Slashdot Mirror
The Ways Programming Is Hard
An anonymous reader writes "Those of us who spend our days sitting in front of a screen trying to make computers do our bidding know how difficult programming can be. But from an outside perspective, there's not much to indicate difficulty. Most of us have heard somebody compare our job to digging ditches, or some other manual labor, meant to contrast easy (sitting around and typing) versus hard (muscle-wearying work). Now, Peter Welch has written an amusing essay to help combat that point of view, titled Programming Sucks. He compares bridge building to a big software project. Here's a small part of it:
'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. ... 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.' Welch goes on to gripe about all the ways in which programming is almost awesome, but ends up being annoying."
'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. ... 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.' Welch goes on to gripe about all the ways in which programming is almost awesome, but ends up being annoying."
Only complete idiots/tools think this way about any profession. Brick laying looks easy, but I wouldn't trust someone who's never picked up a trowel in their life before to put up a brick wall. Anyone 'outside the profession' should only be concerned that the code works, is maintainable, and is to spec, along with passing a security audit.
He's wrong though.
... Aaaand the customers often buy it :).
Bridge building is more like compiling.
Bridge designing is more like programming/program designing.
And there's the big difference.
Civil Engineering:
Design Phase costs about 10% of Build Phase
Build Phase involves tons of construction workers and heavy machinery.
The blueprints and plastic models are way cheaper to make than the Real Thing.
Management often doesn't mind spending a bit extra to get the design better, because the budget only allows for one big Build.
Software Engineering:
Design Phase costs more than 1000 times the Build Phase.
Build Phase involves the programmer typing "make all" and going to read Slashdot or fetch a coffee.
The plastic models cost as much to make as the Real Thing.
Management often sells the blueprints/plastic models as v1.0 because they compile and "kinda run" and the budget only allows for one big Design...
It should be no surprise then that the plastic models regularly fail.
(Wait, did I just hear you denying that the general) problem of "other peoples' code" is an actual problem?
Because if so, I think you may be the script kiddy in a minimum-wage cubicle farm.
Bonus points for realizing that your own code from three months ago is also "other peoples' code".
This. A billion times this.
Back when I was still programming, i once got a spec sheet written on a post-it. Yes, a post-it. Half of it was a diagram. Ok, granted, that was a VERY special case where everyone involved had a kinda-sorta idea what's going to get programmed and it was by no means very complicated, but it showcases very well the problem.
Later, when I was the one organizing a team of programmers, it was my policy that I get a written and signed spec sheet from the project sponsor. If he can't be assed to write specs, my team can't be assed to write code. And that was when I had the revelation: They don't really know what they want themselves. They only know one thing, they don't want what you will produce. They usually want something akin to a magical box that fulfills their wishes. And sometimes I get the hunch, especially with some of the older stakeholders, that this is pretty much how they view a computer. And programmers are some kind or arcane wizards who make the kettle boil and bubble until the program emerges somehow magically.
They fully expect you to know their needs and usually have a very hard time communicating them because a lot of things that make no sense to you are obvious to them because it's their daily bread and butter. And hence these things will be sorely missing in the specs.
I soon learned that it is a good idea to write the specs together with them if you want a project to succeed. You could tell I wanted your project to fail if I had no time to do that...
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
The article is very funny, and makes a lot of good points, but it's not really addressing the question. It gives reasons software projects are difficult. Not why programming as such is. The engineering part, if you will.
The reason programming is difficult is because it's discrete. Whereas most (all?) other engineering is continuous.
If you try to bend a steel rod, there's going to be a range of strain for which nothing will happen, another where it will flex and recover, another where it will flex permanently, and finally a point where it will fail. This is all contiguous, and you can reduce it to a few numbers that will accurately predict the behavior of identical rods. Depending on the expected load, and the desired behavior, you can then pick the right rod, that will behave the way you need it to, with a good and predictable safety margin, because you know when what will happen.
Software, on the other hand, is discrete. That linked list can behave correctly as you add elements, then remove them, all good, then fail when you remove the last one and it (should) become empty again. There's no hint of that unless you test the very specific condition. There is no failure progression. There is no concept of safety margin.
That's why software regularly blows up. That's why it's difficult to make it not blow up. It's always on the edge.
Clueless psychopathic suits in management, who make impossible schedule demands, and have no programming background themselves.
Yeah, I can feel like that too, sometimes. However, I don't agree with the picture you paint - it isn't the case that all management is always useless and harmful and all engineers are always competent and beneficial, but so completely restricted in their options that they can't write good code. Most managers in most IT companies are in fact willing to listen to sensible advice and make concessions that make life easier for their staff; after all, a manager's success is measured by how well his team as a whole does, so a successful manager is likely to be one who is able and willing to communicate with his employees. But it only works if the employees are able and willing to communicate facts to the manager in a language he can understand and use to make sensible decision with; and engineers are notoriously bad at doing that.
The use of popular, but garbage programming languages. C++, PHP and Perl are probably the main three culprits here. ...
There is an old saying that goes something like: Don't blame the tool for bad craftsmanship. If you are a good programmer, then you can write good code in any language that you know - COBOL, FORTRAN, ... Haskell, C, C++, ... - even Intercal. The problem with some languages is that they demand much more of the developer - using C++ well requires a much higher level of theoretical understanding of good design than using a simple language like C, so it is much easier to loose your way in obscure and misunderstood constructs in C++.