• (nodebb)

    Not only weren't the business users fired, but they got big bonuses for handling the disaster that they had created.

    ...which is exactly the wrong lesson, because it will happen again and again and again.

    Addendum 2018-05-23 06:48: Because they won't have learned the thing the frist time.

  • Sally Flynn (unregistered)

    This article perfectly sums up everything wrong with modern IT projects.

  • That nerd guy (unregistered)

    It's not necessarily a lack of spine that stops some developers saying No to insensible requests, it can be a lack of experience causing a blind faith in those telling them what to do being "the right thing", or even worse a lack of caring if they're doing "the right thing" as long as they get a paycheck at the end of the day.

  • Tim (unregistered) in reply to That nerd guy

    Or they might have done what I would probably do under the circumstances - explain to the business user in writing exactly why their idea was stupid, get their approval then just do it their way and sleep easy knowing you've done all you can. it's not the same as not caring, and it's probably better than refusing point blank or quitting.

  • Kashim (unregistered)

    If you can't tell your boss, or your boss's boss, or your C-level execs "No, that is a ridiculous method and you shouldn't do it." without getting fired then either a) you need to take a class in proper communication, or b) you need to move jobs anyway.

    Just gotta speak the language of business: "These are the problems you are GOING to encounter. Here is the use-case where it happens. Here is where it will go wrong because of human error, and Here is how much it will cost you to fix. On the other side, Here is how much it will cost you to do it this other way, that I've outlined over Here, and Here are some other benefits to it.

    The thing I wish I had learned during my CS degree: How to present a cost-benefit analysis to a boss. I had to pick it up in-situ while explaining to my boss exactly why we should all be using SSDs instead of platter drives.

  • Bored (unregistered) in reply to Kashim

    Kashim, your idea - in a perfect world - would work. But sadly we live in this one.

    I once worked in a software shop that was housed in a building that suffered periodic brown outs. We would lose work every time. I put in requests for battery backups, which were ignored. I documented the frequency, and that was ignored. Corporate asked us every couple of years what upgrades we would like? I told them battery backups every time, and was ignored. I made a spreadsheet detailing downtime vs. typical engineering salaries multiplied by the number of engineers working, and how much each brownout would cost the company. And put those numbers vs. the cost of battery backups, and how long it would take for the investment to be returned. Which was ignored.

    I know how to present, too. I was the engineer they would send out to train people on our software. I've done presentations with Q&A to rooms full of engineers and managers and always got good marks.

    TL;DR - you can't fix stupid.

  • OldCoder (unregistered)

    I cringed when I read the first list.

    Item 7, Take backups, has to be item 2! I would also ensure that a backup was taken afterwards.

  • Loren Pechtel (google) in reply to Kashim

    If you can't tell your boss, or your boss's boss, or your C-level execs "No, that is a ridiculous method and you shouldn't do it." without getting fired then either a) you need to take a class in proper communication, or b) you need to move jobs anyway.

    Just gotta speak the language of business: "These are the problems you are GOING to encounter. Here is the use-case where it happens. Here is where it will go wrong because of human error, and Here is how much it will cost you to fix. On the other side, Here is how much it will cost you to do it this other way, that I've outlined over Here, and Here are some other benefits to it.

    This assumes the boss is interested in listening.

    It's your job to write the code to avoid the downside.

  • Bill T (unregistered) in reply to Loren Pechtel

    If your boss isn't interested in listening, then (b) run, don't walk, to another position.

  • Mark (unregistered)

    How would anybody involved in writing this story know about them getting bonuses? That part smells made-up (or assumed, pick your synonym for lie). The rest is great, though.

  • code_goddess (unregistered) in reply to Loren Pechtel

    If your boss won't hear you out, then that would be Kashim's b) condition.

  • marcodave (unregistered)

    Imagine if civil engineering was handled like IT Development Projects, without all the laws, the regulations and the safety measures. Yeah, fortunately, nobody is that stupid*

    • https://www.telegraph.co.uk/news/worldnews/europe/italy/3101377/Venices-new-4m-Grand-Canal-bridge-injures-tourists.html (from 2008)
  • I Am The Very Model (unregistered) in reply to Sally Flynn

    Unfortunately this isn't just confined to modern IT projects. I've seen similar WTF stuff-uppery going back to my early coding days in the '90s, and worked with coders who were saying the same things from their early days

  • TerryK (unregistered) in reply to I Am The Very Model

    This sort of thing has been going on for decades. I'm reminded of the official 1970's procedure to back up a Diablo 44 disk drive (which had a 5MB removable cartridge on top of a 5MB fixed platter) if there are no other disk or tape drives available.

    You will need:

    1. 2 blank Diablo 44 cartridges
    2. Lots of system downtime
    3. Nerves of steel and a proven ability to avoid being distracted

    Procedure:

    1. Remove production cartridge, install blank backup cartridge A
    2. Copy fixed production to backup A (bottom to top)
    3. Remove backup A and label it "backup of bottom half", install original production cartridge
    4. Copy removable production to fixed (top to bottom)
    5. Remove production cartridge, install blank backup cartridge B
    6. Copy bottom (copy of production removable) to top
    7. Remove backup B and label it "backup of top half", install backup A
    8. Copy top to bottom
    9. Remove backup A, install removable production
    10. Hold breath and attempt to boot system

    Since this is the only disk drive in the system, it isn't possible for the system to tell you what to do - you have to keep track of it yourself. This would be done nightly, or perhaps weekly. Of course, fumbling a step meant that you probably didn't have to do any more backups for a few days, since you'd still be recovering the data you erased by accident.

    Some users tried not using the top half, so they could backup simply by copying the bottom to the top and then putting in another top cartridge, but 5MB was not a lot of space on a 32- or 64-terminal minicomputer - in my case, I upgraded from the 10MB Diablo 44 [Data General 4234] to a 192MB "washing machine" [Data General 6061]. But the system also had a tape drive, so almost all backups were to 1/2" 9-track tape and not disk-to-disk.

  • Zenith (unregistered) in reply to Loren Pechtel

    And when you write the code to avoid the downsides, they slap you with nonsensical "best practices" they copped from the back of the same box of Captain Crunch their degree came in.

    Option B is really the only option.

  • siciac (unregistered) in reply to Tim

    I think even in small organizations, if you genuinely think something is a bad idea, a professionally worded, written explanation is the best way forward.

    One problem with this attitude of this article is that it pits developers as "us" and the managers as "them." In fact, there are rivalries between managers. If one of the other execs had a written explanation that this would all blow up after it did, the culprit might not have walked away with a bonus.

  • DrPepper (unregistered)

    Not only weren't the business users fired, but they got big bonuses for handling the disaster that they had created.

    Hey, I can create a disaster and fix it, and I don't need broken business processes to do it. And I can do it in less than a day. Do I get a bonus on top of the bonus if I complete my work in less than 4 hours? Contact me if this sounds like a service I can perform for your company.

  • Fnord (unregistered) in reply to DrPepper

    No, thanks, we have identified creating disasters as our core competency.

  • Zenith (unregistered) in reply to siciac

    "Professional" is usually code for "tell me how great my idea is and how smart I am for coming up with it." Anything else seems to be interpreted as a dare to keep playing with fire. I'll find another job somewhere else, thanks.

  • eric bloedow (unregistered)

    If you need to see inside of a gas tank, throwing a lit match into it will illuminate the inside, but you probably won't like how it works out for you...i read a story on The Darwin Awards website where someone actually did that! the resulting explosion sent him through the roof!

  • Anonymous (unregistered) in reply to Kashim

    Sorry, some of us don't have time to write up a detailed analysis because, unlike executives, we actually have shit to do.

    In fact, we have more shit to do than is even remotely feasible to complete on any given day.

    But no, keep talking about how adding even more shit to that pile is going to help.

  • Ben (unregistered) in reply to Kashim

    I've always found it comes down to approach. If you have the right approach (as outlined) you have much better success. Real problems lead to these kind of arcane "solutions". The right answer is never cheaper up front to build but almost ALWAYS insanely cheaper the first time an issue occurs.

  • (nodebb) in reply to Mark

    How would anybody involved in writing this story know about them getting bonuses?

    Just because you leave a company doesn't necessarily mean you sever all ties with the people who are still there. If you have friends working there who know why you left, they might well let you know the outcome. And if the business users were perceived as the heroes that saved the day, they might well have received public recognition for doing so. Bonuses in my company are awarded publicly, with an accompanying explanation, so I can certainly see this as plausible.

  • Utruk (unregistered)

    This is what frequently happens on my current job. First, when somebody provides a ridiculous solution, I try to resist, but I am told by the business/management and even sometimes senior developers 'We can't afford doing a right thing right now because we are short on resources/time/money/etc. We will do this in a quick and dirty way now. If in the future we have resources/time/money/etc then we will think about doing this right way'. Needless to mention that when the future comes there is no resources/time/money/etc and the amount of the resources required to refactor an inefficient/wrong solution increases as there are dependencies and data in it. Then I quietly wait until it fails and when it fails we spend even more time to fix the consequences of that bad solution.

    I am actually looking for a job because I am tired of seeing this circus.

  • (nodebb) in reply to Utruk

    There's never enough resources/time/money/etc to do it right, but there's always resources/time/money/etc to do it over.

  • Z (unregistered)

    Seems all made up, but if it wasn't the whole mess is the direct consequence of the Author's actions:

    "We all just cringed, made like good little HPCs and followed our orders to march onward."

    No need to blame others.

Leave a comment on “Business Driven Development”

Log In or post as a guest

Replying to comment #:

« Return to Article