• (cs)

    TLDR; Project manager didn't check what tables were in scope for a database project and wildly over estimated timescales.

    Management not knowing any better try to justify the cost without question.

    Seems like a normal day at any big company.

    Edit, Ive been waiting years to say frist, Im not missing my chance now)

  • foo AKA fooo (unregistered) in reply to wonkoTheSane
    wonkoTheSane:
    Ive been analyzing this site for years to develop a plan on how to say frist
    FTFY
  • John (unregistered) in reply to wonkoTheSane

    Hay Wonko,

    You finished building that asylum yet?

  • (cs) in reply to wonkoTheSane
    wonkoTheSane:
    Edit, Ive been waiting years to say frist, Im not missing my chance now)

    Congratulations!

  • (cs) in reply to foo AKA fooo
    foo AKA fooo:
    wonkoTheSane:
    Ive been analyzing this site for years to develop a plan on how to say frist
    FTFY
    So you're saying that Wonko is really Tim?
  • Captain Obvious (unregistered)

    Consultants grimaces

    The company should have consulted either the team that was currently maintaining the database for an estimate or have a competing team do an estimate on how long it would take. The hint that the company was overpaying for these consultants is when one consultant's full time job was keeping the MS-Project (the micro-manager devil's favorite tool) pinpoint accurate.

    Assumptions (and blame) all around: C-Level executives: For not trusting (or commissioning) a in house estimate Consultants: For not clarifying how several strangely named tables are important for the system and clarifying the scope of work Rob: For not asking specific clarifying questions when the 70k hour estimate was delivered to lead the C-Level exes to realize that the estimate is off by 4 orders of magnitude. C-Level executives: For blindly assuming that the Consultants uninformed estimates are accurate and need 100% priority over other commitments.

  • Alistair Wall (unregistered)

    You can't just assume that a table called TMP_65239423756893 is not critically important.

  • QJo (unregistered)

    TRWTF is the decision to get external consultants involved. The rest follows with depressing predictability.

    Even the final section, where Rob is overhearing the mgrs, is not particular WTF-worthy. They've been told to sit tight and wait while Rob goes and gets a more realistic estimate. And so with nothing better to do, they are operating like an idling gear-train, or an uncoupled phase-locked loop; their cage has been rattled, they are frightened, they have nothing better to fill their decision-making processes than the rubbish they have been fed, and so they do the best they can: work with the data they've got for the worst-case scenario: "We know Rob's pretty good at this sort of thing, and I expect he can shave a few hours off this estimate, but what if ...?"

    Might as well treat as a WTF people who argue, weep, wail and write angry letters to newspapers about the happenings in daily episodes of soap operas.

  • Bart Manning (unregistered)

    s/consultant/conslutant/g

  • Bob (unregistered)

    It could be worse. They could have taken the agile scrum approach like we do:

    A product owner has a vague idea of what they want.

    They give a brief summary in planning 1.

    1. The product owner and team lead dictates to the team that any estimate above an 8 is unacceptable.

    2. The developer is expected to just start coding immediately.

    3. Specifications and feature changes are verbally communicated during the morning standup.

    4. Team leads and product owners battle for supremecy during code reviews and if you implement a feature dictated by the one, the other will disagree out of principle. Eventually the developer will advocate some unholy hybrid of the two that just manages to not meat anyones requirements.

    5. When the resulting application gives issues the developer will be accused by the team lead of trying to sabotage his career and the product owner will throw aggressive tantrums and insults at everyone.

  • Bruce W (unregistered) in reply to Alistair Wall
    Alistair Wall:
    You can't just assume that a table called TMP_65239423756893 is not critically important.
    Exactly - one of the things The Daily WTF has taught me is that that table probably controls the North American power grid.
  • Qazwsx (unregistered)

    Anyone with any significant amount of forum experience has had to navigate a topic of some complexity. The only real way to do it is by breaking down the topic into major pages. Then breaking each page into smaller posts and so on, until you have a list of posts that you can reasonably estimate the amount of time that will be required to read. Then you figure in images, see what can be ignored because TDEMSYR, factor in online users, add it all up, pad by as much as you think you can get away with to account for unscheduled derails, misquotations, blakeyrants and general stupidity. Finally, you put it into a textbox and post your presentation to the forum.

    Captcha: wisi. Wisi cared enough to complete the post.

  • Discourse (unregistered) in reply to Qazwsx
    Qazwsx:
    Anyone with any significant amount of forum experience has had to navigate a topic of some complexity. The only real way to do it is by breaking down the topic into major pages. Then breaking each page into smaller posts and so on, until you have a list of posts that you can reasonably estimate the amount of time that will be required to read.

    WRONG.

  • Paley (unregistered) in reply to Alistair Wall
    Alistair Wall:
    You can't just assume that a table called TMP_65239423756893 is not critically important.

    Tables named like that tend to become more important the longer they stick around

  • Geoff (unregistered) in reply to wonkoTheSane
    wonkoTheSane:
    TLDR; Project manager didn't check what tables were in scope for a database project and wildly over estimated timescales.

    Management not knowing any better try to justify the cost without question.

    Seems like a normal day at any big company.

    Edit, Ive been waiting years to say frist, Im not missing my chance now)

    No the TLDR; version is management brought in an expensive outside consulting firm without giving their own people a crack at the problem first.

    Said firm did what most do and sent folks who are in truth probably pretty sharp and experienced in but who don't know the site specific details and may not know the specific tech ie. the database guy they sent is a SQL Server expert and the company runs Oracle.

    The consultants are just as frustrated and annoyed with their firm for sending them on a job they can't possibly do well in the time allowed and are building a ridiculous estimate based on the worst case ("all those temp tables are import to the app") to CYA.

    Management should have enough qualified people on staff with availability to at least design detailed specs and run IT projects. Have the consultants do "the work." I have seen that model work well. I have never seen the bring the consultants in to run the project and let them use internal resources to do it model ever result in anything useful getting done unless its also way over time and budget.

  • (cs) in reply to Alistair Wall
    Alistair Wall:
    You can't just assume that a table called TMP_65239423756893 is not critically important.

    Please try to show some sensitivity. I had a son who was named TMP_65239423756893 and let me assure you it is no laughing matter.

  • Agilista (unregistered) in reply to Bob
    Bob:
    It could be worse. They could have taken the agile scrum approach like we do:

    A product owner has a vague idea of what they want.

    They give a brief summary in planning 1.

    Communicating what information is known, as early as possible is a postive.
    2. The product owner and team lead dictates to the team that any estimate above an 8 is unacceptable.
    Depend, are you talking Story Points for User Stories, or Hours for Tasks. In either case (the former being subject to some scaling) large monolitic estimates are almost invariably better off being decomposed further - at the appropriate time (i.e. not for Initiatives, Goals, or Features)
    1. The developer is expected to just start coding immediately.
    There is always something that can be started. If this was C# then

    int Main(string [] args) { return 0;}

    might be a good start.

    1. Specifications and feature changes are verbally communicated during the morning standup.
    Excellent, identifying that Item #54123 has been posted which contins the details of a proposed chang and needs to be reviewed and prioritized is a valid standup activity
    1. Team leads and product owners battle for supremecy during code reviews and if you implement a feature dictated by the one, the other will disagree out of principle. Eventually the developer will advocate some unholy hybrid of the two that just manages to not meat anyones requirements.
    OK, so you finally identified a WTF.
    1. When the resulting application gives issues the developer will be accused by the team lead of trying to sabotage his career and the product owner will throw aggressive tantrums and insults at everyone.
    Clearly the ALM tooling will have a proper hitory. Regardless of tantrums and insults, the audit trail will speak for itself
  • Pista (unregistered)

    The last phrase of the article is so true and soooo frightening...

  • (cs)

    software development is not same as automobile repair.

  • Bob (unregistered) in reply to Agilista
    Agilista:
    Communicating what information is known, as early as possible is a postive.

    A product owner not understanding their own requirement is definitely not a positive.

    Agilista:
    Depend, are you talking Story Points for User Stories, or Hours for Tasks. In either case (the former being subject to some scaling) large monolitic estimates are almost invariably better off being decomposed further - at the appropriate time (i.e. not for Initiatives, Goals, or Features)

    These are story estimates for major subsystems and as the requirements are unknown at this point they cannot be tasked in any detail.

    Agilista:
    There is always something that can be started. If this was C# then

    int Main(string [] args) { return 0;}

    might be a good start.

    Once again. Coding something functional for a barely considered and unanalysed new system.

    Agilista:
    Excellent, identifying that Item #54123 has been posted which contins the details of a proposed chang and needs to be reviewed and prioritized is a valid standup activity

    No, making shit up as you go along, refining processes and entertaining scope creep as you go along is a CRAP way of developing robust systems.

    Agilista:
    Clearly the ALM tooling will have a proper hitory. Regardless of tantrums and insults, the audit trail will speak for itself

    What, you think any managers in this environment would even dream of putting anything in writing to be held accountable in this environment? Or that any features, specifications or analysis belong anywhere but in their heads? Are you kidding me?

  • Frank (unregistered) in reply to Agilista
    Agilista:
    There is always something that can be started. If this was C# then

    int Main(string [] args) { return 0;}

    might be a good start.

    Yes, because this great starting point adds SOOOOO much "business value". Don't forget to add even more by a unit test to make sure that it's exit code is 0.

  • Project consultant (unregistered)

    Sounds like the consultants were getting ready to make a down payment on some vacation villas in Tuscany...

  • phuzz (unregistered) in reply to Alistair Wall

    It's a security measure, what hacker is going to look in TMP_65239423756893 for credit card numbers? So secure!

  • eric76 (unregistered)

    At one company years ago, we had a PDP-11/70 with the RSTS/E operating system.

    Many of the various application programs created a great many .tmp temporary files. One evening to save space, someone deleted them all when nothing was running and thus needed a temporary file. The next day we all found out that being named .tmp necessarily meant that the file was temporary.

  • eric76 (unregistered) in reply to eric76
    eric76:
    At one company years ago, we had a PDP-11/70 with the RSTS/E operating system.

    Many of the various application programs created a great many .tmp temporary files. One evening to save space, someone deleted them all when nothing was running and thus needed a temporary file. The next day we all found out that being named .tmp did not necessarily mean that the file was temporary.

    Oops. Fixed it.

  • Fred Weller (unregistered)

    Missing the WTF-ness of this. I would much rather give kudos to the management team in that they did something almost unheard of in this business - they listened to the people that were responsible for the project, were trained to be the subject matter experts and, when given information from said team, they didn't just blow it off, rework reality to suit them, cut the hourly estimate in half and said "just make it work or your fired" or any of the other usual management stupidities, they just listened and tried to act on what they were told. That they were given completely bogus information isn't the point - that they listened and just trusted the subject matter experts, is! These "managers" should be cherished as much as any other extremely rare species and given all the help and guidance possible. After all, they listened!

  • (cs) in reply to Bruce W
    Bruce W:
    Alistair Wall:
    You can't just assume that a table called TMP_65239423756893 is not critically important.
    Exactly - one of the things The Daily WTF has taught me is that that table probably controls the North American power grid.
    Is that all?

    It's probably launch codes. For every country on the planet and several extraterrestrial species.

    And it has over six hundred columns, named (not quite sequentially) "fld001", "fld002", etc. All of them CHAR(500).

  • (cs)

    I wonder how defoliation affects the paper-making process.

  • Daniel (unregistered)
    pad by as much as you think you can get away with to account for unscheduled changes, miscalculations, emergencies and management stupidity.

    So true! Best part of the story!!

  • yeahso (unregistered) in reply to Agilista
    Agilista:
    Bob:
    It could be worse. They could have taken the agile scrum approach like we do:

    A product owner has a vague idea of what they want.

    They give a brief summary in planning 1.

    Communicating what information is known, as early as possible is a postive.
    2. The product owner and team lead dictates to the team that any estimate above an 8 is unacceptable.
    Depend, are you talking Story Points for User Stories, or Hours for Tasks. In either case (the former being subject to some scaling) large monolitic estimates are almost invariably better off being decomposed further - at the appropriate time (i.e. not for Initiatives, Goals, or Features)
    1. The developer is expected to just start coding immediately.
    There is always something that can be started. If this was C# then

    int Main(string [] args) { return 0;}

    might be a good start.

    1. Specifications and feature changes are verbally communicated during the morning standup.
    Excellent, identifying that Item #54123 has been posted which contins the details of a proposed chang and needs to be reviewed and prioritized is a valid standup activity
    1. Team leads and product owners battle for supremecy during code reviews and if you implement a feature dictated by the one, the other will disagree out of principle. Eventually the developer will advocate some unholy hybrid of the two that just manages to not meat anyones requirements.
    OK, so you finally identified a WTF.
    1. When the resulting application gives issues the developer will be accused by the team lead of trying to sabotage his career and the product owner will throw aggressive tantrums and insults at everyone.
    Clearly the ALM tooling will have a proper hitory. Regardless of tantrums and insults, the audit trail will speak for itself

    Brillant!

  • haero (unregistered) in reply to Alistair Wall

    We actually have an application called TMP (which does stand for something but the application has changed so much that if we used the full name iut wouldn't make sense to the users) and it does create a lot of records called TMP_reallyLongNumber

  • YellowOnline (unregistered)

    $85/hour for a project manager? Last project manager (an MS Architect, or what's it called) I had around me cost us 20x that!

    Captcha: j'en ai mara

  • (cs)

    Why didn't Rob just drop all the TMP_* tables and ask Mr. Project to update his estimate?

    Side note: It's situations like these that would make a writable INFORMATION_SCHEMA useful. Then the command would just be

    DELETE FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME LIKE 'TMP_%';

  • Captain Obvious (unregistered) in reply to YellowOnline
    YellowOnline:
    $85/hour for a project manager? Last project manager (an MS Architect, or what's it called) I had around me cost us 20x that!
    $1,700 per hour? You overpaid.
  • C-Derb (unregistered) in reply to Bob
    Bob:
    Agilista:
    Communicating what information is known, as early as possible is a postive.

    A product owner not understanding their own requirement is definitely not a positive.

    Agilista:
    Depend, are you talking Story Points for User Stories, or Hours for Tasks. In either case (the former being subject to some scaling) large monolitic estimates are almost invariably better off being decomposed further - at the appropriate time (i.e. not for Initiatives, Goals, or Features)

    These are story estimates for major subsystems and as the requirements are unknown at this point they cannot be tasked in any detail.

    Agilista:
    There is always something that can be started. If this was C# then

    int Main(string [] args) { return 0;}

    might be a good start.

    Once again. Coding something functional for a barely considered and unanalysed new system.

    Agilista:
    Excellent, identifying that Item #54123 has been posted which contins the details of a proposed chang and needs to be reviewed and prioritized is a valid standup activity

    No, making shit up as you go along, refining processes and entertaining scope creep as you go along is a CRAP way of developing robust systems.

    Agilista:
    Clearly the ALM tooling will have a proper hitory. Regardless of tantrums and insults, the audit trail will speak for itself

    What, you think any managers in this environment would even dream of putting anything in writing to be held accountable in this environment? Or that any features, specifications or analysis belong anywhere but in their heads? Are you kidding me?

    More Brillant!

    Bob, you and I may be co-workers because you described my daily work life in great detail.

  • Butthats 4Eva (unregistered) in reply to Alistair Wall
    Alistair Wall:
    You can't just assume that a table called TMP_65239423756893 is not critically important.

    Whatever happened to TMP_IrishGirl123?

    I thought that was a critically important... :(

    But no... Somebody dropped it, and now we are ALL suffering.

  • Nekminnit (unregistered) in reply to QJo
    QJo:
    TRWTF is the decision to get external consultants involved. The rest follows with depressing predictability.

    Even the final section, where Rob is overhearing the mgrs, is not particular WTF-worthy. They've been told to sit tight and wait while Rob goes and gets a more realistic estimate. And so with nothing better to do, they are operating like an idling gear-train, or an uncoupled phase-locked loop; their cage has been rattled, they are frightened, they have nothing better to fill their decision-making processes than the rubbish they have been fed, and so they do the best they can: work with the data they've got for the worst-case scenario: "We know Rob's pretty good at this sort of thing, and I expect he can shave a few hours off this estimate, but what if ...?"

    Might as well treat as a WTF people who argue, weep, wail and write angry letters to newspapers about the happenings in daily episodes of soap operas.
    Uhm, yeap I think that's a pretty major WTF - don't you?
  • xfyk (unregistered) in reply to phuzz
    phuzz:
    It's a security measure, what hacker is going to look in TMP_65239423756893 for credit card numbers? So secure!
    That's just all the transactions associated with card 6523 942 37568 9300
  • Bill C. (unregistered) in reply to chubertdev
    chubertdev:
    I wonder how defoliation affects the paper-making process.
    That was how I made all the papers.
  • (cs)

    I know the old rule about about garbage in garbage out (GIGO) and how putting garbage into a computer ennobles the garbage that comes out.

    I had no idea the same principle worked for project management.

  • Just Sayin... (unregistered) in reply to Bob
    Bob:
    A product owner not understanding their own requirement is definitely not a positive.

    NOBODY knows the requirements of a project at the start of a project, though some are foolish to believe they do. Almost as insane is the idea that detailed requirements which will match reality for an optimal solution at time of delivery can be determined at the start of the project.

    EMBRACING (not just tolerating) chage is a killer mindset for many, but once accepted is immensely powerful.

    fyi: TRWTF is trying to have a serious discussion here - I Know, I know....

  • Bob (unregistered) in reply to Just Sayin...
    Just Sayin...:
    Bob:
    A product owner not understanding their own requirement is definitely not a positive.

    NOBODY knows the requirements of a project at the start of a project, though some are foolish to believe they do. Almost as insane is the idea that detailed requirements which will match reality for an optimal solution at time of delivery can be determined at the start of the project.

    EMBRACING (not just tolerating) chage is a killer mindset for many, but once accepted is immensely powerful.

    fyi: TRWTF is trying to have a serious discussion here - I Know, I know....

    You agile guys are always dealing in extremes and using examples of non-existent problems to make your case. Nobody is saying that your initial analysis has to be perfect right down to pixel perfect UI elements.

    Iteartion and refinement are crucial - they should just be part of a better process and you should have a solid understanding of the system you are developing so that you are iterating and refining, not just making up everything as you go along.

    I've seen major areas of functionality being rolled back and redeveloped at a huge cost which could have been avoided by a systems analyst asking the right person the right question before the first line of code had ever been written.

    There is a huge cost associated with trying to retrofit major requirements to a system half way through development.

  • (cs) in reply to Captain Obvious
    Captain Obvious:
    YellowOnline:
    $85/hour for a project manager? Last project manager (an MS Architect, or what's it called) I had around me cost us 20x that!
    $1,700 per hour? You overpaid.
    It doesn't say that the project manager billed for $1,700 per hour. Maybe it was the cleaning up of the mess he left behind that averaged to $1,700 per hour.
  • Caecus (unregistered)

    The real WTF: Having to read this post twice to realize that snoofle attempted to brng us the double-punch:

    1. The project analyst guy failed to recognize that the TMP tables could likely be ignored

    2. While this was revealed, the managers were continuing to panic over the original estimate.

    What I find disappointing is that Rob and snoofle apparently expected these people to manifest psychic abilities and sense that the original estimate was off by a factor of 10. At least they were looking to tackle the problem, discussing the reallocation of resources, instead of dismissing the issue.

    -Caecus

  • Paul (unregistered)

    Surely that's 'Amazonian'?

  • CigarDoug (unregistered) in reply to DCRoss
    DCRoss:
    Alistair Wall:
    You can't just assume that a table called TMP_65239423756893 is not critically important.

    Please try to show some sensitivity. I had a son who was named TMP_65239423756893 and let me assure you it is no laughing matter.

    I call BS. If you check the history logs, your son's name was shortened to TMP_6523942.

  • (cs) in reply to Bob
    Bob:

    You agile guys are always dealing in extremes and using examples of non-existent problems to make your case. Nobody is saying that your initial analysis has to be perfect right down to pixel perfect UI elements.

    The most effective project I ever worked on (and this is spanning 40 years!) was one in which most of the detailed requirements (functional level - not "pixels") were not known until after 50% of the total codebase was developed. Yes, this is an extreme case and it was also life changing. The company that produced it (I was a consultant)went from being a small privately held company (about $10M in sales) to a public company with over $1B (small scale) because of this one suite.
    Iteartion and refinement are crucial - they should just be part of a better process and you should have a solid understanding of the system you are developing so that you are iterating and refining, not just making up everything as you go along.
    There is a difference between "discovering" and "making up"
    I've seen major areas of functionality being rolled back and redeveloped at a huge cost which could have been avoided by a systems analyst asking the right person the right question before the first line of code had ever been written.
    Asking "the right question" just before the answer is needed is critical. Asking it any earlier is an unnecessary risk.
    There is a huge cost associated with trying to retrofit major requirements to a system half way through development.
    The cost would be higher to delivr something based on the wrong requirements. Were there customer signoffs every sprint on the incremental improvements? If so the maximum "write-off" would have been that sprints work.
  • justme (unregistered) in reply to YellowOnline
    YellowOnline:
    $85/hour for a project manager? Last project manager (an MS Architect, or what's it called) I had around me cost us 20x that!

    Captcha: j'en ai mara

    Can I send you my resume ?

  • Bob (unregistered) in reply to TheCPUWizard
    TheCPUWizard:
    The most effective project I ever worked on (and this is spanning 40 years!) was one in which most of the detailed requirements (functional level - not "pixels") were not known until after 50% of the total codebase was developed. Yes, this is an extreme case and it was also life changing. The company that produced it (I was a consultant)went from being a small privately held company (about $10M in sales) to a public company with over $1B (small scale) because of this one suite.

    That is a great anecdote.

    My experiences go something like this : The fact is that agile, iterative development doesn't reduce the cost of a project and doesn't make it any easier to manage. All you are doing is taking the initial cost of analysis and design and deferring it to extra iterations by the developers, testers (and hopefully analysts) further down the line. Good analysis in the beginning greatly reduces the amount of neccesary "discovery" iterations.

    The problem is that the MBAs see that the costs are staying the same and if anything the quality of the software is going down because all they see in meetings is how the developers never seem to get things right the first time. So the pressure starts being applied on the developers to get it right the first bloody time around, which is downright ridiculous because we don't have accurate requirements to build on. By this time the culture of up front analysis and design is completely dead and the relationship between managers and developers starts deteriorating to the point where it becomes about them and us. Things just get ugly and you start seeing massive staff turnover and managers get more defensive and try to avoid even more accountability.

    Chaos, anarchy, cats sleeping with dogs ensues.

  • chris87 (unregistered) in reply to eric76
    eric76:
    One evening to save space, someone deleted them all when nothing was running and thus needed a temporary file. The next day we all found out that being named .tmp did not necessarily mean that the file was temporary.

    Almost the same here. Somebody removed a file named "a" in temp folder, and next day everyone discovered the website ( of a public company ) collapsed completely without the file.

Leave a comment on “70,000 Hours for Phase I”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article