Is Programming Hard?

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.