Ordinary people have expectations about software defects that don’t match reality. All software has defects. Almost no one is even trying to write software that is free from defects. The goal of software testing is to reduce the number of defects down to an acceptable level. That acceptable level is a lot lower for a network router than it is for a game, for example, but neither has set zero defects as its objective.
Test Driven Design (TDD) has taken a different perspective on software. In TDD, the tests have been promoted to the point where they are the fitness function for the main software. Any software that passes all of the tests is perfect. Of course, there are still gaps between the software that we wanted and the software that we have. The tests themselves will still fail to perfectly describe the system that we wanted, so all that we’ve done is changed our perspective.
In an organisation with a properly functioning Business Intelligence programme, there is a measure and a target for every operation that the organisation considers important. The organisation is functioning perfectly when it is reaching all of its targets. Unit tests for software are the same thing as business intelligence for an organisation.
Ordinary people don’t expect their organisations to hit all of their targets, nor have I ever heard anyone describe an organisation as perfect because it reached all of its targets. And we’re usually wise enough to know that the targets for our roles in our organisations aren’t trying to measure our value as human beings. We understand that the targets are just a framework to be used for guidance. We try to improve that framework with the knowledge that is a tool that improves the underlying organisation. In software we do the same thing. We write better and more varied tests in order to improve the software.
In both cases the underlying mechanism is the same: both BI and unit tests give clear direction to a person. We’ve identified a goal by identifying how that goal will be measured. That person, programmer, lawyer, or chef, does the work that turns the plan described by the measurement into reality. Expressing our plan in a structured framework that emphasizes measurement of the outcome greatly improves our chances of success.
I hope that this has helped explain the management of people to programmers and programming to managers. We’re all doing the same thing with different objects. We know that the targets of our organisation aren’t trying to describe perfection, they’re just there to guide and improve the collective work of a group of people. And the tests for our software are doing the same for our computers.
RSS - Posts
Be the first to comment.