Business evolves at a furious pace, software must keep up-to-speed with this ever changing world. There is often a misconception around the expression “Do it right first time”. The perfectionist in us wants everything to be right first time, but with the introduction of the agile manifesto, refactoring is becoming more and more important.
Refactoring: What allows developers to do it?
The desire of generating code that will exist for ten or more years is over. Why waste time building for the future when it is now? Why should the business wait for the delivery of a component that future proofs the system for the unknown bug that may occur in the distant future? This responsibility to always be looking ahead and feel responsible for all possible permutations of use for the component is a characteristic of mass-production thinking. Lean Thinking admits that software is not perfect.
The production of documentation often is a cumbersome, mundane task, and pointless task that often hampers refactoring. “Do it right first time” is seen from a Lean Thinking perspective as an excuse to produce masses of paperwork generated from armies of analysts and designers that form a barrier between the customer and developer. This approach not only produces waste by becoming quickly out of date, but reduces the accuracy of the final solution as misinterpretations can arise from the handoffs between customers, analysts, and developers. Lean Thinking identifies this waste and advises that developers should focus on tasks that add value other from handoff and documentation.
Strive towards perfection, not for perfection
Agile introduced a greater emphasis on refactoring (iteratively improving the design of software without changing functionality). If code is to be refactored then it hasn’t been done right first time. Surely this is true? Lean development focuses on (and only on) the set of stories in play for the current iteration. Software design should be loosely coupled with high cohesion; thus providing the agility for easy refactoring when new stories require implementation.
Never forget that the code produced should always be quality and with the appropriate test coverage (in the means of unit, functionality and acceptance tests). Refactoring does not mean “buy now pay later” when it comes to quality. It should be correct to the test cases produced for that story; therefore a term to use instead of “Do it right first time” is “Test First” or “Test-Driven Development”.