Programming is hard

One of the answers to my “controversial opinions” question on Stack Overflow claims that “programming is so easy a five year old can do it.

I’m sure there are some aspects of programming which a five year old can do. Other parts are apparently very hard though. Today I came to the following conclusion:

  • If your code deals with arbitrary human text, it’s probably broken. (Have you taken the Turkey test recently?)
  • If your code deals with floating point numbers, it’s probably broken.
  • If your code deals with concurrency (whether that means database transactions, threading, whatever), it’s probably broken.
  • If your code deals with dates, times and time zones, it’s probably broken. (Time zones in particular are hideous.)
  • If your code has a user interface with anything other than a fixed size and a fixed set of labels (no i18n), it’s probably broken.

You know what I like working with? Integers. They’re nice and predictable. Give me integers, and I can pretty much predict how they’ll behave. So long as they don’t overflow. Of have an architecture-and-processor-dependent size.

Maybe you think I’m too cynical. I think I’m rather bullish, actually. After all, I used the word “probably” on all of those bullet points.

The thing that amazes me is that despite all this hardness, despite us never really achieving perfection, programs seem to work well enough most of the time. It’s a bit like a bicycle – it really shouldn’t work. I mean, if you’d never seen one working, and someone told you that:

  • You can’t really balance when it’s stationary. You have to go at a reasonable speed to stay stable.
  • Turning is a lot easier if you lean towards the ground.
  • The bit of the bike which is actually in contact with the ground is always stationary, even when the bike itself is moving.
  • You stop by squeezing bits of rubber onto the wheels.

Would you not be a touch skeptical? Likewise when I see the complexity of software and our collective failure to cope with it, I’m frankly astonished that I can even write this blog post.

It’s been a hard day. I achieved a small victory over one of the bullet points in the first list today. It took hours, and I pity my colleague who’s going to code review it (I’ve made it as clear as I can, but some things are just designed to mess with your head) – but it’s done. I feel simultaneously satisfied in a useful day’s work, and depressed at the need for it.

19 thoughts on “Programming is hard”

  1. I don’t know if you intended it to, but I don’t think that your post rebuts the claim that programming is easy. Each of the domains that you mentioned is certainly not easy to deal with, but the problems (to my mind) are related to those domains (sometimes inherently, sometimes due more to historical baggage) rather than programming per se.

    I think that the problem is that although a professional programmer often needs to deal with the thorny issues you’ve raised, I don’t consider them “programming” in the pure sense.

  2. I agree that they’re inherently hard – but I count that as part of programming in every *practical* sense.

    Put it this way: a programmer who could do the “pure” stuff but couldn’t make even a stab at any of these wouldn’t be much use as a professional developer.

  3. I agree with your sentiment, and I apologize if I’m just arguing semantics, but I think that the distinction between “programming” and “professional software development” is important. I think that if more developers mentally separated the task of modelling the real world (the hard part) and implementing that model using the programming language of their choice (relatively easy, though not without its own challenges), the industry would be in better shape.

    In particular, I think that too often when teaching people to be developers, we fail to explicitly teach the skills required to do the hard parts, but expect them to somehow pick the knowledge up from reading real-world code. This makes “programming” look harder than it really is (because people are actually trying to pick up both the programming language as well as design patterns for representing messy real world concepts). At the same time, it doesn’t give people the right mindset to approach profession software development, because the design patterns are often completely implicit in the code they read, and there’s no discussion of alternative designs and the tradeoffs that would make one design favored over the other.

  4. I agree and you could also add this to the list:

    – If your code needs to run in any kind of security context it is probably broken.
    – If your code uses any resources where non-trivial clean-up is needed it is probably broken.

  5. Ideally, the moment anyone starts writing floating-point code, trumpets should sound and a giant paperclip should descend from the sky on a pillar of fire, asking “Are you sure you want to do that?”

    All of the others require using some sort of API, and generally (hopefully) when you look up the documentation for the API you’ll get some sort of warning as to the hazards of misuse. You might not pay attention, you might not understand, you might not care. But you had a fair chance to be appropriately warned. But you can get yourself into a horrible mess with just the floating-point built-in types and operators (especially ==) in most languages, without ever realising you’re in “Here Be Dragons” territory.

  6. I’ve been programming for more years than i can remember and am still waiting to write a piece of bug free code. I thought I did it once (in 1994 – I still remember !), I just typed the code to do some printing and it compiled straight away. No typos, no missing semi-colons, nothing – It just compiled. That freaked me out, it had never happened before. So I tested it and it did what was expected. That freaked me out even more. I spent the next day testing the code to find what was wrong. Nothing it just worked – now I was nervous about checking it in to source control. Fortunatley I was asked to change formatted columns into a table so i got to rewrite it. This time it didn’t compile first time so i felt a whole lot better about it. 13 years later I still haven’t managed to write a whole section of code that just compiles flawlessly and perfectly. I figure that if you are paranoid about the code that you write and accept that you never are going to get it right, you stand a chance of producing something that is acceptable for most of the time. Well probably ;-)

  7. I like the quote “incremental improvement is better than delayed perfection”. Regardless of what the human civlization takes on, it always requires several revisions to sort out bugs, flaws and pedantic edge cases.

    Version 1.0 is always a great milestone; realizing that, you should always plan for version 2.0.

  8. from Justin Etheredge’s blog

    Building software is hard. Really hard. Really really really hard. Given the best possible situation, and the best possible developers, it is still quite likely that you will fail. Donald Knuth also came to this startling conclusion:

    My main conclusion after spending ten years of my life working on the TEX project is that software is hard.

    If you know who Donald Knuth is, then you know that if he thinks software is hard, then it is really freakin’ hard.

  9. Its like this slogan for a game:
    “A minute to learn , lifetime to master (Othello)”

    It’s hard to do programming. It’s even harder to do it for a living. For every year I think I know less.

    But maybe, maybe it is easy to learn to program, that could confuse some.

    I once heard that “language X” was different from “language Y” in the way that you didn’t need ; after every line. It was really easy to learn Y, but it turned out to be the same level to master as X.
    Y was definitely easier to learn someone newbie than X and the newbies often found themselves think that they where Gods gift to the programming society. Eventually they got wiser and still work as real programmers or they burned and is now managers or they retard to think that the answer to every problem is a model (RUP, Scrum whatever).

  10. I wonder if what you say in some way implies that programming is still (and maybe it’ll ever be) more art, than science, and all this garbage talk about professionalisation is just some form of mask to prevent people from accepting mistakes.
    I’ve never ever done software up to my expectations, and starting to believe never will. So what?

    Really enjoyed your post

    rafael_imas(at)yahoo(dot)com

  11. I once knew a guy who claimed electronic music was easy. Someone gave him a CD of samples and a sequencer and said “do it”. Whenever asked how it was going, he had nothing to say.

    Programming is easy if you’ve been doing it (in one language) for years. Else it’s as hard as the problem it has to solve.

  12. @Melvin: I’ve looked at Ruby a bit, but it wouldn’t make any of these things easier IMO. Heck, it would even make text *harder* from what I understand of its support for text encoding. (I hear that’s getting better, mind you…)

  13. Don’t confuse ‘hard’ with time-consuming. If you can list out all of the things that people are doing wrong in their code, and suggest tangible ways to fix them, then mostly the issue is programmers cutting corners, isn’t it?

    But it’s not fair to paint all of programming with one brush. Most of it is easy, just get stuff from the database, display it, and then update it again. Some of it is really complicated, like dynamic programming, and some of it is (nearly?) impossible, like AI. It’s a wide range that covers a huge spectrum of technical and domain issues. And, as you’ve pointed out it’s be easier and less work for most people if they just did some research first before belting out the code.

    Paul.

  14. I’d say most of the topics I listed are genuinely hard (mentally very challenging) rather than just time-consuming. Floating point may be mostly a case of picking the right data type, but getting concurrency, text, UI etc right is more than just not cutting corners. Keeping all those corners in your head at any one time (after learning them in the first place) is challenging, for one thing.

  15. i m in computer field for 5 years. from the very beginning i found programming a very tedious and boring job. i hate programming languages because of its complexity and long coding. i was not good in maths in my school times so that was enough for hating programming languages. whenever i try to work on programs i found it very boring and left immediately. i also hate the challenges given to employees in MNC’s. too much work pressure can hinder their growth which no company bother about. they only want to meet the challenges and high result at the cost of their employees life. i personally recommend freshers not to go in programming because of its bore and tedious concepts. programming is wastage of time and skill. i would rather suggest you to go for Database. Database is very amusing field where you can make your career illustrious. it has a bright future in coming times. In the next years to come programming will not survive as compared to database languages. Last year i joined Oracle in my course and my fear about computers just shortlived as i found oracle very interesting than programming bcz oracle don’t use code like c,c++, .net. Oracle is completely different from programming languages. I took Oracle Dba in my course module and then i did OCA certification for the bright prospects in job. Certification shows your keen interest and knowledge in oracle. Right now i m working as a Junior dba in INDIA. this is like database job.
    If u want to know about more oracle u r welcome. I can be reached at 9810584697.

Comments are closed.