Slashdot Mirror
Code is Too Hard To Think About (theatlantic.com)
From a longform piece on The Atlantic: What made programming so difficult was that it required you to think like a computer. The strangeness of it was in some sense more vivid in the early days of computing, when code took the form of literal ones and zeros. Anyone looking over a programmer's shoulder as they pored over line after line like "100001010011" and "000010011110" would have seen just how alienated the programmer was from the actual problems they were trying to solve; it would have been impossible to tell whether they were trying to calculate artillery trajectories or simulate a game of tic-tac-toe. The introduction of programming languages like Fortran and C, which resemble English, and tools, known as "integrated development environments," or IDEs, that help correct simple mistakes (like Microsoft Word's grammar checker but for code), obscured, though did little to actually change, this basic alienation -- the fact that the programmer didn't work on a problem directly, but rather spent their days writing out instructions for a machine. "The problem is that software engineers don't understand the problem they're trying to solve, and don't care to," says Leveson, the MIT software-safety expert. The reason is that they're too wrapped up in getting their code to work. "Software engineers like to provide all kinds of tools and stuff for coding errors," she says, referring to IDEs. "The serious problems that have happened with software have to do with requirements, not coding errors." When you're writing code that controls a car's throttle, for instance, what's important is the rules about when and how and by how much to open it. But these systems have become so complicated that hardly anyone can keep them straight in their head. "There's 100 million lines of code in cars now," Leveson says. "You just cannot anticipate all these things."
The problem is that software engineers don't understand the problem they're trying to solve, and don't care to,
Then those software engineers are idiots. Standard for my projects and my teams is, when starting a project, before ever writing a line of code, we try to understand exactly what it is we're trying to accomplish. Work with customers to get requirements, prod the customers to figure out the details they didn't think about and figuring out the best compromises when we have conflicting requirements. Only after we've got a pretty good idea what we're trying to do will we actually start coding.
Yes, there is 100 million line of code in a typical car. This is know for several years. For instance: http://www.informationisbeautiful.net/visualizations/million-lines-of-code/
Why are you pretending he is making shit up ?
Assembly wasn't available right from the start, nor on all systems. I used to work with a couple of NASA subcontractors who talked about when they would code by flipping 8 switches and then pressing a button to push that single byte of code into the computer.
I thought about putting code in quotation marks, a la "code", since it bears little semblance to modern coding, but then I realized that would be an utter and complete disservice to the absolutely herculean effort those people went through back then to build what were in many cases mission critical systems.
Tight code that just does the job and no more can be done, but the writer, or the guy standing over him, has to *deeply* understand the problem, from the inside. Frankly, I think it's easier to teach the problem-expert programming than it is to teach a programmer the problem.
I worked for my local water/sewer utility, first as their IT head, then moved back to my first degree, engineering - but it was my IT that got me the engineering job, which was putting all our pipes, valves and other assets into a giant database that was also a "GIS", a map. We had already for years been switching to mapping with CAD, and had various macros and programs written within its development environment to make, say, placing a hydrant a single graphic operation.
So I got the one contract CAD programmer to greatly expand his "macros" into a comprehensive drafting system where the draftsman first drafted the underlying network, then all the pipes and other assets on top of that; the database understood the connected network and could trace it, analyse flow. The coding from the one former draftsman, who completely understood the drafting problem and the needs of his fellow-draftsman customers hired a couple of young programmers,made sure they were doing what his customers needed, and was done in a year for about $400,000. The IT department charged me much more than that to just supervise him and make sure he "met all corporate standards"!
Well, the IT and Mapping departments hated this software because it ran on top of the CAD package, Microstation. They insisted this was at end-of-life and all mapping was going to an "All-GIS" environment in the 800-lb gorilla of the GIS market, ESRI. They went over me (multiple levels) to get a huge project approved to replace my little $400K amateur effort from a mere engineer.
Long story short, that project peaked at 35 staff, went 3 years, spent $8 million and generated I can't imagine how much code because it was all with Microsoft programming tools that load in whole libraries every time you do anything.
At that point, management realized that it was another $2M-$3M to finish it, and testing showed it would offer no improvements and maybe some slowdowns.
They cancelled it.
My $400,000 CAD software is still there, not yet "end of life" at the age of 20, some 8 years after it was declared good-as-dead. Pity about the lost $8M. What I could have done with that! (There is, by the way, no sign of the whole CAD market vanishing in favour of GIS. Not surprising. Our IT and mapping people also picked Microsoft Silverlight as a winner.)
Whenever I read about giant code messes, I wonder if good, working software for the same problem would be less than a tenth that size. And it isn't bad programmers, it's bad project management. You should never put IT in charge, always their customer. This absolutely requires IT-savvy customers, and these horrors will go on until we get some.