Just Enough to Not Be Dangerous

My blog entry on User Manual Driven Development prompted Chris Adamson to share some thoughts of his own as For Reasons Unknown over at java.net.  My blog entry relates my early experience of developing an application from a pre-written user's guide.   Since then I came across a very similar approach that's used by Daniel Brolund that he calls User Guide Driven Development... obviously great minds think alike ;-)

Chris's thoughts helped me boil down my premise to a single statement:

Programmers should understand the applications that they are writing.

You might think everyone would agree with that statement... but you'd be wrong.  Go look at the comments on Chris's blog.  My favorite is the following from James Browning:

"It's a lot easier for a typical developer to know if their IDE is useful than if they're building an accounting package"

Which is s good reason why the proposed methodology has limited use. I am currently on a contract in an insurance underwriters. I am working on their accounting package and for me to understand everything about how the software is to be used and why I would basically need a degree in accountancy.

That's why we have business analysts ;-)

James has a point, of course.  Most programmers will never understand everything about how a particular application will be used... But surely they should understand something about how the software is used.  If not, then programmers really are interchangeable cogs and we all deserve to have our jobs outsourced.

So what's the minimum?  When do you know "just enough (about the business) to not be dangerous"?

The same is true for Business people.  It's very important for the Business Analysts (that specify software) to know "just enough (about software) to not be dangerous".

Those of you who are sick of my blogs on Process Driven Design should stop reading now... I'm about to make my same old pitch...

Business analysts and programmers need a common language.  Programmers need "something to read" that tells them how the business works.  Business analysts (who specify software) need "something to read" that tells them how the software works.

Business Natural Languages are a big step in this direction.  Business Rules Engines are a big step in this direction.  BPMN Environments are a big step in this direction.

Business analysts don't need to know all of the aspects of the software, and programmers don't need to know all of the aspects of business... but both sides need to understand the common middle ground.

If you  follow my blogging it will come as no surprise that I think that BPMN is a great way of describing that common ground.  The business analysts draw the boxes and connect the lines - the programmers implement all the little details that make those boxes actually work.

BPMN is evolving, and there's a raging debate on just how expressive BPMN should become. Should BPMN just describe the highest level details of a process, or should you be able to precisely express a lot of details?  I tend to agree with Tom Baeyens's views... BPMN should stick to modelling and steer clear of execution sematics.

Regardless... I know from experience that (some) business analysts can learn to "think" in BPMN.  I know from experience that (some) programmers can learn to "think" in BPMN.  I know from experience that if you combine a BPMN literate business analyst with a BPMN literate programmer you will probably end up with a kick-ass managed business process.