New thoughts on last week's topics

OK, kind of weird to see two of my editor's blogs from last week cited in new blogs over the weekend, but it's a good thing... the idea is to get the ball rolling on topics of community interest and discussion.

Let's start with John Reynolds, who writes about knowing 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. 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.

John continues that this seems self-evident, but cites a followup comment which argues that truly understanding the app would practically require a degree in accountancy. Now personally, I would argue that's not a bad idea: if you could code and have passed the CPA exam, you would have a truly unique and ridiculously valuable combination of skills. I would bet that the developers of QuickBooks are highly serious about accounting, just the same way I suspect Final Cut Pro's developers are probably excellent video editors in their own right, and the Guitar Hero and Rock Band developers are all in bands (actually, that's a known fact about the Harmonix gang). But this level of subject-matter expertise seems impractical for most developers, as John admits:

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.S

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".

John's answer is to employ a common language to communicate between the two sides, using Business Natural Languages and Business Process Modeling Notation. Read on for details.