There's a perpetual argument in the programming community about whether or not programming has to be hard. I seem to write a blog entry about this topic every year or so, and I'm a bit overdue... so here goes another stab at it...
Programming is the act of transforming requirements into something that a computer can execute... thus the first step to successful programming is to get your requirements right. For the sake of this posting, let's call the person responsible for dictating the requirement "the client"...
There are various software development methodologies... but generally requirements are transformed into a functional specification - a very precise written description of what the software should actually do. As far as "the programmer" is concerned, the functional spec is the bible - if the client doesn't put it in the spec, then it won't get implemented.
Once the functional spec has been agreed to by both the client and the programmer, the programmer usually takes over and starts coding. From this point on, the client often has no clue what's going on "under the covers" - all they see is the results when they test to see if the software matches the functional spec.
What does this have to do with programming being hard? Stay with me, I'm getting there...
Sometimes it's really, really hard to implement a requirement. A simple requirement like "get the customer's credit score" might require a tremendous amount of infrastructure plumbing to actually pull off. You probably need web service connectors, some sort of federated trust with the credit agency, etc. You have to deal with service outages, latency due to transaction load at the service provider, etc. It can make the programmer's hair turn gray.
Building software infrastructure and tuning solutions to provide optimal performance requires Software Engineering skills. These aren't the sorts of skills that you pick up in your spare time.
When programmers are presented with hard problems they solve them. That's what programmers do.Unfortunately, programmers often solve problems in a manner that obscures the functional requirement that caused the problem in the first place. The business requirement (get the customer's credit score) often gets lost in a forest of code. The trail of bread crumbs that leads you from the functional requirement to the code that implements the requirement ends up very hard to follow. There are twists and turns and ups and downs and before you know it you're getting dizzy.
Some requirements are going to be hard to implement, so some aspects of programming are always going to be hard - but it's this absence of a clear map from requirement to implementation that ends up making most programming harder than in has to be.
If the "requirement to implementation map" was maintained by the programming environment environment itself, then most programming would be easier.I've seen the proof of this in my own work with BPM solutions - In a BPM development suite the process requirements are documented by drawing a process diagram (usually using BPMN symbols). The diagram is the functional spec for the process.
The task of transforming the functional process requirements to "code" is automated. The mapping between the process requirement and the implementation is obvious. What you see is what you get.
With a BPM suite, programming is easy - at least as far as implementing the process requirements goes. When you get into the non-process related aspects it can still get messy... but I hope you see my point. Those BPMN "maps" keep things really clear... and "all you have to learn" is how to make those maps.
Software engineering skills will still come into play in most programming projects - there will almost always be problematic aspects that require thoughtful engineering solutions - but to make things easier we have to constrain those solutions to fit within the boundaries of the "requirement to implementation" map.
That's the key to making "business" programming easier... Build more tools that help programmers and their clients "make their maps" and build more software engines that "follow those maps". This isn't a new idea - software modeling tools have been around for decades, but they've often lost their way and focused on modeling the software engineering aspects rather than the business requirement aspects of the problem.
Focus your development tools on the business functionality of the problem and programming the business functionallity will become easier. We've done that with the process aspects, so now all we have to do is deal with the data aspects and the business rules - Piece of cake :-)
No comments:
Post a Comment