Yo-Yo Code Quality and Architects as Personal Trainers

I exercise regularly. This is for a number of reasons, which I won’t go into and you don’t care about. However what I’ve noticed about exercise and trying to keep fit is that it’s self-reinforcing.

The more you exercise the easier it is. You begin to get more enjoyment from it and therefore want to do it more often.

The reverse is also the case. The less you exercise the harder it is to both get started and keep going and before you know it the emergency services have cut a hole in the side of your house and they’re lifting you out with a forklift.

The point is that it is easier to keep fit than it is to get fit.

The same could be said for software projects.

Over time while the team is concentrating on delivery, the code will get a little flabby. I’m not talking about the code base getting bigger, that’s expected, but some duplication appears, some things are hacked in or some part of the system simply aren’t written or tested very well.

At this stage you’re saying, “Hey, genius, we already know this. You’ve just described ‘technical debt’ using some stupid exercise analogy”. Of course you are right.

My point is that I think it’s easier to keep your code-base clean and tidy with constant refactoring and maintenance (keeping it fit) than it is to let it deteriorate and try to clean it up later all at once (getting it fit).

In the same way that yo-yo dieting doesn’t work in the long term in keeping weight off, big-bang refactorings don’t seem to work as well at keeping a code-base clean as performing a number of smaller done day-to-day as part of your normal development process. This doesn’t mean that you shouldn’t send your project to fat camp by doing a major refactoring or rewrite if it needs it. But perhaps you should consider a lifestyle change.

If you’re getting sick of the fitness analogy please head off to Facebook as it’s only going to get worse.

When people are struggling to get fit they sometime hire a personal trainer to help them get started and / or to keep going and I was thinking that this is a role that could be useful on a software development team.

What if architects were more like personal trainers?

I asked myself, what are some of the attributes I look for in an architect?

  1. They should be writing code (or at least looking at it) most days so that I have some confidence that they know what they’re talking about. In the same way that I wouldn’t choose a fat personal trainer, I want an architect to practice what they preach.
  2. They should be there to keep the developers on their toes and stop them from slacking off. I know some people have personal trainers just to force them to go to the gym at least on those days they have an appointment. That’s fine, some people aren’t that good at self-motivation. Perhaps architects should schedule regular pairing sessions with each of the developers to monitor their progress and the progress of the project as a whole.
  3. They should keep an eye on the bigger picture of the project as a whole and provide solutions where possible. In the same way a trainer might look at a client and mention (discreetly) that their arms are a bit flabby and suggest the best exercise to lose those ‘bingo wings’ an architect might notice a particularly bad area of the code and suggest a fix.
  4. They should monitor and measure stuff. For example, why has the test coverage suddenly dropped, why has the performance of the system suddenly degraded? This is like the personal trainer measuring their client’s weight or how much they can bench press to ensure they are making progress.

This may not sound like the typical architect role that most projects have, it might be more like the team lead. Call it what you like but a personal trainer type has to be more useful than the ‘Ivory Tower’ architects we typically get.

(For the record I do not use a personal trainer).


How Relatively Toxic is Your Code?

I’ve just read an interesting post from Erik Doernenburg about some work I did with him and Darren Hobbs a couple of years back on measuring the ‘toxicity’ of a code-base. Take a read, download the spreadsheet and give it a try. I did this on my current project and it highlighted some interesting information about the style of the coding that the team had fallen into. This is due mainly to the type of project it is, the code wasn’t overly toxic we actually scored okay, but it was food for thought.Reading the post however did remind me of another thing that we did at the time. As Erik mentioned it’s hard to discuss with non-technical managers the quality of a code-base without something concrete to show for it. Even producing a bunch of nice bar charts may not be enough a manager probably will not understand why ‘Class Fan-Out Complexity’ is bad as most developers don’t. 

So what we did was come up with a score that we could use the compare different code-bases and rank them. I don’t think we had a cool name for it at the time but for this post I’ll call it ‘relative toxicity’. Erik has already described how we calculated the scores using checkstyle so I won’t go into that again, but what we did was sum the scores for all classes in the code-base and get a grand total (this is even shown on the second page of the spreadsheet) and then divide this by the number of classes in the code-base to get an average points per class score. This allowed us to compare different code-bases of different sizes and see where they ranked.

We then ran this against some well known open source projects such as XStream, Spring, JBoss and Hibernate and compared our project code-base against them. This meant that we could tell the managers something a little bit more meaningful to them such as ‘the project code quality is three times as toxic as most open source projects’.

BTW I also retried this on my current project and found our ‘relative toxicity’ level was slightly better than Hibernate.

Rules in Software

Following on from Paul’s post about rules in software…

So why do we have rules in software?

  • It makes things easier – developers can switch off their brain, apply the rule and get back to surfing the web.
  • Consistency – thing are done in a standard way throughout the code base, but of course this includes doing the wrong thing everywhere.
  • Safety – it gives developers some insurance, when some asks “why the hell did you do X?” a great answer is “it’s the rule, we have to do X”.
  • Pseudo silver bullet – we’re still looking for it aren’t we, there are lots of people who think that if we apply enough rules, standards, processes that a project cannot possibly fail.

The problems with rules are that they

  • Can be misinterpreted – for example, after explaining the refactoring of extracting a method to replace a comment to a colleague he proceeded to remove comments from the code-base as he had interpreted this as “comments are bad”. It was a combination of my poor explanation and him not thinking about why we would want to do this and when it should be applied.
  • Can be exploited or circumvented – as soon as a rule is in place developers (those crafty devils) will find a way around it or use it to their advantage. I’ve heard of a project where the rule was that all Java classes and methods must have Javadoc comments. The reaction of the developers was to write a tool to automatically generate them with meaningless contents, but the rule was satisfied.
  • Can rarely be applied without judgement – a rule in software development in many cases has an opposing one that can be just as valid given another situation, so the decision is never simply black or white. For example many of the refactorings provided in Martin Fowler’s book have an equally valid opposite one e.g. “Replace Delegation with Inheritance” and “Replace Inheritance with delegation” so which one to use requires some judgement. Will it make the code better or worse?

So I’d like to replace Paul’s rule “There’s no such thing as a rule to rule them all” with the more different rule.

“Question every rule”

I’m not sure there should ever be any hard and fast rules in software. A typical day for a developer involves lots of small decisions being made that will improve the code and it’s design in some way and should never be blindly applied without thinking about why and weighing up the pros and cons.