We do test a lot of our code to make sure that the software behaves as it intends to. But do we test our designs? A sturdy design can instill confidence in the team, much before we try to see the output or the results. This can help improve the software development productivity.
By design I do not mean UML diagrams and details like inheritance or aggregation relationships or design patterns. I mean building the entire system in your design, identifying roles, assigning responsibilities, building interfaces, structuring and organizing data through which they communicate. I am not sure if this is a system model or not, but this is what is the soul of the application. How can we ensure that we the design is right and sturdy? How can we determine that there are no holes or loose threads?
One of the ways I use is to test the combination of responsibility, knowledge and authority, by taking the design for a test drive. No, not through tools and applications, just on a whiteboard, with a team sitting and poking holes in it. I am sure at some level everyone does this, but I believe an explicit attempt can provide higher value. Most of the responsibility is what we usually explicity identify through requirements. But knowledge and authority get specified implicitly. If an entity’s responsibility is not in proportion to its knowledge and authority, it will not function effectively. If the entity does have information, it should at least know where to pick it up from. If the entity does not have authority to do something, it should know whom to ask. This is where we start building relationships. This lets us test individual entities and the whole ecosystem even before we sit to write the first alphabet of our code.
One of the key things to remember is that the balance of these three – responsibility, information and authority, is valid in a given scope. That is why it is important to decide on scope, even when you are working on iterations.
I have understood most of the principles or best practices from this perspective. Because software is first about people and processes and then about functions, classes and patterns. We should be able to test our design at a level where we are still dealing with people and processes, and test if the design is sturdy.