Well, then change the Requirements



  • The project I am currently on was well underway when I arrived on the scene. Consequently, a lot of the framework and structure had already been decided, which is fine. It makes my job simpler... in theory.

    The section that my team is working on involves allowing the user to enter notes on the "case" they are currently working on. The requirements ask that they be able to attach additional data to each of these notes regarding the source of the information in the note, the time spent in investigating, etc. Notes are entered thorughout the application but only in our particular section is this additional data needed. A forward-thinking data modeler actually allowed for the storage of these notes in the database so we are good to go there.

    However, when we began presenting our design to a project lead, we hit a minor snag.

    Lead: You need to use the "Notes Control" that we have already developed.

    Us: Um... we can't because they want to save this additional data that is not part of the control.

    Lead: No, you have to use the standard control.

    Us: What about this additional data?

    Lead: Tell them they cannot have it.

    Us: But it is in the spec that has already been approved. The database even already has the fields to save this additional data. Can't we just copy the existing control and create a second control modified to include this additional data.

    Lead: No. Tell them they have to change the spec to fit the control that has already been developed.



  • Um... no... I can see why you posted this to vent. Your lead is clearly an idiot.



  • This is my favorite new method of development. Don't actually build anything, just always update the spec to match what we already have.

    I can get behind this!



  • I wonder if this is the same train of thought followed at a previous employer's software development cycle.

    Some of their SAP modules had odd things involving "Telephone" fields being used for accounting codes and budget stuff. It seems that instead of creating new fields, they used a pre-existing table format and just used the existing fields for other stuff, hence a bunch of "telephone" fields being used for everything. Gah!



  • @superjer said:

    This is my favorite new method of development. Don't actually build anything, just always update the spec to match what we already have. I can get behind this!

    I'm sure we can get a license for that Universal Calculator someone made a while back. We'll be set for life!



  • I might try this in a game dev session...

    "We can't replicate that accurately in the game engine, it's too much processing power"
    "Then change the laws of physics, idiot"



  •  @danixdefcon5 said:

    I wonder if this is the same train of thought followed at a previous employer's software development cycle.

    Some of their SAP modules had odd things involving "Telephone" fields being used for accounting codes and budget stuff. It seems that instead of creating new fields, they used a pre-existing table format and just used the existing fields for other stuff, hence a bunch of "telephone" fields being used for everything. Gah!

    Same here - I used to have an ongoing argument with my boss over whether it is ever OK to add fields to a table or (gasp!) add a table. Having data of a different type, with different relationships, semantic and logical differences ... not a good enough reason in his eyes to "change the database". Why change the database, when you can just make the ubiquitous varchar fields longer and longer? And what do semantics and logic matter when there are no foreign keys and columns are duplicated across tables (so that deleting something left its ghostly remains all over the GUI ... )?

    It stopped when he finally caved in and let me rewrite the lot. There can be happy endings. Only now I'm really busy.

     


     



  • Note sure if this helps, but why not just subclass / extend the control and handle the extra data there?

    The idiot's lead's and spec's requirements are all satisfied!



  • @nexekho said:

    I might try this in a game dev session...

    "We can't replicate that accurately in the game engine, it's too much processing power"
    "Then change the laws of physics, idiot"

    So... Tribes 2?

    (Actually that was more like, "we can't get the wheeled vehicles to work correctly, so let's convert them at the last second into hovercraft. Make sure you leave some of the wheeled tank graphics in the game, though." Even worse, Halo was released the same year and fucking nailed wheeled vehicle physics. Tribes FAIL.)



  •  Hmm, I have had a similar experience... we develop an 'app' that runs on various platforms; iPhone, Android, Nokia, Blackberry.

    The iPhone dev decided he didn't like a spec'd major feature, so he excluded it.  Noone noticed until it was basically too late.

     



  • @jpaull said:

    Lead: No. Tell them they have to change the spec to fit the control that has already been developed.
    Telling them to change the spec sounds like the role of the development lead. Really. This is taught in CYA101.


  • 🚽 Regular

    @blakeyrat said:

    (Actually that was more like, "we can't get the wheeled vehicles to work correctly, so let's convert them at the last second into hovercraft. Make sure you leave some of the wheeled tank graphics in the game, though." Even worse, Halo was released the same year and fucking nailed wheeled vehicle physics. Tribes FAIL.)

    TRWTF is they still had a wheeled vehicle in the game.



  • @RHuckster said:

    @blakeyrat said:

    (Actually that was more like, "we can't get the wheeled vehicles to work correctly, so let's convert them at the last second into hovercraft. Make sure you leave some of the wheeled tank graphics in the game, though." Even worse, Halo was released the same year and fucking nailed wheeled vehicle physics. Tribes FAIL.)

    TRWTF is they still had a wheeled vehicle in the game.

    Yeah, and the second time it fell into a 2' ditch and exploded, we all wished they had made it into a hovercraft as well.



  • AssCreed II sometimes interprets a minor bump on a roof, or on the ground, as a ledge, and trying to casually walk over it triggers the ledge-look-down view. Looks comical.

    But yeah, at least the character doesn't do something like fall over it and lose health.



  • You've probably never seen this because it's specifically avoided in level design but Unreal Tournament 3's player physics (this may be replicable in other games running on the same engine) allow the player to run up any structure that looks like a staircase, even if said staircase has an incline angle of 85 degrees, thus the player can run 10x quicker up a terraced wall than on the flat.



  • @nexekho said:

    I might try this in a game dev session...

    "We can't replicate that accurately in the game engine, it's too much processing power"
    "Then change the laws of physics, idiot"

    SMBC already did it!  (Click for full-size)

    Saturday Morning Breakfast Cereal



  • @nexekho said:

    this may be replicable in other games running on the same engine)
     

    DOOM I and II



  • @DaveK said:

    SMBC already did it!  (Click for full-size)
     

    SMBC is the new XKCD

    Unlike XKCD, it sometimes makes me LOL.


Log in to reply