Thursday, July 27, 2006

Lie About Quality

Quality is the Constant


The controls you have over a project are scope, time, resource and quality. XP teaches us never to use quality as a control, it should always be 100%. However, I've recently noticed a strange phenomenon: the business is scared of quality. I try to say that we will deliver a high quality product, and the response is unexpected. That sounds expensive - can't you just throw something together quickly? At this point, I consider whether to talk about maintenance costs and total cost of ownership, but think better of it. Why do the business want a low quality solution? Its because they perceieve this to be cheaper and quicker to develop. But we know that with XP we can produce quality software very quickly. However, this is very difficult to communicate to the business sponsor. What to do?


A Novel Strategy


It seems a strange approach, but I can only see one way to overcome this problem. Lie. Pretend that you are throwing together a solution of questionable quality in order to meet the deadline. Sell it as Rapid Incremental Delivery of a prototype, RAD, JFDI, whatever. However, behind the scenes put in place all the elements of XP: Continuous Integration, TDD, Automated Acceptance Testing, Stories, Iterations, Release Planning, Pair Programming. Just don't tell anyone. They will get their solution rapidly and they will get incremental delivery of features. However, when they change their minds about the fact that this is a temporary solution, and leave it in live for 3 years, you will be confident of its quality and won't get bitten by a hidden maintenance cost. When you are asked to enhance the solution in a few months time, you will be able to do this in confidence, as you will have good test coverage.


Agile Architecture


Architecture doesn't have to suffer either. As long as you map out the architectural components of the system and assign them their responsibilities, data and interfaces, then you can implement them in the most minimal way possible - even to the extent of a manual process. As long as the system boundaries are well defined, you can fulfill the architectural component's responsibilities however you see fit. However, follow the same principle of lying to the business. If a quality system scares them, just wait for the reaction when you tell them you are going to build a system that adheres to architectural guidelines. That sounds very expensive. Can't you just throw something together - we could make it comply to architecture later...? Pretend you are breaking every architectural rule in the book in order to get the solution out quickly and cheaply, but quietly make sure that the architecture is well defined and adhered to. It doesn't take long to create a good architecture and build high quality systems, just don't tell anyone...

2 comments:

Anonymous said...
This comment has been removed by a blog administrator.
Anonymous said...
This comment has been removed by a blog administrator.