Brownfield Application Development (Part 2) - Lose Weight, Feel Great

If there was The Biggest Loser for software, legacy applications would be up there sweating on the treadmill and trying to resist the chocolate cake.

One of the characteristics of legacy code bases is bloat, fat, weight - basically stuff that we could do without.

This bloat slows us down: more scrolling, more stuff to distract us from the thing we're looking for, longer VCS operations, longer builds, more keystrokes etc.

15 Diet Tips for Overweight Apps

  1. Remove unused usings
  2. Removed DLL references that aren't needed (and delete the DLLs from source control)
  3. Delete commented out code (you are using a VCS right?)
  4. Delete pointless class or method XML comments (empty summary, params with no useful info, etc.)
  5. Delete unused class files
  6. Delete commented out tests
  7. Delete ignored tests (if you can't un-ignore them and get them working quickly)
  8. Delete bad tests (tests without asserts, etc.)
  9. Remove unused variables, methods, constants, etc.
  10. Remove unused JavaScript and CSS files
  11. Delete unused screens, pages, custom/user controls
  12. Removed unused CSS styles
  13. Remove pointless inline comments "// the line below declares a variable for loop counter"
  14. Remove multiple line spaces between members (unless you like them)
  15. Delete unused configuration settings

SHARE:

Brownfield Application Development (Part 1) - Managing Motivation and Energy

[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 better.

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 development.

SHARE: