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

[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?

[gweihir]

Or maybe you have never written any piece of code that actually had to solve a real problem and was not just simple business-logic.

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.

Re:What's the point of this article?

[gweihir]

If your critical thinking/programming skills are up to par, all you need is an honest interest in what it is you're programming for.

And I disagree on that. Rather strongly in fact. I am not talking about algorithms you can copy from a book or find in your run-of-the mill libraries. And I am certainly talking about related issues like cache-awareness, doing your own custom memory management, doing good privilege-separation on the architecture side, understanding side-channels, etc. Most coders just scratch the very surface and then mistakenly think they are good at it.

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.

Re:Not "too" hard, just hard

[Wrath0fb0b]

Spoken like someone that has never actually worked on a variety of complex projects with different amounts of legibility.

There are any number of things that a talented team will do to make code much easier to work with: consistent interfaces, explicit contracts, thoughtful modularity, high-level documentation, intuitive log/trace functionalities, unit tests*, etc. Conversely, there are all kinds of traps that make a complex project much more difficult to work with: spaghetti code, completely lack of diagnostics, tight coupling that makes unit testing impossible, principle-of-most-surprise.

Don't get me wrong, there is absolutely such a thing as special talent. But the more I've worked with software, the more I realize that this talent consists of building complex things in understandable & predictable ways. The real superstars are the ones that build frameworks that merely-good programmers can understand and use to build upon. These things absolutely make a huge difference. The better the design/implementation, the less talent is needed to build on top of it with messing things up.

And by the way, this was kind of supposed to be the point. We were supposed to throw open the benefits of computing to everyone. That requires more work to make languages/frameworks readily understandable to the less talented and less of the view that only the elite should code and more of the view that the elite are needed to build the foundation for others to use.

* Actually, one of the hidden benefits of unit testing, besides forcing you to create generic interfaces that can be mocked/stubbed out, is that it provides an instant way to learn about a component of the system. Don't know how foo works, run the unit test and watch it work. Want to know the contract between foo and the rest of the system, look at the pre/post conditions the tests are asserting.

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.

Let me guess

[110010001000]

Visual programming is the "answer"? Every decade some non-programmer discovers visual programming and says we are all going to be creating programs by dragging blocks around. No, I didn't bother to RTFA.

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.

Requirements, not coding, at heart of article

[Koreantoast]

I think this quote from the article said it best:

“Typically the main problem with software coding—and I’m a coder myself,” Bantégnie says, “is not the skills of the coders. The people know how to code. The problem is what to code. Because most of the requirements are kind of natural language, ambiguous, and a requirement is never extremely precise, it’s often understood differently by the guy who’s supposed to code.”

My reading of the article is that it's not coding itself that's the problem, we can do that, the problem is that we're struggling to develop requirements for more and more complicated systems. As systems become more flexible and their environments more variable, it's becoming harder to write them.