The Curse of Version Control

Version control is a MUST for any developer - but that doesn't mean you have to use an external version control system. The importance is in the idea and attitude instead of using any specific tool.

Last week we got a harddisk crash, removing SVN version control and TRAC project management from service. Regardless of that - and summer vacations causing delay in repair - work must go on. Was shocked to realize how much I had started to rely and depend on SVN as part of normal development cycle. Suddenly I was on loose ground!

Version control without a version control tool requires certain kind of routines:

• Think before you start doing anything
• Complete your thinking before you start doing anything
• Test your thinking before you start doing anything
• When thinking is done, start doing - don't procastinate

This time it's all about you. It's all in the mind. It's personal.

• Split the work into small enough parts which you can design, implement, test and release during one cycle
• Never start anything you can't complete during same session
• Make regular backups of your progress, even local ones
• Document what you plan to do and how you think you did it
• Automate anything you can

The less you have to keep in your mind, the better you can focus. The better you can focus, the faster you get results. The faster you get results, the easier it will be to fix them.

What would Steve do?

Developer is not "The User". He is biased towards his own comfort zone and all designs, decisions and recommendations are from technical implementation point of view:

• Feature is boring to do: users wouldn't like it.
• Feature is difficult to do: users wouldn't like it.
• Feature changes architecture: users wouldn't like it.
• Feature removes "my code": users wouldn't like it.

The question you really have to ask: What would Steve do?

Refactor or Die (or burden of maintenance)

Agile development says when something is done, it stays done. Don't touch it again! On the other hand refactoring is an extremely important part of agility. How do you combine these, possibly conflicting requirements?

Refactoring is a planned action. When you develop something, it is done as well as it can be at that specific moment. It is scheduled, planned, designed, implemented, tested, documented and released as well as needs to be at the specific moment. When it's done, it's really done.

Developing a new feature, additional requirements or fixing bugs might bring in new information, which makes it possible to improve something already done. Make it more generic, robust or faster. Search for reusing something old.

Refactoring is a fact of life. Experiment, seek alternatives, gain more experience, receive more detailed information, learn from own mistakes or from experts who have made more mistakes than you. Use this for your advantage. Refactoring is not experimenting, but cleaning up afterwards to the most suitable solution.

Don't refactor for the sake of refactoring. If something works, don't touch it without really good reasons. Developing something twice is quite ok, requires less time than refactoring. More safe. Refactoring has to be an improvement.

When you find need for a third similar object/module, then take a moment to consider advantages and dangers of refactoring. Will the be more similar cases in future, how critical areas are you dealing with, how stable have they been bug and feature wise. Would refactoring be worth the risk and investment of time and effort?

Don't refactor for fun. Only when needed, understanding risks.