Skip to main content

Is programming hard?

Posted by johnreynolds on August 6, 2008 at 5:44 PM PDT

Is Programming hard... or are we making programming hard?

That thought came to mind while I was reading Johan Den Haan's well stated opinions on Reasons Why Model-Driven Approaches (will) Fail over at Info Q. He's not saying that MDA won't work, just that it's not the be-all and end-all to solve all of the headaches of programming.

I mostly agree with Johan's opinions about MDA... in my lexicon MDA is synonymous with UML (which Martin Fowler's christened as the Unwanted Modelling Language) and modelling objects just hasn't been the central problem on any of the programming projects that I've ever worked on.

My problems have always related to Requirements.

Programming is the craft of transforming requirements into something that a computer can execute.
Let me say that again:
Programming is the craft of transforming requirements into something that a computer can execute.

Over the years there's been exponential growth in the things "that a computer can execute". Back when I started programming OCR (recognizing text) was still a major technical hurdle... now you find it in hand-held devices.

What hasn't progressed as quickly is the "other" part of my programming equation: Transforming Requirements.

It's often extremely difficult to follow the trail from a Customer's Requirement to the Programmer's Code that implements that requirement.

MDA is an attempt to solve that problem... the idea being that a Model is a more recognizable expression of the Requirements than several hundred lines of code. The "map" from the Requirements to the Model ought to be pretty simple. My problem with MDA stems from a disagreement over what to model... In my opinion a Process Models is a clearer representation of Requirements than an Object Model is. Regardless, I think Models are a Good Thing.

Improving the mapping from Requirements to Code can certainly make programming easier, but the fundamental problem remains: Requirements.

If you don't have the Right Requirements (or they are ambiguous, vague, or self-contradictory) then programmng is probably going to be a nightmare.

This is where the "we" in my original question "are we making it hard?" comes from. John Wood wrote a great blog entry from a typical programmer's view of what makes programming hard... but I think he missed something important....

We seem to regularly block our customers (those who dictate Requirements) attempts to understand what the heck we are doing. We don't want them checking our work until we are done. Said another way, we often block cutomers attempts to validate the requirements that they gave us.

We do this in subtle and perhaps unintentional ways (and in not-so-subtle and blatantly in-your-face ways)... sometimes hinting that "what we do" is more important than "what they do", and mumbling that "they wouldn't it understand anyway".

So how does blocking customer inspection of our work make programming hard? It all goes back to those darn Requirements. I think that many of our problems are caused by focussing (obsessing) on the wrong things. We get sucked in by those nifty techno-glitches that pop up all over the place... and sometimes ignore the very features that the customers really need.

We all know that what customers really need isn't the same as what they want... but that's another blog.

I think the way to programming nirvana is to aggressively pursue techniques that more closely align Requirements to Implementations. If we have a better idea how (and if) we've implemented what they want, then I think we'll stay focused on the right things.

I don't think this is impossible... in fact I think we're already moving in the right directions:

  1. Process Modelling and Execution Environments (BPM)
  2. Test Driven Development (align the Tests with the Requirements)
  3. Aspect Oriented Programming (there are different types of requirements, and aspects can help express that)
  4. Domain Specific Languages (if the SMEs can read it, it's a good thing)

We need to stop focussing on tools that are purely developer focussed, and start focussing on tools that foster communication between the developers and the SMEs (Subject Matter Experts). We need to integrate tools that let the SMEs implement what they can with the tools that let prgrammers do what they must (let's face it, we know how to do things that they don't need to know how to do).

Yeah... Programming is hard... But it doesn't have to be as hard as it is.

Related Topics >>


If it seems hard, you are probably doing it wrong. Solve the needs of the user, and work out the details (the OO model) behind the scenes. My rules: Make it work. Make if right. Make it fast. Make it scale. Finally, do only the rules that are absolutely necessary.

really cool, I found programming is hard, but thats because of my way of learning. thank you. fachim

erdudley, I think we'd agree that the success of the projects you mentioned hinged on sufficient Domain Knowledge to properly interpret the Requirements. If you have developers who really know the Domain, then you're in luck... If not, then increasing the SMEs ability to share their Domain Knowledge will help - Tools aren't the answer, but they can help. -JohnR

"Yeah... Programming is hard... But it doesn't have to be as hard as it is." I think there is two ways to look at this. One, There should be tools and/or processes that allow the skill level of the 'developer' to be lower and be able to produce good programs. Second, the developer has the skills and the domain knowledge to understand the requirements properly. I've seen projects stocked with great developers ( a good portion of being of the 'Martin Fowler' persuasion :) and more than adequate requirements gathering produce a product that wasn't worth anything . I've also seen smaller teams of developers with solid domain knowledge produce great programs using methodologies they've learned 25 years ago. I don't disagree with you John, maybe it's just a different perspective.

Thanks Riccardo... TDD is certainly a huge factor in guaranteeing success when the Tests are the right ones ;-) I think that we need to see "Aspect Oriented Test Driven Development" to make sure that all the aspects of the requirements get tested. -JohnR

Very good post, John, I completely agree with you. I was vey happy to find Test Driven Development in your "list"; I use to describe tests as "automatically executable requirements", I really can't understand how many (so many) people thinks they are useless or simply "we don't have time to write them"... Greetings, Riccardo

Well stated.