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."
It's lousy requirements, fickle customers, bad environments and tools. The code is the easy part.
love is just extroverted narcissism
"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?
"His name was James Damore."
If you think "code is hard", then maybe SlashDot isn't the right site for you.
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.
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
To me, it's a machine or tool. Like a hammer. Use a hammer this way and it does something. Use it another way and end up with bruised fingers. It all seemed so simple and transparent and obvious . I just groked it, long before the concept of grok, and I could not for the life of me understand why other people couldn't get it.
What intensified that was the need to read and memorize about a zillion IBM and FORTRAN manuals. That also appealed to my obsessive ADHD side, long before the concept of ADHD. Add the extra ego brownie points when I could describe some obscure feature or function call to the instructor or one of the advanced calculus students and it was a match made in heaven.
The Russians have won. They have made the world a cesspool of distrust, greed, fear and hate.
"The problem is that software engineers don't understand the problem they're trying to solve, and don't care to,..."
I think they do understand the problem and that's why things generally work, or don't they? I think they do work on the whole.
The reason is that they're too wrapped up in getting their code to work.
To this, I must rephrase:
"The reason is that they're too wrapped up in getting their code to work, as they should..."
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.
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.
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.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
IDEs ... did little to actually change, this basic alienation
As far as I can tell, although they do make the day-to-day job of programming computers much easier (and yes, I did start coding before there were any IDEs), they've made things worse in terms of expectations. Even as getting programs correct is getting harder, the people who don't do it are looking at the tooling and the support, and the how simple the very basic stuff is, and thinking, "this looks easy, therefore it must be easy, therefore if this guy can't get it done in a couple of hours, the only possible explanation is that he's incompetent."
Proud neuron in the Slashdot hivemind since 2002.
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.
Custom electronics and digital signage for your business: www.evcircuits.com
Hehehehe, it also solves the problem of what language to make fun of ;-)
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Any experienced programmer will know very well that abstraction does not always make better solutions. The sad truth is that complex problems usually require complex solutions.
Not sure what you are trying to say here. Obviously even the worst programmer will likely know that abstraction will not always make a better solution. Nothing always makes a better solution. But nearly 100% of code (likely at least 99.999999%) has significant abstractions. You probably cannot even use modern processors without numerous abstractions within the processor itself which you cannot control or even see in the documentation. Even when they do have complete control they probably aren't spending much time thinking about the actual movement of the electrons in those processors, but instead enjoy using a different level of abstraction.
Abstractions can cause problems, but on average I'd guess they solve trillions of potential problems for every problem they cause.
I would change what you said to: Experienced programmers will generally know what abstraction level they should be working at when designing and implementing their solutions. They will also be better than most at determining when they were wrong and need to start investigating in a different level of abstraction.
-- All that is necessary for the triumph of evil is that good men do nothing. -- Edmund Burke
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.
I've been working on CRUD-centric applications since before the GUI era. And I wonder why we keep reinventing CRUD systems? Most of the "logic" COULD be defined as attributes, such as data dictionaries, and relatively simple "rule tables" that are kept in the database. These could handle roughly 95% of the logic, and most the rest could probably be put in stored procedures to make them app-language-change-proof.
I've seen products that kind of come close, but they get tossed out when the shiny New Thing comes along and kills sales or momentum. People are so scared of being left behind that they throw everything out and start over to keep up with the IT Joneses. I don't really blame them: agism is real and ugly in our industry.
I agree the front-end style keeps changing, such as going from CUI to GUI to Web to mobile etc., BUT most of the principles of CRUD have not changed. Do we really have to throw out the entire CRUD engine to get the latest front-ends?
Techniques like MVC were supposed to separate front-end issues from the rest, but as implemented I fail to see it. They often do or assume data joins in code instead of the database, for example. That's stupid; whey reinvent the database? And they often rely on "scaffolders", which are code generators. If you are relying on an attribute-centric CRUD model, then you don't need to generate app code. Generating code means you failed to abstract ideas into attributes and are implementing low-level attribute handling in app code instead of reading/processing them directly from the attribute/rule tables. They automated bloat, not removed it. (Sure, you'll still need to generate client-side code, such as jquery handlers, but it could be at run-time.)
Maybe CRUD is not as exciting as aerospace and thus has none of the modelling tools and abstraction languages mentioned in the article. It has a reputation as being too simple, which is not really true. Dealing with customer expectations, databases that have built up a lot of tangled cruft over the years, and adapting abstract representations to changing UI fashions is often not easy.
Table-ized A.I.
“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.