Programming is not hard – Knowing what to program is hard

Programming is not hard.

Sure, there are plenty of examples you can pull out of the bag that have really brain-numbingly complex algorithms in them, and they are indeed hard to program, but they are really the exception. For most programmers and most programs, this is not the case.

Most programs that fail do so not because the implementation is done badly or fails altogether, but because they implement the wrong things. Its not that the programming was hard, but that they programmed something nobody wants.

Deciding what you should program is where all the beef is.

The point I’m trying to make is maybe most prominent with beginners (although it is really not only about beginners – this misconception exists widely throughout all levels of programmers).

When I teach first-year students to program, they always think that learning how to implement their programs – how to write nice, correct, maintainable, good quality code – is the hard bit. Once you can do this, they think, you’re out of the deep water and in a much more comfortable zone. Maybe it’s good to believe this initially. After all, you cannot learn everything at the same time, and you cannot learn those things which require experience at the start.

The truth, however, is: Learning to implement your problem is really the easy bit. Well, easy, relatively speaking. When I see bad software (and you can find a lot of it), it is almost never the implementation that is the killer. It is partly user interfaces, and mostly functionality.

The applications just don’t do the things I want them to!

This observation is the same at all levels. It is true for final year student projects, shareware I find on the internet, and professional software that I pay good money for.

So many programmers with adequate implementation ability sit down and write programs that do things that end users really don’t want. And they don’t get the right ideas to implement stuff that would be of good value. The process of making decisions about what functionality should go into a program (and then what the UI should look like) is really where the 80% of software that is essentially rubbish falls down.

It’s not how to do things that’s difficult, it is knowing what is worth doing.

22 thoughts on “Programming is not hard – Knowing what to program is hard

  1. You have a narrow view of what’s considered programmer, what you’re really saying is *syntax* is not hard, which is true.

    Most programs are implemented poorly, are full of duplication, and often completely lack in architecture. The measure of quality isn’t whether a program fails, it’s whether they are easy to change and extend. Most programmers can hack up something that works, very few can write something that others can build upon easily.

    Writing good clean code, paying attention to your users and implementing the right features, it’s all programming dude, and programming, *is* hard. If programming wasn’t hard, you’d be able to pluck random people off the street and teach them to do it, but it’s well known that it takes a certain type of person to become a programmer, most people just can’t do it, and can’t learn to do it.

  2. No, you misunderstand. I am not talking about syntax at all.

    Writing good, well structured, quality code has nothing to do with syntax. And that is what I’m talking about. That’s what many programmers concentrate on. People usually understand quite quickly that it’s not syntax that is the problem.

    But a well structured implementation still tells you nothing of functionality.

  3. You are absolutely correct that the actual coding is not difficult and that it is the analysis of the requirements and the production of a suitable design that can be.

    It makes you wonder why in many cases people struggle with the simplest of programming concepts such as naming variables and making the code readable. Perhaps a follow-up article?

  4. “Writing good, well structured, quality code has nothing to do with syntax.”

    I agree, however, you seem to be saying that well structured quality code is common, but programmers choose to implement the wrong features. However, well structured quality code is anything but common. You may be right about programmers often implementing the wrong features, but that doesn’t automatically mean the features they do implement are done well.

    Any random sampling of just about any open source project will reveal that most programs, regardless of the feature set, are very poorly written. Programming *is* hard, it’s as simple as that. Knowing what to program is just *harder*.

  5. Pingback: Programming dan Dunia « Pribadi

  6. I some what agree with Mik, as you can be good programmer even when you are starting to program or is at amateur level.
    you understand problem definition well, you write well commented code, divide things in to classes , classes into function, meaningful names to function and classes.
    Writing code only for what function name suggest, removing circular dependencies.

    I really feel any of the above things related to syntax or for how long you have been programming that why I say an Amateur can some time write better code than experience people.

    Thanks Mik for writing a article on this subject

  7. I agree with Ramon and Michael: Knowing what to program is harder than programming. I agree with Ramon (and disagree with Michael in this respect): even programming in itself is hard, at least for beginners.

    The difference is: After some years of programming you know how to program, so it seems easy to you. But knowing what to program stays hard, no matter how experienced you are.

    “Programming the right thing is harder than programming a thing right.”

  8. Michael,

    I have a problem with this concept – what you are saying, as far as I can understand, is that the issue is with defining what to code, which for me is Product Management. Writing is the easy part – that would be what our programmers do in the company.
    As a Product Manager, when I define what are the requirements of the product, I do a lot of hard work of thinking what customers would want to buy.
    I think that when the programmers come to do their magic with my requirements – they need to design and code it in a way that will make it easy to maintain and to add features that I will want from them somewhere down the road.


  9. While writing well structured applications can be easy, architecting and coding an enterprise level system which is easy to read, easy to maintain, runs well, and most importantly is usable, is the daunting task.

    VB allowed for anyone with a credit card to become a programmer. For the purpose for which it was designed, it was a great tool. It was when folks without the gumption to pay attention to performance, server/database round trips, network traffic, code bloat, etc… that VB grew out of hand (my opinion of course).

    So both sides of the argument can be seen as correct I think. It does come back to the definition of programming. If my architect does his/her job well, the programming actually is easy.

  10. I completely agree, I was having this conversation just the other day. Without getting into a language war I was bemoaning C++. Years ago when I started my programming career I used to love C++ as it was possible for me to write code to show how clever I was. I used to think that people would read my code and think, that’s a clever way to do a bitmap. In fact C++ feels like it’s been designed this way (I’m not saying that it’s not possible to write good code in C++, but it is so easy to write slop).

    The more I program the more I realize that good programmers write maintainable programs. They write things in a way the reader understands, in the language of the problem: not in Martian, Hungarian or Line-noise. They realize that the real cost in software is in maintenance and have maintained enough systems to hope that there is a kind of karma.

  11. I don’t think there is a simple “succeed”/”fail” metric for programs. Some programs are better than others, of course, but there are many different ways one program can be better than another. Sometimes a program is better than another in one way, but worse than that same other program in another way.

    Now, I’ve written piles of total crap, and I’ve also written some okay software. One of the things I’ve learned is that software can always be better: more comprehensible, more efficient, more easily modifiable, more correct, and also intended to do something that’s more useful. In fact, it can be *much* better, on any of those axes.

    Another thing I’ve learned is that they’re not completely independent. For example, a necessary ingredient in making software do something useful is trial and error, because you can only do so much of that by deduction; you also have to build some software and then change it a bunch of times in order to get to something really useful. So software that’s easier to understand and change can evolve toward usefulness more rapidly. Similarly, software that’s easier to understand is easier to find bugs in, and easier for third parties to improve (and those third parties invariably know things you don’t about what would make the software useful). And so when I get better at any of these things — when it takes less effort for me to avoid bugs, or fix them, or figure out what kind of software I need — my software improves in all of these ways.

    A third thing I’ve learned is that most software is, on an absolute scale, total crap in all of these ways. I don’t really know why that is. My working hypothesis is that it’s not that people don’t care, but that improving quality in each of these ways is hard: it’s hard to write maintainable code, it’s hard to figure out what kind of program would be useful, it’s hard to write efficient code, and so on. If Michael were correct, I would expect to see loads and loads of efficient, maintainable, bug-free, and easy-to-modify code, that simply didn’t do useful things. But I don’t. Maybe he is looking at different software than I am? Where is it? If it’s out there, I want to be reading it and learning from it!

  12. I agree with your premise, but not necessarily with your reasoning. I’m not sure that knowing what to program is particularly hard, because you’ve obviously identified some need that can be satisfied through the creation of software. The next bit, which you’ve identified as “the hard bit” is the step in which you refine some abstract notion of a problem domain into a set of concrete, implementable features that solve the problem. I don’t necessarily think that this is a difficult step either, it’s more than developers will often do it in an ad-hoc manner, which can lead to problems and inconsistencies. I believe the hard(est) part of software development comes next, when you actually figure out how features x, y and z work, and how they interact. Once you’ve solved that bit, it’s basically a typing exercise.

  13. I definitely agree. While syntax and implementation used to be the hardest thing for me, it is easy now that I understand it. However, I find it hard to come up with a good original idea that attracts users: either the idea is too far fetched and unprogrammable or the idea itself is not very appealing. I still haven’t found a great idea that is worthy to be programmed. But once a good idea is found and you know what is to be done, all that is left is to arrange your idea into small blocks of program and to execute it. It all comes down to typing.

  14. I agree that it is harder to come up with an idea than to actually write the program. It is a hard field to excell in. I , as a first year student myself, am having a difficult time figuring out what i need to make and at times it is rather difficult. However once i get the material I can finish a program with ease. Some of the material is rather harder than other parts but still eventually I understand it and I use it in other programs. For example, I didn’t understand how to use math in my programs before, but after I got some extra help, I could use it with ease.

  15. I totally agree with you on this paper. I have tried to think of useful programs to create for fun, and it took longer to think of the idea then to actually program it. And sometimes, the program turns out to be a bad idea that has no purpose what so ever. All that you have to do for programming is memorize differnt things and put them all together. It is very hard to think of something new that can help someone or even just a game. In conclusion, I also beleive that it is harder to think of a program than to program

  16. I personally agree with the author’s point. I feel that once you understand the symbols and the rules of programming, you can input the lines of code into many different areas. I agree that inputing programming to solve everyday-like situations may be hard for beginning students, but once the people understand the rules of Java, it will be easy to use the concepts in job fields, such as a Programmer, Computer Scientist, or just a website designer. I feel that the author of this written portion really captured the symbols and rules of programming while being frank. I deserve an A+ for this essay.

  17. I think the problems exists due to a lack of (or difficult to maintain) communication between developer and end user.

    Users do not know technical. They often don’t truly know exactly what they want. Sometimes you can give something to a user and though it might be different than what they expect, they might actually say “oh, this is good. I like it”. Sometimes users (hereby referred to as “clients”) do offer a fairly clear, unambiguous definition as to what they want, but this is the exception, not the norm. Worse still, even when a client *does* provide a clear, unambiguous definnition as to what they want, their explanation can still be misintepreted by the developers.

    The only clients who offer a description that is 100% detailed and totally clear are actual developers talking to other developers. But this is rare since the developer would just go write it themselves (or modify another existing open-source project to get what they want).

    It’s a lack (or difficulty) of communication in which the problem lies.

  18. Ridiculous amount of negativity in the comments.

    Programming is as easy as cake, if it weren’t, then it wouldn’t work. It’s that simple.

    The problem is most programmers are in fact nerds that spend their lives on computers and don’t have any kind of semblence of a spirtituality or emotional understanding of themselves, all they see in numbers, aglorithms and MMORPGS. Logical thinkers they are, and that’s the problem… you all say programming is hard, but if that’s true, then doesn’t that go against logic?

    The problem is most programmers get into programming for a career, which is the worst thing you can do in computer world. Then you are trying to crank out a product that people want to make things easier for them. It’s what they _want_ that is the problem. To actally want something and get it makes things more difficult, so then you have miserable programmers making buggy programs to give people what they want.

    If you leave “want” out of the equation, then the rest of it becomes much easier to write. A freelance programmer would know exactly what I’m talking about. Programming is NOT hard. It’s just as easy as anything else.

  19. Many people who say they a good programmers are fooling themselves, since they see programming more convoluted than in reality. I’m targeting those who have no sense of self, and those who even say that the syntax, features, or even creating their *own* structure is difficult.

    Numbers and algorithms are useful tools (math). But MMORPG’s? It depends on the personality of the person; I play video games all the time.

    If one is literate and works with logic daily, then programming is guaranteed to be easy. The only remaining challenge is dealing with practical problems.

    Don’t believe me? I’ve been programming only for less than 4 years. I’ve never had trouble with programming, even when I just started learning what programming was about out of scratch. The only times of struggle I had to face was when ultimately deciding what structure to use consistently, and what style to use in documentation.

  20. well it all ends to the saying from the tao:
    “When the program is being tested, it is too late to make design changes.”
    the language holds everything what we want it to do and to the fellow programmer of course.
    and before all::welcome to programming!

Leave a Reply

Your email address will not be published. Required fields are marked *