Separation of Concerns

Software developers can test do all their own testing.
But it will not work out.

Software developers can also plan and envision the product.
But this overtime will go astray.

What drives sustained success in software development is Separation of Concerns.
Which sounds like Specialization but is not.

The best example is Accountants and Auditors. An accountant can by changing the rules, change the profitability of the company (think depreciation). So over time accountants have showing a profit, and ever growing one at that, as their main concern. Auditors on the other hand are only concerned with how the accounting processes and practices are done. Auditors have no concern for the whether a profit is shown but rather that the profit and loss number was arrived at in an acceptable and consistent way. When your accountant becomes your auditor as well, or when you auditor accepts at face value all that your accountant does you can expect an Enron type outcome.

Software Development is different because it has three concerns that need to be separated; Specification, Implementation and Validation. It is better to think in these terms rather than the roles that they are usually mapped onto; Business Analyst, Software Developer and Tester/QA. Business Analyst implies some concern for the business as whole. Test is close although it emphasis is on bugs and Quality Assurance takes the focus on Verification.

Specifying what is to be created must be completely separate from Implementation, which is how it will be created. Time and time again the pattern repeats of software developers pushing back and not wanting to implement something because it is hard. Or it does not lead to using the technologies or practices that are currently fashionable. And by fashionable, I mean well rewarded by the market place. If you hold both concerns of Specification and Implementation at the same time the temptation to make a comprise on Specification to benefit Implementation is immense.

When it comes to holding Implementation and Validation concerns at the same time the problem is even worse. Testing may reveal a problem. Knowledge of what it takes to fix it hinders the desire to immediately log it and raise it as a concern. Here again compromising Validation to benefit Implementation is the easiest route.

To keep this in the proper length I will state the next four and return to them later with separate articles:

Specification is about serving the customer.

Testing is about isolating the problem.

Development is about solving the problem.

The process provides the framework. The process is the automated assembly line of software development.

permalink