Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
Software Programming IT Technology

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."
This discussion has been archived. No new comments can be posted.

Code is Too Hard To Think About

Comments Filter:
  • FFS this again? (Score:5, Insightful)

    by avandesande ( 143899 ) on Monday October 02, 2017 @10:10AM (#55292115) Journal
    It's lousy requirements, fickle customers, bad environments and tools. The code is the easy part.
    • Don't forget the expectation that everything worth doing should be doable in about an hour.
    • 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.

      • 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)

        • 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

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

    • This is a favorite thing to say and an easy way to get modded up. The reality is that, if we understand something well enough to have solid requirements, there probably isn't a lot of value in the software and, even if there is, it probably already exists. High value software lets us create systems that increase our understanding of the underlying problem and, therefore, generate new requirements. Anybody can go out and re-implement a linked list. Create a good platform for something and it will spark c
  • by Rockoon ( 1252108 ) on Monday October 02, 2017 @10:10AM (#55292117)
    "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: (Score:2, Interesting)

      by Anonymous Coward

      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 ?

    • by havana9 ( 101033 )
      A Chevrolet Corvair, Citroen 2CV, a Fiat 130 Coupé or a VW T1, I suppose.
    • by billrp ( 1530055 )
      That's right, there isn't just 100 million lines of code, it's more than 150 million lines. This probably includes all libraries and OS fully expanded. Google is your friend for finds LOC in cars, eg http://www.thedrum.com/opinion... [thedrum.com]
    • by Kjella ( 173770 ) on Monday October 02, 2017 @10:31AM (#55292307) Homepage

      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"

      • by Anubis IV ( 1279820 ) on Monday October 02, 2017 @10:57AM (#55292523)

        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.

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

    • by Kenja ( 541830 )
      Clearly they should have said there are 1,000 KLOCs! I miss the 80's computer terms...
    • Well, I have a bunch of programming books in the trunk of my car, and there's probably at least a few million lines of code in there. Maybe he was talking about my car.
    • "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.

    • by gweihir ( 88907 )

      What do you think makes your car entertainment system crash and your navigation system hard to use? Fairies?

  • by xxxJonBoyxxx ( 565205 ) on Monday October 02, 2017 @10:11AM (#55292131)
    If you think "code is hard", then maybe SlashDot isn't the right site for you.
    • Re: (Score:3, Insightful)

      by gweihir ( 88907 )

      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.

    • I wrote a 'hello world' program in javascript. Now where can a professional programmer like me get a drink around here?

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

    • by computational super ( 740265 ) on Monday October 02, 2017 @11:17AM (#55292715)
      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.
    • 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.'

      • by Jaime2 ( 824950 )
        But that's not really true. I've written code for problems that I intimately understand. Anyone that's written code for coders has. 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. But, the problem isn't expressing it in code - the same problem will exist no matter what representation you try to give it.
        • by Kjella ( 173770 )

          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)

    by Anonymous Coward

    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.

    • by gweihir ( 88907 ) on Monday October 02, 2017 @10:19AM (#55292191)

      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.

      • Well, I do very well both sides of the problem: Programming and most of all types of business/logic/engineering/etc problems that they throw at me, usually it is easy to find the correlations between the real world and machine instructions. But I am an artificial intelligence working for the government so I guess my case may not count =/.
        • by gweihir ( 88907 )

          Well, there are people that can do both. Just not a lot. And some have peculiar other issues, like thinking they are an AI ;-)

      • The most effective programming in my group comes from pairs of an analyst and a developer and have worked together for a long time. I think of it like a spotter/sniper team.
        • by gweihir ( 88907 )

          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.

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

      • I can't count how many times I've heard other programmers suggest that obtaining requirements from stakeholders is like "pulling teeth". I get the analogy, too, because I feel the same way when I try to get somebody (who's paying me to write a program for them!) to tell me what the program is supposed to do. My best guess as to why this is is that the stakeholders usually think that the "business driver" is so obvious it can't be explained or that you should already know all this stuff, and they go into a
    • 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

    • 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?"

    • 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'.

  • by gweihir ( 88907 ) on Monday October 02, 2017 @10:14AM (#55292155)

    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.

    • by hyc ( 241590 )

      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]

      • by gweihir ( 88907 )

        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

    • by Wrath0fb0b ( 302444 ) on Monday October 02, 2017 @11:07AM (#55292599)

      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.

      • by gweihir ( 88907 )

        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

    • 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

  • 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.
    • by DarkOx ( 621550 )

      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

    • by gweihir ( 88907 )

      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

    • by ranton ( 36917 )

      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

  • 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.
    • by 605dave ( 722736 )

      First hammer analogy!

      • Can someone please do a Hummer analogy now?

        • by MagicM ( 85041 )

          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.

    • by PPH ( 736903 )

      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.

  • by bogaboga ( 793279 ) on Monday October 02, 2017 @10:18AM (#55292183)

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

    by Murdoch5 ( 1563847 ) on Monday October 02, 2017 @10:18AM (#55292185)
    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.
    • by jez9999 ( 618189 )

      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. :-)

      • ... and the way every single manager I've ever had expected me to do it was wrong, too. "Why aren't you typing? Programmers should always be typing! Get to typing!"
      • 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.

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

  • Should be the real title. Eg, POTUS can easily start a nuclear war, here are the directions: https://www.bloomberg.com/poli... [bloomberg.com]
  • Let me guess (Score:4, Insightful)

    by 110010001000 ( 697113 ) on Monday October 02, 2017 @10:33AM (#55292313) Homepage Journal
    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.
    • 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?

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

  • 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!).

  • 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

  • by 140Mandak262Jamuna ( 970587 ) on Monday October 02, 2017 @10:47AM (#55292425) Journal
    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.

  • 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

    • 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

  • Since the invention of hexadecimal. It was such a pain, working with all those 1's and 0's on your screen. Lots of cutting and pasting to get anything done. People looking over your shoulder at your screen couldn't tell what you were doing, though, so browsing for porn at work was easier.
  • by computational super ( 740265 ) on Monday October 02, 2017 @11:01AM (#55292553)

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

  • by guruevi ( 827432 ) <`evi' `at' `evcircuits.com'> on Monday October 02, 2017 @11:06AM (#55292591) Homepage

    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.

  • 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

  • After attempting to read through the 100 million lines of article I gave up around the point where they started talking about writing flowcharts to represent code. But they did mention this was connected to a Kickstarter project called Light Table (which apparently somehow inspired Apple's Swift??). So I watched the kickstarter video ( https://www.youtube.com/watch?... [youtube.com] ) and the kickstarter page ( https://www.kickstarter.com/pr... [kickstarter.com] ) and I still don't have a clue what it is, what is new about it, or how it
  • 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...

  • "Why do we pay IT, everything is working without their help." "Why do we pay IT, nothing is working". Sub in developers for IT. YMMV.
  • Yes programming is difficult. Being creative logically, understanding the big picture and where the project is going, being able to get lost for hours in your head and staying focused as your tracking variables and flowing data ya, it’s hard. It’s also exactly why this silly notion that “everyone needs to learn to code” is simply asinine and coding boot camps are a lie. Different people have different skills
  • 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

  • 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

  • by rbrander ( 73222 ) on Monday October 02, 2017 @12:54PM (#55293877) Homepage

    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.

  • by Koreantoast ( 527520 ) on Monday October 02, 2017 @03:41PM (#55295559)
    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.

An age is called Dark not because the light fails to shine, but because people refuse to see it. -- James Michener, "Space"

Working...