[This is the first in a meandering and irregularly published
series on brownfield / legacy application development.]
TL;DR: measure stuff that makes you happy when it gets
Working on a brownfield application can be frustrating,
demotivating, difficult, energy-sapping and soul-crushing; or to put it in
other words: "let's just re-write it".
Sometimes a re-write might be the best choice, and sometimes
the people with the cash might let you do it - but more often than not we
inherit an application and have no choice but to work on it.
Once you come to terms with the fact that you can't do a
re-write you have to either start looking sources of happiness and motivation
or give up and not care.
One way too look at a bad (tightly coupled, no tests,
un-unit-testable etc.) brownfield application is that it offers a goldmine of
potential for improvements.
One of the biggest motivators is a sense of progress. In brownfield
development you need to find something to give you a sense of that progress. In
Agile we see user stories moving across the wall and getting to the 'done'
column, this is one sense of progress, but sometimes this may not be enough if
you know that you're actually leaving the codebase in a worse state than when
you found it.
For me, one great motivator is knowing that overall the
codebase is getting better, it gives me a sense of personal achievement and I
know that we are a small step closer to be able to respond more quickly to
changing business requirements in the future.
We have tools to measure different aspects of code quality;
the key thing is to find some metrics that make you happy when you see the
lines going up on the graph. The 2 simplest ones to start using are number of
tests and code coverage: while these only give a partial view of code quality
when you see the figures getting better week-in, week out, it can start to
engender a sense of pride in the code-base. This new-found sense of pride can
lead to less of a tolerance for Broken Windows.
Once you start to feel this sense of pride and potential it
can become a powerful motivational force: "how awesome will it be when we
get 50% code coverage!", "wow I can't believe we had zero tests to
start with now we have 500!", etc.
Once you get that initial 'buzz' going you can start to add
a few more metrics such as lines of duplicated code, cyclomatic complexity,
etc. I'm not sure if it is a good idea to throw all these things onto the graph
at the start of the project as it may seem overwhelming: "what's the
point, look how bad it is, we'll never be able to make it better".
One of the things to be careful of with this approach is
that developers should not see the graph as the end goal, but rather a helpful
friend that whispers in their ear "you doing a pretty good job dude, keep
it up". It's also important not to concentrate too heavily on the actual
numbers: "why has our coverage only gone up by 1% this week", the
important thing is the line is going up - it's about the trend over time, not
the individual measurements.
It's probably not a good idea to link KPI, bonus amounts,
yearly reviews to these figures either - as pretty soon you'll end up with 110%
code coverage ;)
One last point: brownfield development can be really hard,
but it can also offer a great opportunity for growth and learning new
techniques for dealing with the problems inherent in brownfield app