Confusing Business Complexity with Programming Complexity

Responses to my recent posting "Why Occasional Programmers Suck" were mostly positive, but I did get a few expected disgreements from offended "full time" programmers such as the following from Mark:

"I don't agree. What we doing is not simple. It is more than just putting parts together or drawing a diagram. I think our tooling has gotten better and has made it much easier. But Tools like VB and MS Access have done much to hurt our industry as it allows people to THINK they can program. So we end up with piles of unmaintainable code and code that can't deal with the complexity of business and the need for systems to integrate. Advancements of tooling should be to help developers develop, not end users." 

Mark misunderstood a bit what I mean by "Occasional Programmers"... It's not really the end users of business applications that need better development tools.  Developing Business Applications is an art that requires a proper mindset and many skills that you would not expect most end users to possess.Occasional Programmers are people who understand the concepts of programming.  They are folks who understand process flow, how to express rules, how to logically organize functions... but their full time jobs are something other than "writing code".


Where Mark's comment really missed the mark (pun intended) is with his tacit assumption that the "complexity of business" has much to do with the complexity of programming.

For example... I was recently working with some very experienced programmers who were completely aghast that IBM's Lombardi BPM doesn't provide support for rolling back database transactions that spawn multiple process activities.  In database programming, there is the concept of a "transaction" that spawns multiple database updates.  Many records can be "written" to the database as part of a single "transaction".  If for some reason you need to cancel the "transaction", you can roll back  (undo) all of the changes that have been made to the database.  The programmers I was working with naturally assumed that they'd be able to define database transaction boundaries in the Business Process that we were working on, to handle rolling back any changes in the event that the Business Process was canceled.

Programmers don't work on reality, they work on models of reality.  Canceling a process was, to these programmers, as simple as undoing any changes to their model.  They'd missed the fact that each process activity takes place in the real world.  People perform tasks, messages are sent, related activities and processes are started... "real" changes are made by the process.  "Rolling back" a Business Process when it's canceled has very little to do with restoring the state of a database.

The programmers building this application didn't fully understand the "business complexity" generated by canceling the Business Process in-flight.  In contrast, the Business SME on the project did know the necessary steps... and the Business SME was able to use the tools to diagram and define the necessary steps.

Here's the bottom line - programming tools intended for building Business Applications need to focus on dealing with common patterns of Business Complexity.  The underlying Business Machine worries about programming complexity... not an easy task by any means... but not the concern of the Occasional Programmers.

As an analogy, think of your car.  Your interface to your car is the steering wheel, the gas pedal, and the brake pedal.  With these three controls you are able to drive anywhere you want to (until you run out of gas). The complexity of the machine that accepts your input - what's "under the hood" - is somebody else's problem.  You just handle the complexities of driving the car.

This is what Object Oriented Design and Service Oriented Architecture is all about - providing the proper interfaces for those who build higher level (business) applications.  With the right interfaces, and the right tools, our Occasional Programmers can focus on dealing with those business complexities that Mark's worried about.