A team in trouble would probably say that they would very much welcome expert help – but would they really? Are they ready to face the brutal facts of the state of the project?
An important part of the psychology behind forming a team is the distinction between “we in the team” on the inside and the rest of the world on the outside. To some extent this is good: A team with a strong spirit will be able to handle any obstacle in the outside world. But in some cases it can backfire, when the team stop looking at themselves, but only look at the outside world to explain problems. In fact; when a team is in trouble, they will in most cases first find external reasons for the trouble.
The customer demanded a huge change, with a very tight deadline.
The architecture in this legacy system is so hard to work with that it takes forever to make changes.
The first one is external – the customer asked for a change, but what about the second? It might be that the system was recently handed over to the team in which case it is external. But what if the team has been in charge for maintenance of the system for a year? The fact that the legacy system that they took over had an architecture that’s hard to work with is external. The fact that they haven’t done anything to it in a year is at least partly internal to the team.
Looking deeper at the first example that might be internal as well. The change may be huge to the team’s standards, but if they had a flexible architecture and proper automated tests in place it might not have been such a big issue. If the team has worked in isolation for too long, they are less likely to see that their architecture is inflexible and that their testing is sub standard.
When working with legacy code I usually start by classifying all modules of the system based on the urgency for rebuild. The classification helps making sure that no work is wasted improving details of code that will be discarded later.
I use four levels to classify the code:
The classification of different parts of the code is communicated to everyone on the team so that everyone knows the rules for the different parts of the system.
I can’t tell how often I’ve been in a meeting with a financial manager, trying to explain the technical considerations of a project. To be honest, there have been times when it has been really, really hard to keep it technically simple enough, while still being accurate. That’s the lucky times. The bad times is when I’ve completely failed and left the room without any funding at all. I read a blog post (in Swedish) written by a colleague of mine that opened my eyes for the term technical dept. It was first formulated by Ward Cunningham. Martin Fowler has written a great article that explains the concept.
Reading a bit more, following links and searching I found a number of ideas on how to describe software development in financial terms.