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."

Comments

FFS this again?

[avandesande]

It's lousy requirements, fickle customers, bad environments and tools. The code is the easy part.

Obviously bullshit statement there

[Rockoon]

"There's 100 million lines of code in cars now"

No, there isn't. So this guy, criticizing, is making shit up in order to do it.

Whats he selling?

Re:Obviously bullshit statement there

[Kjella]

You got that far? My bullshit meter overflowed when he started ranting about binary instead of assembler which they've had from the very beginning as simple text substitution...

Anyone looking over a programmer's shoulder as they pored over line after line like "100001010011" and "000010011110"

Re:Obviously bullshit statement there

[Anubis IV]

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.

Re:Obviously bullshit statement there

[michelcolman]

I would bet most of it is in libraries. We need to display this little triangle widget on the screen... ok, found it in this 100 MB library, so we'll just include it and move on to the next problem. Programming is easy!

There's no way you actually need 100 million lines of code to control a car.

What's the point of this article?

[xxxJonBoyxxx]

If you think "code is hard", then maybe SlashDot isn't the right site for you.

Re:What's the point of this article?

[computational super]

Hmmmm.... well, hang on - I don't think this is what you meant, but you seem to be implying (and certainly a non-coding reader would infer from reading your comment) that code is actually easy. Code IS hard, and it takes a lifetime of discipline to master, and when actual, human safety is on the line, it should absolutely be left in the hands of experienced professionals.

Not "too" hard, just hard

[gweihir]

At least not too hard for everybody. But the simple plain fact is that thinking about code above a certain minimal complexity requires special talent. Tools, languages, coding-styles, etc. make no real difference.Those that do not have it ( probably something like 95% of all people) should stay away from professional coding. Incidentally, the same applies to mathematical thinking and reasoning, for example. Nothing surprising here, just too many people writing code that do not have what it takes.

Stupid Topic

[Murdoch5]

Before a single line of code hits the IDE, you plan out what you're trying to solve, the problems you have to deal with, and how the logic will have to act. Coding happens after the "hard" work has been done, once you have a good idea of what has to be done and how to do it.

If anyone thinks that a true software engineer just sits down, starts slamming on some keys and then says "Oh well, I wrote code, let's see how the throttle handles it", then they don't understand software development or software engineering.

Re:Then they're idiots

[gweihir]

Same here. But I see tons of people that either only understand the problem but cannot code or the other way round. Of course there are also people that suck at both. The fact of the matter is that only a small number of people can both code well (including understanding design, architecture, performance, security and reliability) and can understand the application problem well at the same time. Of course the latter is with the help of the customer or user, but even that seems to be too hard for many coders.

It is not laziness or unwillingness, IMO, it is simple inability. And people that can do one of these things well cannot be called stupid by any sane measure either. The problem of doing both things well is just very, very hard.

No, the problem is coding is just too new.

[140Mandak262Jamuna]

At the start of industrial revolution, since around 1750 approx, lathes were turning out nuts and bolts. But you needed to buy a matched set of nut and bolt. There were no standards, no interoperability between nuts and bolts from different manufacturers. At around 1840 a man named Whitworth painstaking collected nuts and bolts from various manufacturers, found the most common thread profiles and published a "Whitworth thread profile". This eventually became British Standard thread profile, and almost all the nuts and bolts we take for granted came from that standardization.

Software is still in that era. Each machine built then was made from the scratch, with custom built parts. There were no standard off the shelf components then. We still don't have a standard reliable gui that can be assumed to be supplied by the OS in linux. Windows guarantees a mouse/screen but it can't even give multiple customizable desktops in 2017 Windows 10.

If I am designing an electric motor, I don't have to worry about the anchoring bolts. I know the power and torque and weight of what I am shooting for. I will simply pick from well tested components library a set of four, six or eight bolts with known tensile strength, corrosion resistance, temperature profiles, cost and provide for holes large enough for the anchor bolts. If I am designing the controller for the same damned electric motor, every interaction the motor has with the micro processor that controls it is custom made. Several device control muPs each with its own protocol for data, feedback and error handling.... If I am designing a mortgage consolidation program for the asset management of a bank, every data feed I get, every data output, feedback, and error handling is custom built. That is why software reliability is poor, security holes are ill understood and development is insanely complex.

Having said that, we have made great strides in standardization. File IO within a system, of https requests across the network is getting standardized. XML is helping a lot. Entrenched players deliberately mess up interoperability with ulterior motives. But as the end users become more and more aware of switching costs and vendor locks, eventually these things will dry up and interopera bility will improve.

Well tested, well understood components are the key to building large, complex but reliable machines. We are getting there. Serious computation is a mere 60 year old technology. Hardly two and a half human generations, coping up with 45 generations of computational technology evolution. It will take a couple of human generations before we have senior managers who grew up with technology who would not fall easily for the sales tricks and demand real tested true interoperability and well tested well understood components.

If code is too hard to think about

[guruevi]

You shouldn't be in the field of software development. Whoever uttered that statement should be fired from any programming related job.

It does require a special sort of insight (eg. being able to keep track of state and thinking much more abstractly about computers than what you're used to) which can be both acquired or natural but is only improved by practice but it's by no means impossible to think about code and what it will end up doing. In most cases, programmers have thought about ways the program can fail (eg. buffer overflows) and either think it's no big deal (it will never get connected to the Internet) or have to give up finding solutions for it due to lack of time or funding.