Skip to main content

Just Enough to Not Be Dangerous

Posted by johnreynolds on September 12, 2008 at 1:39 PM PDT
My blog entry on User Manual Driven Development prompted Chris Adamson to share some thoughts of his own as For Reasons Unknown. 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.
Related Topics >>


James... No offense meant. You were very clear in your comment (to me) about "limited use" of Manual Driven Development rather than "useless", and very clear that "understanding everything" is going to far... In fact, that's what prompted me to write this blog entry about "just enough"... Thank you for your comment - it made me think, and that's what I try to do with all of my blogs. With that said... It all depends on how you define "Basic Understanding"... I have been shocked by how little some programmers think they need to know about an application. If you are a specialist, like a SQL Optimization Guru, then I can accept a very narrow focus... but if you're doing anything with UI then I'd raise the bar a whole lot higher. -JohnR

Another interesting post John. Flattered as I am to be quoted in this follow up article, I do think you are engaging in a (slight) sleight of hand. My original quote merely drew attention to the "limitations" of your methodology, rather than rejecting it outright. Indeed, your distillation "Programmers should understand the applications that they are writing" is again too dogmatic. Whilst I would agree with the spirit of it, practical experience would cause me to modify it thus: "Programmers should [have a basic understanding of] the applications that they are writing." As for your point on developers becoming interchangeable cogs - whilst I share your fears, as a contractor, I would argue that the ability to transfer my development skills between differing business domains is what has kept me in work for the last 10 years ;-)

I've written software an user manuals. Writing manuals is hard work, and a lot of attention needs to be given to it to keep it coherent. The problem w/the approach suggested is that reality often gets in the way.. you specify things to great detail only to find out there's a better way or a more realistic way later. What I have found useful however, is to develop screenshots or even mockups of the UI so that we can TALK about how the application works. The mockup/screenshot serves as a referenc or reminder of some of the decisions taken (they can also be in a document w/some key decisions documented). That usually provides enough detail for the work. Of course, it works at a feature by feature basis. We do this when working offshore and have had little trouble w/this approach. One key advantage: it is FAST!