We Don't Need Requirements

« Return to Article
  • evilghost 2008-02-13 12:11
    I've been involved in similar projects and now have the insight to run at FIRST sign of them. The never-ending project, with no scope, no details, and an hourly vision of what the application should do.
  • SkittlesAreYum 2008-02-13 12:14
    I am the only one who thinks this could have used better grammar, and perhaps a better explanation? If someone was telling me this story in real life, they would have sounded out of breath. I felt winded just reading it.
  • Mean Mr. Mustard 2008-02-13 12:17
    ...And they were delicious!
  • suzilou 2008-02-13 12:17
    evilghost:
    I've been involved in similar projects and now have the insight to run at FIRST sign of them. The never-ending project, with no scope, no details, and an hourly vision of what the application should do.


    sounds like a cash-cow for contractors though. why run away?
  • stationary 2008-02-13 12:22
    Sponsors getting their full measure of comeuppance?

    heart.getCockles().setWarm(true);
  • Disnarda 2008-02-13 12:22
    SkittlesAreYum:
    I am the only one who thinks this could have used better grammar, and perhaps a better explanation? If someone was telling me this story in real life, they would have sounded out of breath. I felt winded just reading it.

    I think that was just the idea...
  • zip 2008-02-13 12:24
    stationary:
    Sponsors getting their full measure of comeuppance?

    heart.getCockles().setWarm(true);


    Beat me to it. Nice to see the right guy getting the blame for a change.
  • Trevel 2008-02-13 12:25
    I like how it tried to blame it all on the sponsers.

    Yes, of COURSE the sponsers are going to take advantage of anything you do, if you don't push back and demand requirement documents. You had firm rules that you ignored -- and that's somehow their fault?

    People who ask for programs/databases are very seldom coders, and certainly don't know the rules that we work under. Why should they? That's *our* job. "Making it work by any means possible, despite breaking every rule in the department" is the true WTF here.
  • morry 2008-02-13 12:31
    I've worked on a few that are similiar, although not quite so WTFy. One project where the requirements / specs were quite detailed and complete. And completed AFTER we loaded to production. I enjoyed the review where I got to do the reverse of what normally occurs. I got to tell the BA to remove or change requirements because "that's not how it works".

    Another one where the BA had been the first to use a new process, and as such the external consultants were the ones driving the meetings. The end result of this is that the requirements were done right, and done up-front. But the process had been so difficult for this BA that she had "broken down in tears more than once". The end result of this painful process was the resulting document was carved in stone. Even where the document was obviously incorrect or did not make sense, it HAD to be done that way. Which was fine in some cases - during acceptance testing the invariable sequence was: "this doesn't work, right, fix it". "See page 87, works as per specs". "Shouldn't work that way, needs to change". "closing the problem ticket. Please open up a change request." I think she cried a lot during that phase too.



  • Zylon 2008-02-13 12:35
    morry:
    The end result of this painful process was the resulting document was carved in stone. Even where the document was obviously incorrect or did not make sense, it HAD to be done that way.

    I can't tell-- are you ashamed or proud of this?
  • Galbrezu 2008-02-13 12:36
    evilghost:
    I've been involved in similar projects and now have the insight to run at FIRST sign of them. The never-ending project, with no scope, no details, and an hourly vision of what the application should do.


    Welcome to my life RIGHT NOW, I really need to start looking for a better place to work.
  • Mateo_LeFou 2008-02-13 12:37
    suzilou:
    evilghost:
    I've been involved in similar projects and now have the insight to run at FIRST sign of them. The never-ending project, with no scope, no details, and an hourly vision of what the application should do.


    sounds like a cash-cow for contractors though. why run away?


    That cow is dry: client will stop paying partway through it, on account of bugs. Bugs creep in when client demands functionality (gotta have it tomorrow, by the way) that is out of scope.

    A few months after you give up trying to get paid to put out fires, client will try to send you a bill because some other codeshop quoted him $20,000 to redo everything and she thinks you ought to pay it..

    (This obviously won't wash, legally, but you're never getting the arrears)
  • Mateo_LeFou 2008-02-13 12:41
    Trevel:
    I like how it tried to blame it all on the sponsers.


    I agree with Trevel. Policy should be "no spec, no check"

    You were quite happy to take (evidently lot of) money over the course of the project, but did not insist that someone outline what was expected of you?
  • morry 2008-02-13 12:42
    Zylon:
    morry:
    The end result of this painful process was the resulting document was carved in stone. Even where the document was obviously incorrect or did not make sense, it HAD to be done that way.

    I can't tell-- are you ashamed or proud of this?


    Ashamed or proud of what? I'm not sure I know what you're refering to.
  • Kederaji 2008-02-13 12:43
    evilghost:
    I've been involved in similar projects and now have the insight to run at FIRST sign of them. The never-ending project, with no scope, no details, and an hourly vision of what the application should do.
    So... I take it you've worked for either 3D Realms or Ion Storm before?
  • TheDev 2008-02-13 12:47
    morry:
    Zylon:
    morry:
    The end result of this painful process was the resulting document was carved in stone. Even where the document was obviously incorrect or did not make sense, it HAD to be done that way.

    I can't tell-- are you ashamed or proud of this?


    Ashamed or proud of what? I'm not sure I know what you're refering to.


    EPIC FAIL ...
  • TheDev 2008-02-13 12:48
    morry:
    Zylon:
    morry:
    The end result of this painful process was the resulting document was carved in stone. Even where the document was obviously incorrect or did not make sense, it HAD to be done that way.

    I can't tell-- are you ashamed or proud of this?


    Ashamed or proud of what? I'm not sure I know what you're refering to.


    EPIC ... FAIL ...
  • Greyfairer 2008-02-13 12:49
    The end result of this is that the requirements were done right, and done up-front. But the process had been so difficult for this BA that she had "broken down in tears more than once".

    In my case, our team lead and the Customer's BA spent two full weeks in a little office yelling at each other. Our team lead blaming the BA for giving inconsistent requirements, and the BA blaming our team lead for refusing to design something that was consistent with his inconsistent requirements.

    When development stalled because we got no more input, the customer fired the BA, and we had to replace our team lead. He has found a better place since.
  • Tei 2008-02-13 12:55
    I like this WTF. It feel soo real that it smeel, and make all others WTF on this site looks like fanfiction.

    Alex, can you change the captcha to show humurous words? My captcha is now "nisl" that I doubt is a english word. We must respect traditions!
  • morry 2008-02-13 12:57
    TheDev:
    EPIC ... FAIL ...


    thanks... for... adding... nothing... to... the... conversation..., twice... even...
  • Dave 2008-02-13 13:07
    Responding to Trevel--
    I, like many developers, would agree with you. But I experienced the exact same thing where a client demanded to push forward on a year long enterprise e-commerce project with about 20 bullet points for a spec.
    We, the developers, demanded that the client give us clear specs, but our management made us allow the client to do whatever they wanted. After all, everyone knows, the customer is always right. And when a customer is really whiny and your management is really spineless, well...this is what you wind up with.
  • cparker 2008-02-13 13:20
    morry:
    Zylon:
    morry:
    The end result of this painful process was the resulting document was carved in stone. Even where the document was obviously incorrect or did not make sense, it HAD to be done that way.

    I can't tell-- are you ashamed or proud of this?


    Ashamed or proud of what? I'm not sure I know what you're refering to.
    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.

    Tracer bullets FTW.
  • s. 2008-02-13 13:22
    Galbrezu:
    evilghost:
    I've been involved in similar projects and now have the insight to run at FIRST sign of them. The never-ending project, with no scope, no details, and an hourly vision of what the application should do.


    Welcome to my life RIGHT NOW, I really need to start looking for a better place to work.


    Oh, no. You just need to pay close attention to ALL the requests, require them all in writing and document every change together with estimated man-hours to implement.

    Then when the deployment day comes, you can say "we are 163 years, 11 months, 3 days and 15 hours ahead of schedule for current scope of work."

    Every single change of requirements = more development time.

    I was in such a project recently. Intended to be some 3 months work, it lasted 6, finished only slightly after the "extended" schedule and came out polished, flawless and a delight to all who use it. All extra requirements were fulfilled, all expectations met in their widest scope, documentation detailing every single detail both as raw specs and as juicy how-to, hooks for extra functionalities and customizablity in all possible places and so on. People come to me asking about using the system and customizing it in certain way, and I just open the manual and point them "here it is". They come up with some quite far-fetched ideas and they didn't even get halfway through possible layers of customizablity.

    Yeah, we doubled the development time. And when they asked why, "well, we were 2 months into the project and they changed the requirements totally, we had to rewrite from scratch and the new requirements had even wider scope than the original." Yep, we rewrote it from scratch, but we had all the projects ready about how it -should- work, and we could finally fit them in the specs :)
  • Trevel 2008-02-13 13:25
    Responding to Dave--

    I'll certainly agree with that. If you don't have support from management, then there's not much you can do (except it take it higher to the next level of management). -- apply my criticism to the manager, then, or the team lead, or whoever it is who said "Just go along with whatever they say". When you lie down in the mud in front of the sponsors, don't be surprised when you get walked on.

    Props to *my* manager for saying when I started -- if we don't have an approved requirement document on file, we don't do ANYTHING.

    Granted there's a 1% chance that the requirement will actually be *useful*, but it's a start.
  • s. 2008-02-13 13:33
    cparker:

    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.


    One of best ways to teach your kid not to smoke when it smokes its first cigarette, is to give a whole pack and force the kid to smoke them all.

    Feed the BA their own medicine. They get paid for producing the specs. We are paid to produce software to the specs. If BA does half-assed job and we do the "good thing" we need to do our job, fix the BA's work AND take the blame for any screw-ups, our and their.

    If BA produces good specs, blame, if any, is where it's due.

    If BA produces bad specs and gets blamed for bad product, this should teach them not to do it.


    Where I work, we have guidelines concerning this: "We mention shortcomings of the specs if we notice any ONCE and allow changing them, but if our opinion is ignored, we produce exactly the crap we were asked to." and the second one is "Even late changes to specs are welcome AND BILLED ACCORDINGLY".
  • halber_mensch 2008-02-13 13:39
    SkittlesAreYum:
    I am the only one who thinks this could have used better grammar, and perhaps a better explanation?

    A statement and a question, all in one convenient sentence!
  • CynicalTyler 2008-02-13 13:43
    Yes, this is totally and completely the fault of the development firm. Trevel's right. If you know the project is going to fail and you don't change things, you're a critical component in the failure of the project.

    It's up to you to tell your clients the best way to do things because they often don't know and they're paying you to tell them. Of course you can't force best practice but you had sure as hell better try.

    Sure, maybe this firm didn't get punished because the ultimate cause of the failure was a non-compliant client, but you can't get past the fact that they helped the project fail. In the end, it's your reputation that gets you your bread and butter and that's what matters: not whose fault it was.
  • DudeMonkey 2008-02-13 13:45
    SkittlesAreYum:
    I am the only one who thinks this could have used better grammar, and perhaps a better explanation? If someone was telling me this story in real life, they would have sounded out of breath. I felt winded just reading it.


    Transposition of question word and subject. This penalty is declined.
    Illegal use of commas. 10 yard penalty. Repeat 1st down.
  • DudeMonkey 2008-02-13 13:47
    This sounds like a joint failure. I would have difficulty saying that one group, and one group only, is responsible for a failure of this magnitude.

    The sponsors were crazy. That's for sure. However the development team was poorly led. There's blame enough to go around.
  • morry 2008-02-13 13:50
    cparker:


    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.


    thank you. I was trying to draw out the original poster and the troll because, while I had a rough idea, I don't see the fail or why I should be ashamed. There's lots more to that story that wasn't included because it wasn't relevant. Those reading the story have a different perspective than me, and a lot less information.

    It is not a good thing to code to a bad spec, and it wasn't a CYA. The sequence of events was like this:

    Dev: "This requirement doesn't make sense because of X, Y, and Z, we need to correct it to ABC"

    BA: "I don't think so. That's the way the spec reads, that's how it should be done. Besides I have to go through a change review then."

    Dev: "Look, this is really important. It's gonna take us more time, be worse, and it's not going to do what you need, in the long run. You'll have to change it later."

    BA: "Sorry, but I CRIED during the development of this spec. Follow the spec. Or do I need to bring management in on this and point out you're not willing to follow the new process?"


    In other words, there was no CYA involved. There was due diligence to produce a quality product as the customer wanted. If the customer insists on doing it wrong, and ends up changing their mind later, that's their choice. But they have to take responsibility for their choices. It's not a good situation, but it's the only possibility. Well there's one other - doing it what Dev thinks is the right way and then either getting congratulated or fired when it's completed, but that's a dangerous road.

    Does that cover it? Or have I still left out some piece that would clear this up more?
  • Rooser 2008-02-13 13:56
    The sponsors responded that we don't need specifications because it will be done when we don't see any more problems.

    I worked on a project just like that just a few months ago. Occasionally, something comes up that reminds us of that project and my boss will break into a delighted grin and say, "Aren't you glad we don't have to work with 'Costive Co.' anymore?"

    I guess it wasn't exactly like this story because we did get requirements in writing. That didn't stop the folks at "Costive" from changing their minds, though. And we needed the money badly at the time, so we put up with it. Features they said were crucial became ignored and half-developed as they dreamed up new crucial features. Weekly meetings focused on whatever nifty new feature the client had dreamed up since the last meeting. When we actually did institute a code freeze to try and catch up with bugs, they were upset about it.

    Oh, and did I mention that the whole time we were building this application, they were bringing in paying customers to use it? At least we did have separate dev and prod environments, even if the walls between them were paper-thin. More than once, prod got updated before dev, enough times that we had to abandon the svn repository for the dev server and create a new dev repository based on prod.

    In the end, we got to a point where we needed their money less than we needed our sanity, so we pulled out the dusty old Scope of Work and used it to show Costive that not only had we built everything they'd asked for, but a bunch of extra stuff as well. We asked them to pay for the extras. Then we told them that if we were going to continue development we'd need a new signed contract and scope of work by a specific date. The date came and went and they never signed, so we gave them all their stuff and washed our hands of the project.
  • Change Request 2008-02-13 13:59
    Trevel:
    Responding to Dave--

    I'll certainly agree with that. If you don't have support from management, then there's not much you can do (except it take it higher to the next level of management). -- apply my criticism to the manager, then, or the team lead, or whoever it is who said "Just go along with whatever they say". When you lie down in the mud in front of the sponsors, don't be surprised when you get walked on.

    Props to *my* manager for saying when I started -- if we don't have an approved requirement document on file, we don't do ANYTHING.

    Granted there's a 1% chance that the requirement will actually be *useful*, but it's a start.


    Requirement: Read my mind and code the software to make it work exactly like I think it should work each time I try to use it. The way I want it to work may be different from moment to moment depending on my mood, what I want it to do, and who else is also watching. Should work in all moon phases equally and please the mother goddess.
  • Trevel 2008-02-13 14:11
    Change Request:


    Requirement: Read my mind and code the software to make it work exactly like I think it should work each time I try to use it. The way I want it to work may be different from moment to moment depending on my mood, what I want it to do, and who else is also watching. Should work in all moon phases equally and please the mother goddess.


    Mmhmm, let me see, here's one for you:

    Requirement: Find someone else to build your dream project.

    -- is there anything so freeing as being able to say "no"?
  • Steve 2008-02-13 14:19
    If this kind of stuff bothers you, stay clear of academia.

    My "requirements" usually are transmitted to me by way of a chance meeting at the coffee shop and projects are all open ended.

    I've worked on projects for five years without any sign of completion.

    But, hey, it's research.
  • Lysis 2008-02-13 14:23
    Trevel:
    I like how it tried to blame it all on the sponsers.

    Yes, of COURSE the sponsers are going to take advantage of anything you do, if you don't push back and demand requirement documents. You had firm rules that you ignored -- and that's somehow their fault?

    People who ask for programs/databases are very seldom coders, and certainly don't know the rules that we work under. Why should they? That's *our* job. "Making it work by any means possible, despite breaking every rule in the department" is the true WTF here.


    I don't know what planet you're on, but he did say "sponsor" so that means the guys with all the fuckups were the guys with the money. The guys with the money call the shots. The programmer is just trying to make a paycheck. Not everyone can afford to just walk away because they can't explain to the jackasses with the money what specs are. If it was as easy as saying "no specs, no code." then half the posts on this site wouldn't exist.
  • Barf 4 Eva 2008-02-13 14:26
    "The system was designed, based on the sponsoring users claims, to handle 500-600 million records per day."

    So... how did nobody notice that it was REALLY only going to be 350 rows of data in your db??

    Honestly, where were the 500-600 million "records" coming from? If it was data from some pre-existing system, show me the pre-existing system. If it was expected millions of transactions per day (or were these bulk loads, which begs the question of where the data was coming from), what was this need based off of? Yeah, specs specs specs specs specs... As someone who loves OLTP databases: Understanding data distribution, number of concurrent users, and how many IUD operations are happening, are all very VITAL to making some assessment of 500-600 million records per day coming in to the system. Honestly, I'd cry foul if I didn't have specs for a system stated at half a million rows per day. You seriously need to determine where the hell they got that figure from before I outright believing it.. Snoofle, I imagine you are standup guy/girl who knows the WTFery of his/her own company, but man.... it seems like the biggest problem is a full lack of skilled project management and a full lack of skilled DBAs/Programmers with solid DB knowledge.

    Man, I swear I said this the last time TDWTF posted an article by a guy they had given the pseudo-name of snoofle to... Same snoofle? If so, same problem. Management sucks. And perhaps the devs/db programmers are not taking enough responsibility upon their own shoulders in this regard as well...

    Anyways, I'll read through the comments and see if you already responded and gave more detail on the situation with the sponsor... If not, please share!
  • Mike 2008-02-13 14:27
    Change Request:
    Trevel:
    Responding to Dave--

    I'll certainly agree with that. If you don't have support from management, then there's not much you can do (except it take it higher to the next level of management). -- apply my criticism to the manager, then, or the team lead, or whoever it is who said "Just go along with whatever they say". When you lie down in the mud in front of the sponsors, don't be surprised when you get walked on.

    Props to *my* manager for saying when I started -- if we don't have an approved requirement document on file, we don't do ANYTHING.

    Granted there's a 1% chance that the requirement will actually be *useful*, but it's a start.


    Requirement: Read my mind and code the software to make it work exactly like I think it should work each time I try to use it. The way I want it to work may be different from moment to moment depending on my mood, what I want it to do, and who else is also watching. Should work in all moon phases equally and please the mother goddess.


    There's a Dilbert comic hanging up here in the office with a engineer and the client sitting down hashing out requirements; the engineer is asking the client what the software SHOULD do, and the client wants the engineer to tell her what the software CAN do. It's the classic, I-have-no-freakin'-clue-what-I-want--so-please-tell-me-what-I-want issue that just about every engineer with any measurable experience gathering requirements has had to deal with. The only alternative to this is to sit in your cube and ponder what hurts less: a cattle prod in your rectum, or slamming your own head in your car door. The alternative is far more pleasant, no matter which one you choose.
  • Recycled contractor 2008-02-13 14:32
    Reminds me of The Neverending Project.

    This was at one of the country's largest banks, and as far as anyone remembered, the project had been ongoing off & on for 12 years. What happened was one of the Senior VPs wanted a system to do something or other -- estimated time to complete was just over a year. About 2/3 of the way into the project, the sponsor leaves for another position within the bank. The new Senior VP of Absolutely Nothing has been watching Animal Planet's Big Cat Diaries -- the episode where they explain that the new Alpha Male has to kill all the previous male's lion cubs in order to assert his new position. And that's what he does -- he canceled the project, sending all the contractors home.

    A month later, he has a brainstorm -- he wants a system to do something or other. It's just like the previously killed system, but with minor tweaks, and the major innovation that it's HIS idea! They staff up with contractors for this, gather requirements, do their design, and start coding.

    About 2/3 of the way through the project, the sponsor leaves for a new position in the bank. The new Senior VP, who had been watching Big Cat Diaries too, kills the lion cubs and sends the contractors home because the project is obviously not needed, the budget is overdrawn, or some such reason.

    A month later....
  • DudeMonkey 2008-02-13 14:44
    Lysis:
    Trevel:
    I like how it tried to blame it all on the sponsers.

    Yes, of COURSE the sponsers are going to take advantage of anything you do, if you don't push back and demand requirement documents. You had firm rules that you ignored -- and that's somehow their fault?

    People who ask for programs/databases are very seldom coders, and certainly don't know the rules that we work under. Why should they? That's *our* job. "Making it work by any means possible, despite breaking every rule in the department" is the true WTF here.


    I don't know what planet you're on, but he did say "sponsor" so that means the guys with all the fuckups were the guys with the money. The guys with the money call the shots. The programmer is just trying to make a paycheck. Not everyone can afford to just walk away because they can't explain to the jackasses with the money what specs are. If it was as easy as saying "no specs, no code." then half the posts on this site wouldn't exist.


    One of the main purposes of tech leads and project managers is to push back on the people with the money. Yes, they have money, but I'm going to guess that they're going to want working software as an ROI more than they're going to want XYZ shiny new feature. This was an example of poor management on the part of the development team as much as it was insanity on the part of the project sponsors. I would say that they share the responsibility pretty equally.

    Realistically, it's the job of the engineering TEAM or DEPARTMENT to manage these projects. Not necessarily the programmers themselves, but the department.
  • TheDev 2008-02-13 14:46
    morry:
    TheDev:
    EPIC ... FAIL ...


    thanks... for... adding... nothing... to... the... conversation..., twice... even...


    Ouch you missed that AOTS reference, how embarrassing for you.

    I decided the first didn't quite capture the voiceover in question; the second nailed it.
  • ComputerForumUser 2008-02-13 14:58
    Referring != Adding
  • relaxing 2008-02-13 15:04
    DudeMonkey:
    SkittlesAreYum:
    I am the only one who thinks this could have used better grammar, and perhaps a better explanation? If someone was telling me this story in real life, they would have sounded out of breath. I felt winded just reading it.


    Transposition of question word and subject. This penalty is declined.
    Illegal use of commas. 10 yard penalty. Repeat 1st down.

    What does this mean? Exactly what grammar rules were broken and where?
  • CodeMonkey 2008-02-13 15:15
    Personally, I hope they were eaten.


    Never before has that awful feeling I've had after leaving a failed project meeting, where the customer was to blame, been summed up so succinctly.

    Bravo!
  • Marc 2008-02-13 15:16
    DudeMonkey:
    Lysis:
    Trevel:
    I like how it tried to blame it all on the sponsers.

    Yes, of COURSE the sponsers are going to take advantage of anything you do, if you don't push back and demand requirement documents. You had firm rules that you ignored -- and that's somehow their fault?

    People who ask for programs/databases are very seldom coders, and certainly don't know the rules that we work under. Why should they? That's *our* job. "Making it work by any means possible, despite breaking every rule in the department" is the true WTF here.


    I don't know what planet you're on, but he did say "sponsor" so that means the guys with all the fuckups were the guys with the money. The guys with the money call the shots. The programmer is just trying to make a paycheck. Not everyone can afford to just walk away because they can't explain to the jackasses with the money what specs are. If it was as easy as saying "no specs, no code." then half the posts on this site wouldn't exist.


    One of the main purposes of tech leads and project managers is to push back on the people with the money. Yes, they have money, but I'm going to guess that they're going to want working software as an ROI more than they're going to want XYZ shiny new feature. This was an example of poor management on the part of the development team as much as it was insanity on the part of the project sponsors. I would say that they share the responsibility pretty equally.

    Realistically, it's the job of the engineering TEAM or DEPARTMENT to manage these projects. Not necessarily the programmers themselves, but the department.


    The programmers and/or the department can push back as much as they want, but at the end of the day, the man with the money says "DO THIS", you either do it or leave -- or get thrown out.
  • Marc 2008-02-13 15:16
    DudeMonkey:
    Lysis:
    Trevel:
    I like how it tried to blame it all on the sponsers.

    Yes, of COURSE the sponsers are going to take advantage of anything you do, if you don't push back and demand requirement documents. You had firm rules that you ignored -- and that's somehow their fault?

    People who ask for programs/databases are very seldom coders, and certainly don't know the rules that we work under. Why should they? That's *our* job. "Making it work by any means possible, despite breaking every rule in the department" is the true WTF here.


    I don't know what planet you're on, but he did say "sponsor" so that means the guys with all the fuckups were the guys with the money. The guys with the money call the shots. The programmer is just trying to make a paycheck. Not everyone can afford to just walk away because they can't explain to the jackasses with the money what specs are. If it was as easy as saying "no specs, no code." then half the posts on this site wouldn't exist.


    One of the main purposes of tech leads and project managers is to push back on the people with the money. Yes, they have money, but I'm going to guess that they're going to want working software as an ROI more than they're going to want XYZ shiny new feature. This was an example of poor management on the part of the development team as much as it was insanity on the part of the project sponsors. I would say that they share the responsibility pretty equally.

    Realistically, it's the job of the engineering TEAM or DEPARTMENT to manage these projects. Not necessarily the programmers themselves, but the department.


    The programmers and/or the department can push back as much as they want, but at the end of the day, the man with the money says "DO THIS", you either do it or leave -- or get thrown out.
  • Byteback 2008-02-13 15:18
    This is actually not Worse Than Failure.

    Worse Than Failure is when there is no management chain to point out the total lunacy of an approach that is worse than a week-long party of burning wads of $100 bills on a reception bonfire.

    Worse Than Failure is when this system go-live is actually deemed a success and the development team who built the beast have the misfortune (or poetic justice, depending on your viewpoint) of being fed into the meat grinder they created, with only the small mercy that one day, maybe, just maybe the will be allowed The Rewrite.

    Worse Than Failure is, well, when these retards get away with it.

    You have a manager that spots these idiots for what they are - that's A Good Thing. Even if you all get fired and the hardware freaks are forced to watch their shiny new toys burn in a skip.

    I want to hire your manager.
  • morry 2008-02-13 15:23
    TheDev:
    Ouch you missed that AOTS reference, how embarrassing for you.

    I decided the first didn't quite capture the voiceover in question; the second nailed it.


    Damn. I've never seen G4TechTV / Attack of the Show (had to google AOTS, hope that's what you're talking about). Where do I turn in my geek card? Am I relegated to only use windows and AOL from here on?
  • Trevel 2008-02-13 15:38
    Byteback:

    You have a manager that spots these idiots for what they are - that's A Good Thing. Even if you all get fired and the hardware freaks are forced to watch their shiny new toys burn in a skip.

    I want to hire your manager.


    Why? Where was he in the past years while development went on without requirements? Where was he during the release when they deployed on the test server?

    I want to fire that manager.

    Or promote him, whichever.
  • mizchief 2008-02-13 15:42
    So what happend? don't leave us hanging like that.

    /spoken like a true boss
  • RayMarron 2008-02-13 16:05
    morry:
    [...]I've never seen G4TechTV / Attack of the Show (had to google AOTS, hope that's what you're talking about). Where do I turn in my geek card? Am I relegated to only use windows and AOL from here on?
    You have it all wrong. Watching the raw effluent that is G4/AOTS is cause for revocation of your geek card, not the other way around!
  • dtremain 2008-02-13 16:05
    To me the real WTF in this situation is a high up muckety muck that is so out of touch with reality that he allows a 50 man year project to grind on with no requirements, no sanity checks, and no accountability until the colossal flame-out - "obviously a major malfunction" as flaming pieces streak across the sky in all directions...
  • G Money 2008-02-13 16:08
    Trevel:
    I like how it tried to blame it all on the sponsers.

    Yes, of COURSE the sponsers are going to take advantage of anything you do, if you don't push back and demand requirement documents. You had firm rules that you ignored -- and that's somehow their fault?

    People who ask for programs/databases are very seldom coders, and certainly don't know the rules that we work under. Why should they? That's *our* job. "Making it work by any means possible, despite breaking every rule in the department" is the true WTF here.


    Agreed. It sounds like this was a generic group of IT Consultants -- you know, the type of organization that will do whatever, say whatever, to win a contract. Delivering on the contract, well, that's another story. There are many, many of them out there.

    Unfortunately, sponsors get used to working with such organizations. When the sponsor says jump, such organizations say "How high?", even when standing in the middle of a minefield. It makes it a huge challenge for the rest of us who are understand that it's our <i>professional obligation</i> to (gently) communicate to the sponsor the risks associated with doing it a certain way and why it's better to do it a different way.

    Suppose you hire a licensed contractor to do work on your house. First of all, don't tell them <i>how</i> you want the work to be done. If you've already hired them, then you should already trust that they'll do it the right way. Second, if you do happen to tell them to do something a certain way, then that contractor has a professional obligation to refuse to do it the wrong way, if it's unsafe, illegal, not to code, etc. Failure to do so can result in the revocation of their license.

    I'm not advocating that developers / IT consultants / whomever be licensed. However, in the absence of standard practices, this is what can happen. Unfortunately, it seems that many sponsors view IT as a commodity; whoever bids the lowest wins the contract. There's no consideration for professionalism, value, and "doing things the right way".
  • G Money 2008-02-13 16:11
    Dave:
    Responding to Trevel--
    I, like many developers, would agree with you. But I experienced the exact same thing where a client demanded to push forward on a year long enterprise e-commerce project with about 20 bullet points for a spec.
    We, the developers, demanded that the client give us clear specs, but our management made us allow the client to do whatever they wanted. After all, everyone knows, the customer is always right. And when a customer is really whiny and your management is really spineless, well...this is what you wind up with.


    In that case, doing the spec. is part of the project. You write it, you bill it, you get the sponsor to sign off on it, then you build it.
  • dlikhten 2008-02-13 16:15
    Poor Snoofle... Sounds like his company is crankin' out WTFs left and right.

    Reminds me of office space... I ALWAYS MESS UP A DECIMAL POINT! 300,000,000... Opsie I meant 300.000,000 whoa slight difference there no?
  • reverendryan 2008-02-13 16:20
    Mike:

    There's a Dilbert comic hanging up here in the office with a engineer and the client sitting down hashing out requirements; the engineer is asking the client what the software SHOULD do, and the client wants the engineer to tell her what the software CAN do. It's the classic, I-have-no-freakin'-clue-what-I-want--so-please-tell-me-what-I-want issue that just about every engineer with any measurable experience gathering requirements has had to deal with. The only alternative to this is to sit in your cube and ponder what hurts less: a cattle prod in your rectum, or slamming your own head in your car door. The alternative is far more pleasant, no matter which one you choose.


    I have the same comic hanging next to my calendar. It always amuses me that Alice is as calm as she is in the last frame. If anyone is interested, the date is 1-29-06.
  • bstorer 2008-02-13 16:28
    RayMarron:
    morry:
    [...]I've never seen G4TechTV / Attack of the Show (had to google AOTS, hope that's what you're talking about). Where do I turn in my geek card? Am I relegated to only use windows and AOL from here on?
    You have it all wrong. Watching the raw effluent that is G4/AOTS is cause for revocation of your geek card, not the other way around!

    Only if you don't immediately exclaim, "They dumped The Screen Savers for this?!?"
  • Steve 2008-02-13 17:06
    I was involved in a project like this. Project ran on for 2 years ( I came onboard in the middle). Unfortunately, not only did the project manager (who was the main liason to the client) NOT write down anything, but he and the client had the habit of making major logic changes midstream, and then just asking one of the developers (not the team or the lead) to just go ahead and implement. Oh, and there was a 2-day delay to make db schema changes, as the client's dba was administering it. Lots of fields called things like "newsletter" filled with delimited lists of ids and other horrible things like that (undocumented, of course).

    At the end the client sued because of how long it took and over budget it was. Unfortunately we couldn't point to a big stack of emails detailing all the changes they'd asked for, because the PM had absconded one night at 3 AM to start his own company, leaving a note on his desk (basing his company on clients taken from the original employer-they eventually sued him too) and bulk-erased his computer, the one that might've had any such notes.

    Good for you for all the notes, would've enjoyed seeing the scene.
  • Richard H 2008-02-13 17:44
    This sounds like it all boils down to no one leading the project. It's all to easy to let the sponsors pitch an idea with no requirements, but surely the first step of any development project it to at least come up with some rough requirements and then to evolve them with the sponsors input as the project progresses.

    I myself am a senior developer working for an isp, we have taken on many large projects with very little in the form of formal requirements. This is usually because the customer or sponsor has very little idea on how to approach a problem, but does understand what the end result of the project is to achieve.

    This is the developers role as they have the technical knowledge and the experience to design and engineer the solution.

    Many times I have been presented with a specification document that was unimplementable and broke every law of reason and logic, however it's all to easy to go ahead and attempt to engineer a solution from a crazy spec, it's the lazy way out. As an software engineer you should be feeding back your knowledge to the sponsor to help them evolve their spec so it is implementable.

    I've never posted on the daily wtf before, but I think I may just start a new thread :)
  • Carnildo 2008-02-13 17:59
    Byteback:
    This is actually not Worse Than Failure.


    Then I suppose it's a good thing the site isn't Worse Than Failure either.
  • tk. 2008-02-13 18:30
    Richard H:
    As an software engineer you should be feeding back your knowledge to the sponsor to help them evolve their spec so it is implementable.


    ...and you implement it, and then when you're finished and it all works well, they get rid of you as quickly as possible for stirring up all of that trouble trying to obtain your specs and making them have to work. You troublemaker.
  • brazzy 2008-02-13 18:43
    Marc:
    DudeMonkey:

    One of the main purposes of tech leads and project managers is to push back on the people with the money. Yes, they have money, but I'm going to guess that they're going to want working software as an ROI more than they're going to want XYZ shiny new feature. This was an example of poor management on the part of the development team as much as it was insanity on the part of the project sponsors. I would say that they share the responsibility pretty equally.

    Realistically, it's the job of the engineering TEAM or DEPARTMENT to manage these projects. Not necessarily the programmers themselves, but the department.


    The programmers and/or the department can push back as much as they want, but at the end of the day, the man with the money says "DO THIS", you either do it or leave -- or get thrown out.


    Total fools who insist on doing the wrong thing after you have carefully explained why it is wrong are rarely the ones who REALLY have the money. In this case, there was an "overlord responsible for the budget" to whom the sponsors were subordinate, and who understood what went wrong and why when it was shown to him. Why was he not notified earlier when the sponsors demanded actions that were against explicit company policy?
  • emurphy 2008-02-13 19:25
    reverendryan:
    Mike:

    There's a Dilbert comic hanging up here in the office with a engineer and the client sitting down hashing out requirements; the engineer is asking the client what the software SHOULD do, and the client wants the engineer to tell her what the software CAN do. It's the classic, I-have-no-freakin'-clue-what-I-want--so-please-tell-me-what-I-want issue that just about every engineer with any measurable experience gathering requirements has had to deal with. The only alternative to this is to sit in your cube and ponder what hurts less: a cattle prod in your rectum, or slamming your own head in your car door. The alternative is far more pleasant, no matter which one you choose.


    I have the same comic hanging next to my calendar. It always amuses me that Alice is as calm as she is in the last frame. If anyone is interested, the date is 1-29-06.


    And here is the actual comic.
  • nwbrown 2008-02-13 19:58
    The sponsors responded that we don't need specifications because it will be done when we don't see any more problems.

    I suppose thats one definition of an 'agile project'.
  • Brett 2008-02-13 21:38
    It sounds like the developers in this organization were treated like the peons of the organization. If upper management wants to set unrealistic deadlines that will put out a POS product, there really isn't anything the developers can do.

    I was in a similar situation and I left. You are better off to abandon the ship then to go down with it. I sent my story to Alex and hopfully he'll post it one day.
  • vt_mruhlin 2008-02-13 23:05
    Trevel:
    I like how it tried to blame it all on the sponsers.

    Yes, of COURSE the sponsers are going to take advantage of anything you do, if you don't push back and demand requirement documents. You had firm rules that you ignored -- and that's somehow their fault?

    People who ask for programs/databases are very seldom coders, and certainly don't know the rules that we work under. Why should they? That's *our* job. "Making it work by any means possible, despite breaking every rule in the department" is the true WTF here.


    It's easy to be a process nazi until upper management goes to monster.com and finds a project monitor with a real "can-do" attitude, who comes in and first tells the management that things will run more smoothly if everything flows through him. Then all he has to do is to tell you to bend whichever way to make the customer happy. And if you don't do it, you're a "roadblock". Some guy three or four levels of management and several countries away rubber stamps your layoff papers without giving you any chance to defend yourself.
  • Cpt 2008-02-14 00:51
    Quote: "It's not like developers need a place to work or test their code. Make all the room you can for that data."

    Erm... you did say that no tests were performed, so don't complain! The real WTF is that the project leader should never have agreed to start the project without specifications and a good, clear business case (measurable, so you can check the outcome with expectations). The architect (was there one?!) should not have agreed to designing an application without specifications and the technicians should never have agreed with an unknown production environment as should the test team. This is a clear example of a project that should have never happened, the sponsoring stakeholder should have been educated. Don't blame it all on the sponsor, the "professionals" in this story should not have resorted to "well... my *ss is covered, so we go ahead - against all better knowledge". Millions of good money could have been saved if the guidance of the users was organized right from the start.

    You are all to blame, developers as well as sponsors.
  • Cpt 2008-02-14 00:56
    vt_mruhlin:

    It's easy to be a process nazi until upper management goes to monster.com and finds a project monitor with a real "can-do" attitude, who comes in and first tells the management that things will run more smoothly if everything flows through him. Then all he has to do is to tell you to bend whichever way to make the customer happy. And if you don't do it, you're a "roadblock". Some guy three or four levels of management and several countries away rubber stamps your layoff papers without giving you any chance to defend yourself.


    No need to call nasty names. That project-monitor will be gone after such a project (or comparable) has happened. If all the developers leave (with announcement mails cc'd to them upstairs stating the reason) some bells should ring, right? Don't agree with wrongdoing for the sake of keeping your job, because bad projects will stink right through your resume as well. Take your responsibility as professional and don't start on such projects!
  • Anders 2008-02-14 01:42
    nwbrown:
    The sponsors responded that we don't need specifications because it will be done when we don't see any more problems.

    I suppose thats one definition of an 'agile project'.


    No, its the definition of an 'unprofessional behaviour'. And I mean both from the sponsor but even more so from the developers, who where (hopefully) the ones with the technical knowledge.
  • Richard H 2008-02-14 02:53
    tk.:
    Richard H:
    As an software engineer you should be feeding back your knowledge to the sponsor to help them evolve their spec so it is implementable.


    ...and you implement it, and then when you're finished and it all works well, they get rid of you as quickly as possible for stirring up all of that trouble trying to obtain your specs and making them have to work. You troublemaker.


    Ah I think I see the problem here I work as a permanent employee and therefore have to maintain and evolve applications after they go live, I also have to deal with customers more than once. I generally find the sponsors don't mind too much in the end providing the application works well.

    Some sponsors may whine if they have to do work, but hey doesn't everyone now and again...
  • Richard H 2008-02-14 02:54
    Anders:
    nwbrown:
    The sponsors responded that we don't need specifications because it will be done when we don't see any more problems.

    I suppose thats one definition of an 'agile project'.


    No, its the definition of an 'unprofessional behaviour'. And I mean both from the sponsor but even more so from the developers, who where (hopefully) the ones with the technical knowledge.


    well said...
  • Tamahome 2008-02-14 03:25
    Chuck Norris don't need specs !
  • Royal 2008-02-14 04:31
    This sounds exactly like every single project I have ever been on. We work for one customer, and for the last 10 years I have done work for them.

    The customer understand they have a problem. But the organization is large, and no single person has a full understanding of what needs to be done with it. Several departments have differing opinions on how to solve the data flow, and different requirements, and different words for almost the same thing.

    Asking the customer to come up with a unified model for how they want their business run is futile. To create a system that they dream of, all of the deparments would have to change some of their beloved methods and do some things more thoroughly than before so that other things can be easier. And the dream is "We want something that works automatically"

    Then we have around 20 other systems to interface with, the far worst of them being SAP, a system so stale and bugged down that I can't for my bare life understand how it was possible to sell it all over the world.

    For two rounds now we have failed miserably in making our big-unified-central-application.

    And now the customers have stolen most of the employees from the contractor too, since they are probably the only guys that have a semi-coherent view on how the big corp customer actually work.
  • zzp 2008-02-14 04:42
    "Handle 500-600 million records per day."

    Lame. My low-end $50 dual-core Athlon 64 4000+ can handle 500 millions SQL queries per day as measured by pgbench when benchmarking PostgreSQL SELECT queries: that's about about 6000 transaction per second.

    A vague statement like "500-600 million records per day." means NOTHING if no more tech details are given.
  • s. 2008-02-14 04:54
    Trevel:
    Change Request:


    Requirement: Read my mind and code the software to make it work exactly like I think it should work each time I try to use it. The way I want it to work may be different from moment to moment depending on my mood, what I want it to do, and who else is also watching. Should work in all moon phases equally and please the mother goddess.


    Mmhmm, let me see, here's one for you:

    Requirement: Find someone else to build your dream project.

    -- is there anything so freeing as being able to say "no"?


    Nah. Just the right hourly salary and the deadline is sometime in the next millenium.
  • s. 2008-02-14 05:08
    Well, what happens when you code out of specs?



    This happens.
  • Rob Baillie 2008-02-14 06:30
    Seriously... what's wrong with customers not knowing what they wanT?
    What's wrong with them changing their minds when they see stuff?
    It doesn't mean you can't produce quality bug free software.

    http://www.extremeprogramming.org/
  • Steve 2008-02-14 06:45
    I have a different take on the "no spec, no code" rule, looking at it from the customer's point of view. We have a large piece of software being developed by a "large military contractor". Here's an example of some of the WTF code in this software. There's this window that is supposed to display error messages. Each message is time-stamped. BUT, you can't actually read the exact time, because they chose a font that is too big, thereby cutting off the last digit of the minute. So you can narrow down the error time to a 10-minute window, but that's it.

    Now, this project was extremely thoroughly spec'd, but this works against us. When we complain about things like this (and there are many more such problems), the developer can simply say "you didn't specify that the last digit of the time has to be readable". And they're right - we didn't. We didn't think of it. But we shouldn't have had to. Such things should be obvious. But they hide behind the specs to justify complete lack of quality.
  • coljac 2008-02-14 06:58
    I was hoping the story would end where they realized the system only needed to handle _550_ requests per month, and the "million" had been cropped up somewhere early on, Chinese whisper-style.

    That would be good evidence that specs can actually be useful - sure, specs are all 1990s and not agile and all, but you know you won't overbuild the system by six orders of magnitude.
  • Tom_fun_63 2008-02-14 07:06
    halber_mensch:
    SkittlesAreYum:
    I am the only one who thinks this could have used better grammar, and perhaps a better explanation?

    A statement and a question, all in one convenient sentence!

    Bravo halber_mensch, best comment of the thread! :-)
  • PAG 2008-02-14 07:55
    Royal:

    The customer understand they have a problem. But the organization is large, and no single person has a full understanding of what needs to be done with it. Several departments have differing opinions on how to solve the data flow, and different requirements, and different words for almost the same thing.


    Yep, that's what 70% of big corps and 50% of small businesses live...*sigh*

    http://blogmiel.blogspot.com
  • JimM 2008-02-14 07:58
    So where was the management team for this project? If the company managers were willing to haul the sponsors over the coals, why weren't the project managers getting hauled over them too? Or weren't there any?

    The only way I can see ALL of the aspects of this story being true is if the project manager left about a month into the project and no-one bothered replacing them (or even mentioning that they'd left), with the secretary handing out coding assignments as the sponsors made more and more outlandish requests because they realised that no-one was checking the requests through a proper change management procedure.

    Otherwise, the problem here is either that the senior management didn't require enough (any?) progress reports from the project management team, or the project management team lied through their teeth. I don't think you can blame the devs for this one, but the sponsors shouldn't suck it all up either: someone in the management chain of the development company seriously failed in their role; keeping the sponsors under control and ensuring the project was carried out in accordance with company policy.

    That said, I'm not sure if this is a WTF or just a typical example of modern buisiness practices...
  • Someone You Know 2008-02-14 08:09
    relaxing:
    DudeMonkey:
    SkittlesAreYum:
    I am the only one who thinks this could have used better grammar, and perhaps a better explanation? If someone was telling me this story in real life, they would have sounded out of breath. I felt winded just reading it.


    Transposition of question word and subject. This penalty is declined.
    Illegal use of commas. 10 yard penalty. Repeat 1st down.

    What does this mean? Exactly what grammar rules were broken and where?


    "I am the only one..." should be "Am I the only one...", since it seems to be a direct question.
    The comma in the first sentence should be removed, because a conjunction (e.g. "and") should only be preceded by a comma if it joins two independent clauses.
    The use of "they" as a neuter singular pronoun is in common usage in some areas, but doesn't make any sense and sounds awkward, so I'd replace it with the correct neuter singular subject pronoun, which is "he" in English.
  • UsageNazi 2008-02-14 08:23


    One of best ways to teach your kid not to smoke when it smokes its first cigarette, is to give a whole pack and force the kid to smoke them all.

    Do you call your own kids "it"? Whoever taught you that this was a proper way to be gender-neutral should be shot. Technically the proper way is "he". However, you can also use "she". Either way -- pick a gender.

    If BA produces bad specs and gets blamed for bad product, this should teach them not to do it.

    Is it one BA or multiple? If it's just one, it's "he" or "she", not "they". For variety, you could just use the opposite gender as the one used for the kid above.
  • snoofle 2008-02-14 08:58
    Trevel:
    I like how it tried to blame it all on the sponsers.

    Yes, of COURSE the sponsers are going to take advantage of anything you do, if you don't push back and demand requirement documents. You had firm rules that you ignored -- and that's somehow their fault?

    People who ask for programs/databases are very seldom coders, and certainly don't know the rules that we work under. Why should they? That's *our* job. "Making it work by any means possible, despite breaking every rule in the department" is the true WTF here.

    We did buck it up - three levels to be exact. At each turn, we were told to just deal with it as best we could. We made sure to repeat the warnings of instability that go hand in hand with no testing, and so forth. Everyone on-high said they were ok with it. We (2 levels up) even got (in writing) approval from the powers-that-be to bypass QA and work directly in prod (the QA folks were NOT amused).

    You can try to do the right thing but sometimes you just get squashed.
  • snoofle 2008-02-14 09:01
    Mateo_LeFou:
    Trevel:
    I like how it tried to blame it all on the sponsers.


    I agree with Trevel. Policy should be "no spec, no check"

    You were quite happy to take (evidently lot of) money over the course of the project, but did not insist that someone outline what was expected of you?

    No contractors here - all in-house personnel and management.
    As I've said, I came on 20 months into a 2 year project. At that point, there was a lot of momentum (stupidity) built up and me and 2 other (new) guys just couldn't stop it.
  • snoofle 2008-02-14 09:13
    Barf 4 Eva:
    "The system was designed, based on the sponsoring users claims, to handle 500-600 million records per day."

    So... how did nobody notice that it was REALLY only going to be 350 rows of data in your db??

    Honestly, where were the 500-600 million "records" coming from? If it was data from some pre-existing system, show me the pre-existing system. If it was expected millions of transactions per day (or were these bulk loads, which begs the question of where the data was coming from), what was this need based off of? Yeah, specs specs specs specs specs... As someone who loves OLTP databases: Understanding data distribution, number of concurrent users, and how many IUD operations are happening, are all very VITAL to making some assessment of 500-600 million records per day coming in to the system. Honestly, I'd cry foul if I didn't have specs for a system stated at half a million rows per day. You seriously need to determine where the hell they got that figure from before I outright believing it.. Snoofle, I imagine you are standup guy/girl who knows the WTFery of his/her own company, but man.... it seems like the biggest problem is a full lack of skilled project management and a full lack of skilled DBAs/Programmers with solid DB knowledge.

    Man, I swear I said this the last time TDWTF posted an article by a guy they had given the pseudo-name of snoofle to... Same snoofle? If so, same problem. Management sucks. And perhaps the devs/db programmers are not taking enough responsibility upon their own shoulders in this regard as well...

    Anyways, I'll read through the comments and see if you already responded and gave more detail on the situation with the sponsor... If not, please share!

    Same snoofle, same DBA group, same anti-management team.

    After I had been here about a month and had gotten my bearings, I made a 10 page list of questions, some of which revolved around some sample data. I forced a series of 2 hour meetings to impress upon various managers that we couldn't build something to handle hundreds of millions of rows of data without actually having that much data, even junk data, to test memory, load, bandwidth, etc. Naturally, we were told that the prod systems had it, but the dev DB resources weren't sufficient to load it and so we would have to make do with about a million rows.

    In practice, it turns out that several source systems feed into one "funnel" system that coalesces the data, and ours was to act as a pipe-like filter after the "funnel". There really were about 600MM rows of data per day. The problem was that the "funnel" applied filters to the data based upon some business rules that the sponsors were aware of, but never told anyone on our team about because they never connected the dots. All we knew was 500-600MM.

    Mountains of code to handle massively parallel processes, synching data across servers, ... sheesh.
  • snoofle 2008-02-14 09:28
    brazzy:
    ...In this case, there was an "overlord responsible for the budget" to whom the sponsors were subordinate, and who understood what went wrong and why when it was shown to him. Why was he not notified earlier when the sponsors demanded actions that were against explicit company policy?

    Because, at least around here, you may not go directly to your bosses boss (at least not unless you want to get fired). We went to our boss who agreed with us. He went to his boss who agreed with us. He went to his boss who didn't care, and signed off on everything we were being forced to do, in writing.

    It's sad, but sometimes you just get dragged along for the ride.

    Personally, I gave this analogy: If you go to an architect and say design and build me a house. He will ask: what style (ranch, colonial, ...), how many rooms, etc. If you tell him: just build it, and I'll let you know after I move in, you are not going to get very far. The same applies in software. We were ordered by 3 levels up to do it (with the clear implication: if you want to keep your jobs).

    We made the thing do what it was supposed to do - it works. Fortunately, I believe in configurable software and designed my part of it to load different classes based upon DB configs, and so the thing can be "reprogrammed" by just changing some db configs to load different implementations of the same classes.

    As a result of this, after the sponsors were moved to another department (people only get laid off for cost savings, apparently incompetance is not an excuse), we met with the folks with the money and a few other teams and showed how out system could also serve many of their needs with just a few minor (1 man-month) modifications. This saved more than a dozen projects, so they seemed pleased.
  • savar 2008-02-14 10:04
    morry:
    In other words, there was no CYA involved. There was due diligence to produce a quality product as the customer wanted. If the customer insists on doing it wrong, and ends up changing their mind later, that's their choice. But they have to take responsibility for their choices. It's not a good situation, but it's the only possibility. Well there's one other - doing it what Dev thinks is the right way and then either getting congratulated or fired when it's completed, but that's a dangerous road.

    Does that cover it? Or have I still left out some piece that would clear this up more?


    I agreed with you before you explained it again. If you're not in a position to change the requirements, then it's not your fault if the requirements are bad.

    A good consultant will try to make things better by pointing out faults or limitations and suggesting improvements. But if they don't listen to you, you have two choices:

    1) Go home. Forfeit payment.
    2) Make money.

    I'm leaning towards #2 on any project with significant time already invested.
  • real_aardvark 2008-02-14 10:08
    Anders:
    nwbrown:
    The sponsors responded that we don't need specifications because it will be done when we don't see any more problems.

    I suppose thats one definition of an 'agile project'.


    No, its the definition of an 'unprofessional behaviour'. And I mean both from the sponsor but even more so from the developers, who where (hopefully) the ones with the technical knowledge.

    Ignoring the obvious sarcasm in nwbrown's post, these two views are not incompatible.

    Don't agile fan-boys understand critical thinking? Or is that a skill that can safely be abandoned because it doesn't fit on a 3x5 card?

    You both need apostrophes, btw.
  • Barf 4 Eva 2008-02-14 10:48
    Damn snoofle... Talk about getting the shit end of the stick!!! Thanks for sharing the rest of the gory details. :)
  • dtfinch 2008-02-14 11:02
    I'd laugh, but I can't remember the last time I've had the luxury of specs or requirements that I didn't write myself.
  • brazzy 2008-02-14 11:13
    Rob Baillie:
    Seriously... what's wrong with customers not knowing what they wanT?

    Nothing... unless they refuse to cooperate in finding out what they want.
    What's wrong with them changing their minds when they see stuff?

    Nothing... unless they do it faster than you can implement the changes, refuse to acknowledge that changes result in additional expenses, or change their mind repeatedly about basic assumptions of the architecture.
    It doesn't mean you can't produce quality bug free software.

    http://www.extremeprogramming.org/

    XP is not a magical silver bullet. At some point the customer needs to make decisions and stick with most of them.
  • snoofle 2008-02-14 11:25
    Barf 4 Eva:
    Damn snoofle... Talk about getting the shit end of the stick!!! Thanks for sharing the rest of the gory details. :)

    I actually like this place. The people are nice, the hours are mostly reasonable and the pay is good. While the system-users could fill this forum with stories for months, the various bosses I've worked for (both in the past the first time I worked here 10 years ago, and today) are very reasonable and flexible, and in all cases, backed me as far as they could.

    As far as dealing with the WTF's, I view it as getting paid to be entertained. It's like watching somebody trying to touch the spinning blade of a circular saw; you tell them not to, they refuse to listen, you can't stop it, you know you shouldn't watch, but you just can't turn away!
  • bshock 2008-02-14 11:28
    I'm not sure I understand the situation. You have Overlords, Sponsors, and Developers.

    -- The Overlords seem to have some notion of proper software development life cycle, but were not available for supervision.

    -- The Sponsors are apparently wealthy, unsupervised infants who only understand that they want what they want when they want it.

    -- The Developers presumably understand software development life cycle, and have the power to implement some semblance of a system at the behest of the Sponsors, but lack the power to control how that system is implemented.

    The vagueness of the story makes me suspect the storyteller.
  • snoofle 2008-02-14 11:32
    bshock:
    I'm not sure I understand the situation. You have Overlords, Sponsors, and Developers.

    -- The Overlords seem to have some notion of proper software development life cycle, but were not available for supervision.

    -- The Sponsors are apparently wealthy, unsupervised infants who only understand that they want what they want when they want it.

    -- The Developers presumably understand software development life cycle, and have the power to implement some semblance of a system at the behest of the Sponsors, but lack the power to control how that system is implemented.

    The vagueness of the story makes me suspect the storyteller.

    Welcome to corporate america! Sorry to dissappoint but everything was 100% true. I'm literally living it right at this moment!

    What, exactly, would you like to know?
  • Barf 4 Eva 2008-02-14 11:41
    snoofle:
    Barf 4 Eva:
    Damn snoofle... Talk about getting the shit end of the stick!!! Thanks for sharing the rest of the gory details. :)

    I actually like this place. The people are nice, the hours are mostly reasonable and the pay is good. While the system-users could fill this forum with stories for months, the various bosses I've worked for (both in the past the first time I worked here 10 years ago, and today) are very reasonable and flexible, and in all cases, backed me as far as they could.

    As far as dealing with the WTF's, I view it as getting paid to be entertained. It's like watching somebody trying to touch the spinning blade of a circular saw; you tell them not to, they refuse to listen, you can't stop it, you know you shouldn't watch, but you just can't turn away!


    lol, thanks for the laugh snoofle! It's funny, I love the company I work for as well and we've been through the same predicament of constant WTFery. However, for the past couple of years the company seems to be heading in a better direction and when things seem to be looking really good, I decide I need to get out of the state. :P

    Follow your heart, I guess. And good luck on your future endeavors
  • DaveK 2008-02-14 13:51
    nwbrown:
    The sponsors responded that we don't need specifications because it will be done when we don't see any more problems.

    I suppose thats one definition of an 'agile project'.

    I believe you have mis-spelled "asshole".
  • Sigivald 2008-02-14 16:00
    Ouch you missed that AOTS reference, how embarrassing for you.

    Sounds, to me, more like "ouch for assuming anyone knows or cares about any random bit of pop-culture".

    I had to use The Google to figure out what "AOTS" was, and you know what?

    Any reference that assumes I watch G4, or even know what channel it is on my Cable system, is itself a FAIL.

  • Henry Miller 2008-02-14 18:11
    [quote user="snoofle]
    Personally, I gave this analogy: If you go to an architect and say design and build me a house. He will ask: what style (ranch, colonial, ...), how many rooms, etc. If you tell him: just build it, and I'll let you know after I move in, you are not going to get very far. The same applies in software. We were ordered by 3 levels up to do it (with the clear implication: if you want to keep your jobs).
    [/quote]

    I have a friend in construction. In his last house (a 2 million dollar house), he had one window, and a sketch on a napkin of what the customer wanted. My friend spent 2 hours with the architect going over options, and rejecting each one (either because a header would have had to go through the window, or because the roof would sloop such that water would pool someplace and leak in), eventially the architech said "I don't know how to do it, but this is what they want it to look like so make it work." My friend did.

    The next week the electrition came and asked "what is going on, the print shows a wall here, and there is no wall." The builder just said "Ask the framer, we just know it has to be that way."

    End the end it is a solid, well build house, but the requirements in between were make it look right, and pass inspection.

    As an american programmer I'm thankful for projects like this. If specs were nailed down those cheap coders in India can do just a good a job as me (and if you hire just their best they may even be better - though of course India has a lot of people programming who shouldn't). Because the specs are not nailed down I have some important advantages: I speak the same language - including accent - as the customer. I have the same culture as the customer. I work the same hours as the customer. I have a mental model of what the customer needs (not wants - this is often different) and can build to that at first and get 90% of the project working allowing the customer to better see what that last 10% of what he needs is (the parts where I'm wrong about what the customer needs)
  • eldakka 2008-02-14 19:52
    And who is going to "push back"?

    As a techie on the floor, when I say 'this isn't going to work because of yada yada', invariably the response comes back from someone more senior (i.e. a 'manager' who has absolutely no technical experience/skills/qualifications, they just manage...after all, can't any decent manager manage anything, irrespective of the field? at least thats the management theory...) "just do it". Or "that's an architectural responsibility, if they say do it that way then do it that way, you're just the implementers". Same response for "It's a design issue, do what the designers say". You just get into a merry-go round when you are on the sharp end of "it's architecture/design/developers/capacity management/contract management/business analysis" responsibility/issue, not the techie's/sysadmins/deployers problem. Fkin architectural groups. In my experience, the sysadmins at the end of the line, the ones who actually 'run' the systems, deploy the code etc invariably have more practical experience, skills, knowledge than all the other higher level groups combined, and are the ones who see the results of the failures (and generally get the blame or are the ones who have to put in 80 hour weeks with no weekends to clean up the mess) in all the higher level areas and generally can see the flaws and know the fixes, but who do not have the authority to do or often even recommend anything. And as they are 'only' sysadmins, usually any advice or recommendations they DO make are discounted if it conflicts with the more 'senior' architectural/design/development/capacity management etc etc teams.

    Sorry for the rant ;)
  • chris 2008-02-15 03:51

    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 2008-02-15 08:23
    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 2008-02-15 08:26
    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 2008-02-15 10:28
    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 2008-02-15 11:10
    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 2008-02-15 11:42
    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 2008-02-15 16:53
    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 2008-02-15 17:45
    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."
  • real_aardvark 2008-02-16 13:11
    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 2008-02-18 02:43
    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 2008-02-23 14:15
    The real WTF here is that a senior manager didn't blame the devs.
  • M.waqas 2009-10-08 04:44
    Sir i need job