SoylentNews is people
SoylentNews
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?
(Score: 5, Interesting) by Rupert Pupnick on Monday July 01 2019, @08:46PM (12 children)
There’s also a perception that standards based, modular and highly integrated technology reduces complicated tasks to snapping together Legos. It doesn’t.
(Score: 2) by JoeMerchant on Monday July 01 2019, @09:02PM
Hey, those managers had Legos as kids, it always worked that way for them...
https://www.bricklink.com/v2/catalog/catalogitem.page?S=2922-1#T=S&O={%22iconly%22:0} [bricklink.com]
Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end
(Score: 4, Interesting) by goodie on Tuesday July 02 2019, @01:48AM (4 children)
I read this while taking a break from writing a paper on how modern software development practices and technologies make things more complicated rather than simpler than they used to. Of course our software do more than they used to but our dependence on others (whom we have no idea of often) and our ignorance of the ramifications of this increasing dependence make things very complex (as in complexity science too!). Happy to know I'm not crazy to think this... Now I just need reviewers to stop thinking it's not cool enough because it does not drink the kool aid.
Ok back to work now, full of motivation again :)
(Score: 3, Interesting) by VLM on Tuesday July 02 2019, @02:09PM (3 children)
Given the culture of this site please submit an article when you complete the paper. Assuming we don't have to subscribe to journal "X" to read the paper, etc.
I've been in this game since '81 and my gut level impression is trying to eliminate complexity is like squishing a balloon, it just squooshes out somewhere else, typically somewhere unpredictable always somewhere more expensive. Older more "unix" ways of doing things were small simple tools and that let the complexity live elsewhere, like in the architecture of systems using the tools or ... well, somewhere other than the small elegant code, anyways. Capitalism and non-FOSS require vertical silos to increase profit so all software no matter how small the original scope eventually poorly re-implements emacs and has a checkbox list of unused features thats multiple pages long. That requires complexity in the code and crashes dev projects with no survivors. The "solution" is to squoosh the complexity balloon to push complexity out of coding into absurdly complex ritualistic development systems that have generally never been successfully implemented in any other complex developement technology (like major military ops or construction projects or non-computer research projects). Needless to say squooshing the complexity balloon to send complexity shrapnel screaming thru the dev trenches causes worse problems and delays that the original problem.
On one hand, I'm pessimistic because of the analogy that medicine will never work because we're at the level of leeches and that was stupid, or heavier than air flight is impossible because no mechanic has successfully cloned every detail of a really giant seagull. On the other hand I'm pragmatic in the sense that no level of effort will ever make mechanistic astrology "work" as its critics explain, or no amount of religious purity law implementation will "trick" god into obeying a mere human.
(Score: 2) by All Your Lawn Are Belong To Us on Tuesday July 02 2019, @02:58PM (1 child)
A system always grow more complex, until/unless something more simple (and genuinely original) is able to replace it. I think that transcends development into all forms of systems theory. If you're a believer in evolutionary theory, this isn't always a negative. I'd rather be me than an ameoba (although some would question if there is a difference...)
Complete replacement, however, is often more effort than maintenance of the prior system, or transformation of the prior system which but seldom actually reduces the complexity and instead only redistributes it.
Personally, I blame entropy.
This sig for rent.
(Score: 2) by goodie on Tuesday July 02 2019, @06:47PM
That's the thing that is so fascinating to me. Software is really now the product of series of uncoordinated moves by heterogeneous groups of actors working on their own thing and using one another's artifacts to build something of their own. And the process repeats itself over and over...
Where it gets ugly is when you see that we have little to no visibility on what we depend on. When the heartbleed vulnerability was discovered, everybody freaked out because they suddenly realized that one of the most critical pieces of software they depend on was maintained by two (I think?) overworked people. Yet so many products depend on it.
Same with refactoring. If we use stuff like structural complexity measures, we can reduce it through refactoring. But if the refactoring involves using other frameworks, dependencies, etc. our own code might have low structural complexity but the code that we depend on might be crap. But we won't see that because we will depend on the packaged version 99% of the time. Same principle with microservices: low complexity, limited scope. But pieced together they can create a huge mess of interdependence. Why do you have a dependency on an XML parser? Because the devs from a dependency 4 levels down did not remove it when they moved to JSON. Or something like that...
(Score: 2) by goodie on Tuesday July 02 2019, @06:41PM
If it ever gets accepted somewhere, i'll pay the open access fee if there is one. Thank for the vote of confidence!
(Score: 0) by Anonymous Coward on Tuesday July 02 2019, @03:09AM (5 children)
It does if what you are making does not change what it is half-way through. It's all the "Agile" and "Innovation" that ruins complicated projects. The standards change, module definintions change, and everything is always tryign to hit a moving fucking target.
(Score: 3, Interesting) by Anonymous Coward on Tuesday July 02 2019, @05:41AM (4 children)
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?
(Score: 2) by Rupert Pupnick on Tuesday July 02 2019, @01:03PM (1 child)
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
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)
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
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!