• dtremain (unregistered)

    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 (unregistered) in reply to Trevel
    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 professional obligation 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 how 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 (unregistered) in reply to Dave
    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.

  • (cs)

    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?

  • (cs) in reply to Mike
    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.

  • (cs) in reply to RayMarron
    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 (unregistered)

    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 (unregistered)

    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 :)

  • (cs) in reply to Byteback
    Byteback:
    This is actually not Worse Than Failure.

    Then I suppose it's a good thing the site isn't Worse Than Failure either.

  • (cs) in reply to Richard H
    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.

  • (cs) in reply to Marc
    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?

  • (cs) in reply to reverendryan
    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.

  • (cs)
    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 (unregistered)

    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.

  • (cs) in reply to Trevel
    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 (unregistered)

    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 (unregistered) in reply to vt_mruhlin
    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 (unregistered) in reply to nwbrown
    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 (unregistered) in reply to tk.
    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 (unregistered) in reply to Anders
    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 (unregistered)

    Chuck Norris don't need specs !

  • Royal (unregistered)

    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 (unregistered)

    "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. (unregistered) in reply to Trevel
    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. (unregistered)

    Well, what happens when you code out of specs?

    [image]

    This happens.

  • Rob Baillie (unregistered)

    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 (unregistered)

    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 (unregistered)

    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 (unregistered) in reply to halber_mensch
    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 (unregistered) in reply to Royal
    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 (unregistered)

    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...

  • (cs) in reply to relaxing
    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 (unregistered) in reply to s.

    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.
  • (cs) in reply to Trevel
    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.

  • (cs) in reply to Mateo_LeFou
    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.

  • (cs) in reply to Barf 4 Eva
    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.

  • (cs) in reply to brazzy
    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.

  • (cs) in reply to morry
    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.

  • (cs) in reply to Anders
    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 (unregistered) in reply to snoofle

    Damn snoofle... Talk about getting the shit end of the stick!!! Thanks for sharing the rest of the gory details. :)

  • (cs)

    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.

  • (cs) in reply to Rob Baillie
    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.

  • (cs) in reply to Barf 4 Eva
    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 (unregistered)

    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.

  • (cs) in reply to bshock
    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 (unregistered) in reply to snoofle
    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

  • (cs) in reply to nwbrown
    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 (unregistered) in reply to TheDev

    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 (unregistered) in reply to snoofle

    [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 (unregistered) in reply to Trevel

    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 ;)

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

Log In or post as a guest

Replying to comment #176825:

« Return to Article