'You are an expert in all these technologies, and that's a good thing, because that expertise let you spend only six hours figuring out what went wrong, as opposed to losing your job.'
April 30th, 2014
Imagine joining an engineering team. You're excited and full of ideas, probably just out of school and a world of clean, beautiful designs, awe-inspiring in their aesthetic unity of purpose, economy, and strength. You start by meeting Mary, project leader for a bridge in a major metropolitan area. Mary introduces you to Fred, after you get through the fifteen security checks installed by Dave because Dave had his sweater stolen off his desk once and Never Again. Fred only works with wood, so you ask why he's involved because this bridge is supposed to allow rush-hour traffic full of cars full of mortal humans to cross a 200-foot drop over rapids. Don't worry, says Mary, Fred's going to handle the walkways. What walkways? Well Fred made a good case for walkways and they're going to add to the bridge's appeal. Of course, they'll have to be built without railings, because there's a strict no railings rule enforced by Phil, who's not an engineer. [Multiple additional constraints, pet ideas and poorly described extraneous features omitted – see original post for the full, hideous and hilarious set…] After the introductions are made, you are invited to come up with some new ideas, but you don't have any because you're a propulsion engineer and don't know anything about bridges.
Would you drive across this bridge? No. If it somehow got built, everybody involved would be executed. Yet some version of this dynamic wrote every single program you have ever used, banking software, websites, and a ubiquitously used program that was supposed to protect information on the internet but didn't. […]
In all fairness to programmers everywhere, this is at least as much about how programming is organised on large-scale projects ((And in particular how the specifications are arrived at long before anyone gets to write a single line of code as it is about issues resulting from programmers' proclivities.