- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
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.
Admin
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.
Admin
...And they were delicious!
Admin
sounds like a cash-cow for contractors though. why run away?
Admin
Sponsors getting their full measure of comeuppance?
heart.getCockles().setWarm(true);
Admin
Admin
Beat me to it. Nice to see the right guy getting the blame for a change.
Admin
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.
Admin
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.
Admin
Admin
Welcome to my life RIGHT NOW, I really need to start looking for a better place to work.
Admin
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)
Admin
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?
Admin
Ashamed or proud of what? I'm not sure I know what you're refering to.
Admin
Admin
EPIC FAIL ...
Admin
EPIC ... FAIL ...
Admin
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.
Admin
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!
Admin
thanks... for... adding... nothing... to... the... conversation..., twice... even...
Admin
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.
Admin
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.
Admin
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 :)
Admin
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.
Admin
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".
Admin
Admin
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.
Admin
Transposition of question word and subject. This penalty is declined. Illegal use of commas. 10 yard penalty. Repeat 1st down.
Admin
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.
Admin
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?
Admin
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.
Admin
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.
Admin
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"?
Admin
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.
Admin
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.
Admin
"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!
Admin
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.
Admin
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....
Admin
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.
Admin
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.
Admin
Referring != Adding
Admin
Admin
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!
Admin
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.
Admin
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.
Admin
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.
Admin
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?
Admin
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.
Admin
So what happend? don't leave us hanging like that.
/spoken like a true boss
Admin