Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Monday July 01 2019, @07:32PM   Printer-friendly
from the You-Thought-Your-Builders-Were-Bad dept.

Stories about seriously mangled public infrastructure projects keep coming up and even the alleged super-efficient Germans are not exempt. But what would you expect when you change and expand the project while it is being implemented and when you use smaller contractors with no track record for projects like this? the BBC has the story:

As a structure, it looks impressive enough.

Until you pause, look around you, and absorb the silence. This is Berlin Brandenburg or BER, the new, state-of-the-art international airport built to mark reunified Germany's re-emergence as a global destination.

It is a bold new structure, costing billions, and was supposed to be completed in 2012.

But it has never opened.

BER has become for Germany not a new source of pride but a symbol of engineering catastrophe. It's what top global infrastructure expert Bent Flyvbjerg calls a "national trauma" and an ideal way "to learn how not to do things".

[...]Martin Delius, a former Berlin city politician who later headed an extensive inquiry into what went wrong, says those in charge decided "to give 30 to 40 contracts to smaller companies which they thought they could pressurise into giving them lower prices".

"They built a very complex controlling system which didn't work," he says.

Most disruptive of all were decisions to change the size and content of the new airport - while it was being built.

[...]New construction boss Hartmut Mehdorn made a list of all the faults and failures, Mr Delius tells me.

"Small ones like the wrong light bulbs to big ones like all the cables are wrong," he says.

The final total was 550,000 - more than a half a million problems to fix.

Maybe that builder who left a big hole in your dining room wall for a couple of weeks wasn't so bad after all? It wasn't like seven years later, was it?


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 3, Interesting) by Anonymous Coward on Tuesday July 02 2019, @05:41AM (4 children)

    by Anonymous Coward on Tuesday July 02 2019, @05:41AM (#862290)

    So .... you'd rather build something, specified to the n'th degree? I've been there.

    Here's how it goes:

    First you have six months (if you're lucky) of getting requirements defined. And boy, do those business analysts get that right. Hell, yeah. They will march up to your desk, having worked all night, and slam down a document that's all of four hundred pages, plus another seven hundred of appendices detailing everything from accessibility requirements through auditing facilities and legal review systems down to the sequence of steps for HA failover in case of a hurricane. (Those of you who think I'm exaggerating have never worked in this kind of environment. Lucky bastards.)

    Now the architectural wrangling begins in earnest. Sure, it already grumbled before, but now the gloves come off. Program managers, project managers and assorted other organisers float around, trying to work out what needs to be done, and in what order, so that they can build the tightly specified GANTT chart from hell. If you're lucky, it's only 6 feet of tight printout taped to the wall. In the mean time, the list of specifications grows. If you're smart, you have a document repository complete with SharePoint admins and a DBA managing the madness - but hey, you're a professional, right? We have to know what we're doing. And now we're a year in without having cut so much as a single module of code, but that's what you need to do it right!

    Now the grind starts, and immediately you run into the imponderables, the unreviewed assumptions and the shifting grounds. The unions want a new contract, complete with changing requirements. The management have a new buzzword, and want a different DB because a saleshole convinced them it was necessary. The activist shareholders need it to be otherkin friendly because what are you, a NAZI??? No, of course you're not, you're a professional and you're cranking that code like the good little hamster you are. Oh, and the federal regulations governing it all have changed three times since you've started, and show no signs of stopping. Don't want to comply? That's OK, they can't make you comply - but they sure as hell can make you want to. The project managers are sweating blood, updating those charts and projections, and what would have been a nice, simple 2 million dollar project is now headed for 4 million dollars because management doesn't want it to take an extra three years, and you have to hire every hired gun available in the market, regardless of whether or not they have a felony record. Or maybe they wanted non-felons? That'll cost you extra, bub.

    Again, if you think I'm exaggerating, you haven't been there.

    But you're not one for those fancy-schmancy agile fads, no sir, you stay the course! And as one deadline slips into another, and the project managers start to change from irish coffee to Wild Turkey of a morning, the pressure mounts. 50 hours a week, 60 hours a week, why aren't you working on Sunday? Are you lazy? Do you want the project to fail? Where do you think you are, Google? No, sir, we're old school! Death marches are there to cull the weak! And now we waterfall down to the QA stage. And the bug reports start rolling, while (it's been years, folks) the technologies on which you bet the project start to EOL. You swear at the vendor, but they just shrug and point to their roadmap.

    No matter, you soldier on, squashing bugs and praying that fresh ones won't manifest with every commit ... and then the users get to see it.

    What the fuck is this? We didn't ask for this! We never wanted this! It doesn't do anything we care about, can we please, PLEASE go back to the old system? This sucks rotting zombiecock, the devs spent, what, five years producing this? My nephew in middle school could have shit better code over a weekend! The company spent five, no six million dollars on this? Why?

    ... if you think I'm exaggerating, oh MAN do I have bad news for you...

    But, you know what? Never mind. Agile is evil, we can all agree on that. They hardly specify anything! How can you get quality from that?

    Starting Score:    0  points
    Moderation   +3  
       Interesting=2, Informative=1, Total=3
    Extra 'Interesting' Modifier   0  

    Total Score:   3  
  • (Score: 2) by Rupert Pupnick on Tuesday July 02 2019, @01:03PM (1 child)

    by Rupert Pupnick (7277) on Tuesday July 02 2019, @01:03PM (#862363) Journal

    This is a great illustration of why engineering program management positions are something I avoid. Every PM I’ve ever worked with was held to a high degree of a accountability, but had absolutely no control over personnel or strategic decision making. When headcount becomes an issue, these guys are among the first to get the heave ho.

    • (Score: 2) by VLM on Tuesday July 02 2019, @02:12PM

      by VLM (445) on Tuesday July 02 2019, @02:12PM (#862388)

      This is a feature, not a bug. They can "interface" with middle management all day and act as a meat shield to absorb and deflect incoming away from the engineering department.

      I know it seems bizarre to implement human labor to prevent management mistakes, it seems like it would be cheaper/simpler to get better management, but its the weird world we live in...

  • (Score: 2) by VLM on Tuesday July 02 2019, @02:21PM (1 child)

    by VLM (445) on Tuesday July 02 2019, @02:21PM (#862392)

    You missed some aspects, like its "impossible" to coordinate 500 medium expensive developers so we'll pay them a severance bonus to train their 5000 replacements who will be utterly uncoordinated and non productive, then we'll hire like 50 super expensive local devs to rescue. I make a lot of money off that scheme.

    Another hilarity is a shocking percentage of managers have no idea how to run a business. Consider... restaurant business, if the manager is a moron his idea of dumping a quarter pound of salt on every steak will pretty much be ignored in an overall high level sense by the system self correcting. But in precise technical software development, the morons rule more efficiently and if they want everyone to use edlin.com as an IDE, or use bubblesorts for all sorting, or use no version control, or use email for bug tracking, etc, those dumb ideas will be efficiently enforced to the detriment of the project. Other fields of business involve dumb managers having less control of micromanaged processes, so they're more successful than strongly controlled fields like software dev. If some moron in management at McDonalds could successfully enforce the exact muscle movements of flipping a pattie, then McD would be as much of an epic fail as any software project or airport or whatevs. What if the biggest moron of a MBA had total and utter control of the smallest tiny detail of every medical procedure, we'd be better off with going back to leeches in that case.

    • (Score: 0) by Anonymous Coward on Tuesday July 02 2019, @09:55PM

      by Anonymous Coward on Tuesday July 02 2019, @09:55PM (#862549)

      Yeah, it's impossible to cover all the immense fuckups that we can find within soylent's text limitations. The morons who disbelieve every word that Brooks ever wrote are just one aspect of it.

      One recent challenge I faced was outright sabotage from devs who somehow thought that death marches would be preferable to Agile - presumably they were more excited about the devil they know, than the reverse. Managed to get them around by pointing out that management had a choice between two options (because of politics, long story) and the options were: Agile and (some approximation of) DevOps, or layoffs and contracting a firm of indian IT people who promised the impossible for a song and dance. Faced with the alternative, precisely none of them left the company, and all of them decided to embrace an Agile system.

      Surprisingly, none of them broke legs or caught cooties from Agile. Instead, after a couple of months of learning the ropes, they actually started to produce. Outsourcing averted!