• chris (unregistered) in reply to cparker
    Even where the document was obviously incorrect or did not make sense, it HAD to be done that way.

    At first glance, it seems like you're saying it's a good thing to be forced to code to a bad spec. After re-reading your entire original comment, it's evident that coding exactly to spec is just a CYA measure, and shifts the blame to the person(s) defining the specs in case of product failure.

    I have worked somewhere where the spec was the contract. We had to implement the spec as written or not get paid. We could ask the customer to change the spec, but if they failed to do so then they got what the spec said. This did mean creating an api that returned error messages that were completely useless (we were adding a programatic api to replace a UI - but the spec said return the first error message that the user would see which is great if you can see the screen that you are filling in but "invalid field" is not much help).

  • Coder (unregistered) in reply to nwbrown

    Yeps, its true, that if the lower level guys don't force the upper level guys to the idea that the lower level guys have some rules, then its a bad situation. But surely there is some project manager and project guidance team that supervices the project. If the guidance team notices that some rules are not being followed, then there should be some trigger for action.

  • Mike Gavaghan (unregistered)

    Sponsors control the budget, the timeline, and the scope - but don't want to bear any of the responsibility for success. They don't want to hear whiny developers complaining about a need for "testing". Yet, they don't mind beating the dev team with sticks when things don't work.

    Complicating things is the "dumbing down" of the techies they hire. The job requirements can usually be boiled down to having the right keywords on your resume and the lowest possible hourly rate. Nevermind having seasoned, experienced, enthusiastic hot shots on your team - they're too expensive!

    Whatever Happened to the "Old School" Programmers?

    Mike

  • Jon haugsand (unregistered)

    Requirements as in "specifications" don't work very well. As a "Certified Scrum Master" (really) I enjoy the life of participating in scrum organized projects.

    • Jon
  • Coder (unregistered) in reply to Jon haugsand

    Modern software can have millions of lines of program code and business logic. And they are intertwined so that many things affect many others at all levels. So I would like some specs there.

    Surely its pretty straight forward to omit a few extra walls from a building, but software really isn't that easy.

  • Josh the do-everything-guy (unregistered)

    Our dev process is supposed to Agile because they want to push out projects superfast without any documentation. We've consistently ran into issues where noone had any idea what was supposed to happen..."It's agile".

    I'm a firm believer in Requirements. When I'm approached about why something wasnt tested, I say I didnt know about it or didnt know how it was supposed to work because there was no communication or documentation. Yes, requirements can be a pain to document but it actually saves more time during the dev process (if they havent started coding before the conceptual design) and I'm able to pop out new tests like there's no tomorrow.

    Unfortunately, noone else sees any value just because they consider it more work and guess who gets to do the requirements? Me. I'm supposed to be planning, creating, executing tests but since there are no requirements, I have to stop and define them in order for me to do my job...

    "How's QA going?" oh I havent started because I'm too busy trying to figure out HTF the stuff is supposed to work.

  • Adam (unregistered) in reply to Trevel
    You had firm rules that you ignored -- and that's somehow their fault?
    To be fair, programmers don't always have a say in the matter. I've been in way too many situations like this:

    Me: "There is absolutely no way in hell we can implement this change by tomorrow. That's not enough time to even build it out properly, let alone do any kind of testing. If it's SO crucial to the client, then they shouldn't have any problem with giving us the time we need to do the job right."

    Boss: "Yeah, I completely understand. I'll explain the situation to them; they're just going to have to wait."

    .. a few hours later ..

    Boss: "The client said that it is absolutely 100% imperative that this change is done tomorrow, no matter what. I explained why we can't do it, they promised that this would be the VERY last change, so I told them we'd do it this one last time. I know, it sucks, but it's the VERY VERY last change, for real this time!"

    Me: (...urge to kill...rising...)

  • Jay (unregistered)

    Last year I worked on a project where a few weeks after deployment, the boss of the client said that he wanted an additional report. Surprised, I said, "But, we've already deployed. I can add that to the list of things for version 2 ..."

    He angrily replied that this report should have been part of version 1.

    I explained that no one had ever mentioned this report as a requirement before. This was the first I'd ever heard of it.

    "Well," he said, "I didn't bother to describe this in the requirements documents because I just took it for granted that the system would be able to produce any report I need at any time."

    My reply was something on the order of "Ummm ... ah ... oh ..."

    My new motto became, "What's the point of discussing the requirements NOW? We haven't even written the code yet."

  • (cs) in reply to Adam
    Adam:
    You had firm rules that you ignored -- and that's somehow their fault?
    To be fair, programmers don't always have a say in the matter. I've been in way too many situations like this:

    Me: "There is absolutely no way in hell we can implement this change by tomorrow. That's not enough time to even build it out properly, let alone do any kind of testing. If it's SO crucial to the client, then they shouldn't have any problem with giving us the time we need to do the job right."

    Boss: "Yeah, I completely understand. I'll explain the situation to them; they're just going to have to wait."

    .. a few hours later ..

    Boss: "The client said that it is absolutely 100% imperative that this change is done tomorrow, no matter what. I explained why we can't do it, they promised that this would be the VERY last change, so I told them we'd do it this one last time. I know, it sucks, but it's the VERY VERY last change, for real this time!"

    Me: (...urge to kill...rising...)

    You know, I'd be the last person in the world to defend agile "methodology" to you, but there is a kernel of truth in there.

    Basically, keep listening. What you deliver, first go, won't be what they wanted, as per contract. It will probably keep them going for a while (say, 635 rows out of a possible 600 million, as per snoofle.) So: get as much as you can get done, without being divorced in the middle and without skipping unit tests and without skipping qa and without skipping lunch.

    Then deliver.

    They will moan. Your boss will moan. What do you care? You're a professional, goddamnit!

    In two weeks' time, you'll have sorted out all the minor bugs, and both your boss and the customer will be creaming themselves. (You don't have to take photographs of this. But it might help.)

    Then you can get on with the real work.

  • Coder (unregistered)

    A lot of people use prototypes early in the project. The prototypes are rough examples about how the program could look like and the prototype is created fast and lousy because the prototype is supposed to be scrapped later. But then the customer tends to think that the product is quite ready already, and they might want to keep the prototype without starting again from scratch with better design. Then you end up using the lousy designed prototype.

    Or if you use evolving method of software development, then when you deliver version 1 with many bugs, the customer might think that you delivered the product, so the customer doesn't want to pay for evolvement nor fixing the bugs.

    So the contract should have a mentioning about the method of software lifecycle. If you use prototypes or evolving, put it into the contract.

  • James Ingram (unregistered)

    The real WTF here is that a senior manager didn't blame the devs.

  • M.waqas (unregistered) in reply to Coder

    Sir i need job

  • GeraldDew (unregistered)
    Comment held for moderation.

Leave a comment on “We Don't Need Requirements”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article