Code is Too Hard To Think About (theatlantic.com) 397
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."
FFS this again? (Score:5, Insightful)
Re: (Score:2)
Re: (Score:2)
My favorite is:
IT ONLY TOOK 2 SECONDS TO THINK, WHY DOES IT TAKE 6 MONTHS TO WRITE?!
Re: (Score:2)
It's lousy requirements, fickle customers, bad environments and tools. The code is the easy part.
Far too often the process from requirements to software engineering takes the form "Ready, fire, aim".
They develop and THEN they try to figure out what was needed.
Re: (Score:2)
Half the time it is the end customer doing Fire, Aim, Ready. Rinse and repeat for Continuous Bugs (see current tagline, your mileage may vary in 2022)
Re: (Score:3)
Half the time it is the end customer doing Fire, Aim, Ready. Rinse and repeat for Continuous Bugs (see current tagline, your mileage may vary in 2022)
I dunno. Most of the time, what I've seen, is programmers and project managers just not bothering to get things clear with the customer because that takes too long and they seem to think it's better to get those (expensive) programmers working ASAP.
They don't like having meetings, they don't like getting people around a table to hammer out the issues and make sure the task is clear, because on the one hand they don't really like socialising (and meetings are social activities) and, on the other hand, they f
Re: (Score:2)
It's lousy requirements, fickle customers, bad environments and tools. The code is the easy part.
The worst point is when they change their mind 6 months into the project how it should work and expect it to not delay your initial estimate.
It would be like telling a contractor you wanted to build the Empire State Building, but 6 months in telling them you want the Burq Khalifa instead... and not expecting delays.
Re: (Score:2)
Obviously bullshit statement there (Score:5, Insightful)
No, there isn't. So this guy, criticizing, is making shit up in order to do it.
Whats he selling?
Re: (Score:2, Interesting)
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 ?
Re:Obviously bullshit statement there (Score:5, Insightful)
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.
Re: (Score:2)
Tossing out the "100 million lines of code" in reference to the overall technical complexity of modern cars is fair.
I'm not sure it is, since there shouldn't be anything in a car actually technically requiring 100 million lines of code.
Re:Obviously bullshit statement there (Score:4, Informative)
"I didn't bother counting, but I doubt there were more than 10K LOCs in the Apollo code, "
Well, you're wrong. Way off, actually.
Code is available here: https://googlecode.blogspot.no... [blogspot.no]
Here are some crude stats (from a source tree I know nothing about...)
[boa@localhost trunk]$ for i in Artemis072 Colossus2* Comanche055 Luminary* Solarium055; do printf $i; find $i -name \*.agc | xargs wc -l | grep total; done
Artemis072 64444 total
Colossus237 62565 total
Colossus249 64223 total
Comanche055 65585 total
Luminary099 65058 total
Luminary131 63217 total
Solarium055 30074 total
[boa@localhost trunk]$
Re: (Score:3)
Linux kernel alone is ~20 million lines? That probably accounts for the largest section of code by itself!
Re: (Score:2)
Re: (Score:3)
Re:Obviously bullshit statement there (Score:5, Insightful)
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 (Score:5, Interesting)
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 (Score:4, Informative)
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.
That wasn't uncommon for early personal computers either. Try this in-browser simulations:
Kenbak-1 Emulator [neocomputer.org]
MITS Altair Simulator [s2js.com]
Re: (Score:2)
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"
Maybe he's been looking over the shoulders of programmer's who have been looking at xRodent instead of working and when they saw him coming they opened notepad++ and started typing 10010100101011100 to make him go away.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
"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.
He meant to say there's 100 million lines of coke in cars now. You know those party-animal Detroit workers.
Re: (Score:2)
What do you think makes your car entertainment system crash and your navigation system hard to use? Fairies?
What's the point of this article? (Score:4, Insightful)
Re: (Score:3, Insightful)
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? (Score:4, Insightful)
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.
Re: (Score:2)
I wrote a 'hello world' program in javascript. Now where can a professional programmer like me get a drink around here?
Re: (Score:2)
I wrote a 'hello world' program in javascript. Now where can a professional programmer like me get a drink around here?
Someone will be along to tell you the secret location of the Mountain Dew bar soon. The location will be scribbled on the back of a Magic the Gathering card with a Cheetos stain in the upper right corner.
Re:What's the point of this article? (Score:5, Insightful)
Re: (Score:3)
If you think "code is hard", then maybe SlashDot isn't the right site for you.
Its not about 'code being hard', its about 'code obscures the problem and shifts the focus away from solving the underlying problem and onto solving the coding problem.'
Re: (Score:3)
Re: (Score:3)
The real problem is that most problems are really hard to fully specify. As soon as you start to code it, you begin to realize how hard.
The problem is not that the problem is hard, it's that the user doesn't understand why their specification is woefully incomplete. Like if you asked them how to walk they'd probably say "Well put one foot in front of the other, duuuh" but tell a robot to do that it'll fall with a big thud. Then they'll say "Well you got to keep your balance, duuuh". And you'd tell the robot to do that and it won't get anywhere because it started to lift one foot, realized it was out of balance and put it back down again. An
Then they're idiots (Score:2, Interesting)
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.
Re:Then they're idiots (Score:5, Insightful)
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.
Re: (Score:2)
Re: (Score:2)
Well, there are people that can do both. Just not a lot. And some have peculiar other issues, like thinking they are an AI ;-)
Re: (Score:2)
Re: (Score:3)
When you work on the same areas long-term so that you can have analysts that stay a long time, then that is a pretty good solution.
Re: (Score:2)
Only after we've got a pretty good idea what we're trying to do will we actually start coding.
And many, many times that would read as "never".
Re: (Score:2)
Re: (Score:2)
I actually know quite a few people in IT (Shocking I know!) in all sorts a various areas, and the one thing that distinguishes them from your average person is insatiable hunger for knowledge.
While I am sure there are those that only want to code, the majority (vast??) want to understand the problem so that they can actually code more effectively and efficiently. Understanding the problem they are coding for makes it easier to code for exceptions (there are always exceptions) and around potential pitfalls.
T
Re: (Score:2)
Then those software engineers are idiots
Yeah, but there are lots of them. When I try to get somebody to explain the actual problem they want me to solve, they don't even seem to understand quite what I'm trying to get at - mostly because their past experiences with programmers has consistently been "where should the buttons and drop-downs go?"
Re: (Score:2)
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.
I'm guessing that you aren't using agile then? Because it sounds like you are actually doing 'Ready, aim, fire' instead of 'ready, fire, aim'.
Not "too" hard, just hard (Score:5, Insightful)
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: (Score:3)
They might have what it takes, but particularly in the US, their abilities were not trained up and refined.
https://www.cs.utexas.edu/user... [utexas.edu]
Re: (Score:2)
Well, most do not have what it takes. But it is certainly true that of the few that do have it, many are lost to coding because of an inadequate education system and bad job prospects. I mean these people are smart. Many of them will not go into coding when they can expect to have low job security, a bad salary and being treated badly. At the same time a small number of really good coders can often replace hundreds of mediocre and bad ones. Due to bad management in most larger companies, nobody seems to hav
Re:Not "too" hard, just hard (Score:4, Insightful)
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: (Score:3)
Oh, I have. Your Ad Hominem is entirely misplaced.
And note that you require a "talented team". That "talented team" is not any of "tools, languages, coding-styles, etc.". It is people that know what they are doing and that take care to structure and document it as well as possible. This requires intelligence and creativity.
Incidentally, I disagree about the frameworks. They often hide too much. One of my main scopes is security and frameworks are one of the worst problems, because coders do not understand
Re: (Score:2)
Exactly.
To illustrate, I am an ocean modeller (or climate modeller). Climate models are typically large and complex. But most of the time I am very aware of what problem I want to solve. Of course, there is a whole lot more in the code than the basic equations that you may and should have written down at some time before actually implementing your model, but you work on a small part of the code, a part that you understand thoroughly. Sometimes numerical and system design schemes go above my head, but lu
Re: (Score:3)
Yes, that too. Here is another gem: https://www.schneier.com/blog/... [schneier.com]
It is both though.
Re: (Score:2)
No, it's not "thinking about code" that's hard. THINKING is hard. And most people are incapable or unwilling to do much of it.
Two days ago I was at a McDonald's that had newly installed touch screen kiosks for ordering. I saw people give up and wanting to leave without ordering anything because selecting their food and confirming their order was too difficult for them. They complained to the cashiers, who then had to help them enter their order. If people are too lazy to learn how to order a burger, how does anyone expect them to learn coding?
No, that's the whole point; coding is nothing like actual thinking.
Coding is more like doing math than it is like thinking.
Re: (Score:2)
And how do you do math? By doing push ups?
When the problem being solved is mathematical in nature, you're going to need to know some math, or else you're not going to be able to solve it, be it on a piece of paper or in code.
Re: (Score:2)
Re: (Score:2)
The problem with all those abstractions is at a basic level there is an underlying assumption each class (not exactly in the OOP sense) of thing follows certain rules. To make effective use of those abstractions you have to understand those rules really really well. Otherwise you end up with lots of code on top so to speak patching(not in the insert at some offset sense) things.
It still "looks" clean to anyone not popping open the abstraction but what it really is, is doing one thing here and than undoing
Re: (Score:2)
Indeed. You cannot abstract complexity away. You can hide it, often with really bad effects, but it will still be there. The only cases were abstraction makes things easier is if the complexity was created by a bad tool and is not inherent to the task being solved. You will always need to understand that task in order to create an adequate solution. And if that task is complex and cannot be simplified, then the solution must necessarily be complex too. Of course, a major talent for any good engineer is the
Re: (Score:3)
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 muc
That's EXACTLY what turn me on about it (Score:3)
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.
Re: (Score:2)
First hammer analogy!
Re: (Score:2)
Can someone please do a Hummer analogy now?
Re: (Score:2)
To me, it's a machine or tool. Like a Hummer. Use a Hummer 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.
Re: (Score:2)
To me, it's a machine or tool. Like a hammer.
This.
But it's a tool to be used by the system engineer. That's the person with the domain expertise necessary to produce the requirements, design the hardware and integrate and test the system. Having to hand requirements to coders is like being a carpenter and cutting all the boards. But then having to call the hammer group to come in and put it all together.
I think there's something missing here... (Score:4, Informative)
"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..."
Stupid Topic (Score:5, Informative)
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: (Score:2)
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.
Shit, looks like I've been doing it wrong all these years. :-)
Re: (Score:2)
Re: (Score:2)
I know, right? Who doesn't cut and paste the master code into the IDE and then start deleting and renaming parts of it, and moving stuff around? Far easier than this thinking and planning stuff.
Re: (Score:2)
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.
You aren't using Agile, are you.
Re: (Score:2)
I am, but I sure as hell prefer waterfall. See tagline.
"Some things are hard to think about" (Score:2)
Let me guess (Score:4, Insightful)
Re: (Score:2)
Every decade some non-programmer discovers visual programming and says we are all going to be creating programs by dragging blocks around.
I've been using the same one for the last decade. They're great. What is your issue with them? Or if you have a problem with them do you also have a problem with compilers?
Well, yeah (Score:2)
We haven't solved the hard AI problems necessary to make computers think like us, so we have to think like computers in order to program them, and we're not good at it. This is news?
If Architects designed buildings... (Score:2)
like programmers wrote programs, the first woodpecker that came along would destroy civilization.
Sorry that's the only (hopefully funny) comment I could come up to contribute (and I didn't even come up with it, I read it somewhere in pre-Internet time!).
Rule of Generation (Score:2)
Developers should avoid writing code by hand and instead write abstract high-level programs that generate code. This rule aims to reduce human errors and save time.
Which is why we've been abstracting away the hard bits for a while now. We're not manually flipping in digits. We made punch cards, automated punch cards, compilers, and higher level languages.
I couldn't imagine doing non-linear control algorithms with C or assembly. Did simple PIDs in college, understand how to do it and just let Simulink write the DO-178C and MISRA 2012 code for me. It's already certified for critical code.
It's also easy to build a plant model to unit test against and add in SIL/MIL/HIL l
No, the problem is coding is just too new. (Score:5, Insightful)
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.
What would be different? (Score:2)
I read the article on Friday and remember how it was trying to propose some kind of other way to visualize the behavior of code, and thought it was pretty cool idea. Then I remembered the first anecdote in the article about how a 911 calling system crashed because the unique ID's hit their max value. If one were to create a visualization of the system, it would still show "green" for when the system hit their max value for unique ID's. So I don't think that the solutions proposed fixes the problems at all.
I
But the key is, over time... (Score:2)
I read the article on Friday and remember how it was trying to propose some kind of other way to visualize the behavior of code, and thought it was pretty cool idea. Then I remembered the first anecdote in the article about how a 911 calling system crashed because the unique ID's hit their max value. If one were to create a visualization of the system, it would still show "green" for when the system hit their max value for unique ID's. So I don't think that the solutions proposed fixes the problems at all.
I
Coding is so much easier... (Score:2)
And it's getting worse (Score:3)
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."
If code is too hard to think about (Score:5, Insightful)
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.
complexity will lead to different techniques (Score:2)
In about 100 years, the codebase of most simple appliances will start to resemble the size of the entire genetic material for a small insect. While no human can possibly think about the entire DNA sequence for even a simple creature, we start to think of which alleles can be switched "on" or "off" and cut and paste sections using CRISPR from related codebases. This is the ultimate in "script kiddie" hacking, but that's where we are with complex code like genetics, and that's where we will be with manmade
This is connected to a Kickstarter project (Score:2)
I don't even see the code (Score:2)
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.
All I see it blonde, brunette, redhead...
Sounds Similar to the IT Conundrum (Score:2)
Bootcamp morons (Score:2)
Possible software is hitting a complexity limit? (Score:2)
I wonder if the existing method of writing software isn't just running into the limits of general human cognition.
We can conceptualize complex systems or tasks, but to make software that does them requires a very low level of understanding of how it will work and gluing together many low-level functions to get to the finished complex system.
Fixing a system like this when it doesn't work as expected requires an encyclopedic level of knowledge about all of the low level pieces as well as the larger picture of
Flamebait to declare "we don't care to" (Score:2)
The problem is that software engineers don't understand the problem they're trying to solve, and don't care to
I thought the article had some issues but this one really made me mad... I have worked with scores of professional developers who indeed spent a LOT of effort trying to understand the domain (problem) we were writing software for, most of them would push back on requirements that made no sense for "solving the problem" when we knew it would hinder (or at least not help) users.
Also on a sidenote, the
Lack of understanding inflates code (Score:4, Interesting)
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.
Requirements, not coding, at heart of article (Score:4, Insightful)
“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.
Re: (Score:2)
This confused me at first as well. Once you've been in the community and built up your karma you may be asked to moderate at some point. For me it just kind of showed up one day as a pull down under each comment. As I have moderated over the years it seems like I am offered the chance more frequently. Probably because I actually do pay attention and try to moderate in a helpful way. Note, now that I have commented on your comment I can't moderate anything in this discussion. That's to prevent me from modera
Re: (Score:2)
I write code for the gov and the hard part is when the bug is in the law. The bug might have not been obvious to lawmakers, but when I write my if-else it becomes dead obvious. It is hard because
A) I know what I'm doing is wrong, but I have to do it, because it is written into the law
B) There is no bug tracker where I can submit bugs in the law.
You could perhaps consider providing an example of what you're talking about. Without a concrete example, your submission is anemic I am afraid.
Re: (Score:2)
Lawmakers are what happens when people think their written word defines reality. Alternatively they start writing holy books, which is even worse.
Re: (Score:3)
Hehehehe, it also solves the problem of what language to make fun of ;-)
Re: (Score:2)
..chose what?
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
These were not really computers in the modern sense. No capability to run general-purpose code. Also, if I remember correctly, they basically had people doing the job of an assembler between the coders and the machines. Might even be were the name comes from.
Re: (Score:2)
Well, I have when doing I/O to specific hardware components. But that is about it. For actual code, I always had at least an assembler.
I do agree that the stance of the article is mostly BS, also because you _cannot_ think like a computer. Computers are exceptionally dumb in a very fast fashion. No human can think like that. Smart humans can think in a smart and complex fashion pretty slowly. That is nothing alike computers.
Re: (Score:2)
Ah, yes? The only point of that was marketing and some politicians simulating being "modern" anyways. And some nice rip-off-type business models for "coding schools".