I have seen this scenario many times: programmers fearing existing code, writing extra code just to accommodate new features without changing existing code. A similar attitude I see is, is manifest in projects dealing with big databases. People working in these projects don’t dare to question the design of the Database, and subject themselves to finishing the tasks at hand to fit around the existing DB design. This is fear. Fear of:
- Uncertainty. They know existing code works. Refactoring existing might break some functionality.
- Time. The time to refactor code cannot be correctly estimated.
- Work. Of course, this is additional work.
There may be other reasons (for example, greed. The programmer might want to gain a short-term acknowledgment of his speed of delivery). But the common occurrence is Fear. And we will try to understand the implication of this fear:
- Old code gets older.
- Additional code to manage deficiencies in old code need to be created.
- The application becomes monolithic and difficult to change.
- This creates additional fear of change.
The cost involved in maintaining such code is stupendous. And how do we avoid this cost? It is, from my experience, by following some good-old practices and tools:
- Unit tests: The importance of these cannot be exaggerated. When you have a Unit test suite covering your code, it is with more confidence you can refactor it, and more confidence with which change it.
- Each developer gets his own play area: Sharing resources during development is also costly. This is the reason I encourage each developer to have his own database setup and development environment (whenever possible). This isolates the developer, and his fear of breaking the shared environment is nullified (which affects other team member’s productivity). He is more free to innovate and bring in new thoughts.
- Developer’s own coding and commit space: I also encourage people to use distributed source control systems in place of things like svn. This allows the individual to have a independent commit space, where he can commit his work as and when he completes a unit of it, without worry of breaking someone’s build. Again, a source of greater freedom.
I have seen the most unlikely people innovate by following these simple practices. So what is your take on this?
