Opportunistic salvage driven by tests

Taking a break from my recent series of blogs about management, I’d like to discuss something that has come up with my current client - OK, I’m bending my rule to and blog about live events but this isn’t about the client, its about an idea.

Opportunistic salvage

Many readers will have seen this scenario before: there is an existing system, it has been developed under a previous approach, a non-Agile, an approach that didn’t give quality a high priority. Some believe that the new work, based on an Agile approach, can take the current system “as is” and build on it, maybe some patches will be needed but why throw away something that has already been built?

Something customers have? Something you’ve paid for? - they have a point.

And there are other people who believe, perhaps with good reason, the existing system has poor code quality, poor architecture, significant defects (bugs), and in general takes more effort to maintain than it would to rebuild.

As always the truth lies somewhere in between, and as always, determining what the truth is is not easy. The best that can be said is: some parts of the system are good and can be built upon, and some parts of the system bring more costs than they do benefits.

Anyone who has ever owned an old car will know the problem: you take the car to the garage and you are told “Ooo…. this is expensive to fix” - not as expensive as a new car but expensive. Nor it this the first time you’ve taken the car in, this time its the steering, last time it was the electrics, next time… the clutch? the gear box? And maybe there is rust.

You have to make a decision: should you spend the money to keep the car running or invest the money in a new car?

This is the question we face. Our solution is: Opportunistic Salvage.

We will look at each part of the system on a case-by-case basis and decide whether we can bring it across or whether we rebuild.

Critically this is driven by tests, automated acceptance tests to be specific.

Faced with a request, a requirement, we develop a series of acceptance tests - based on the acceptance criteria that go with the requested story.

These tests will be implemented in an automated ATDD fashion using a tool like Cucumber, SpecFlow, FIT or Selenium. We will then take the part of the existing system and run it through the tests.

Two points to note at here:

• Building an automated acceptance test system is needed for a proper Agile approach. So building this keeps with the new approach. (If you are not automating your tests to build fast feedback loops its unlikely you really are doing Agile anyway.)
• Some work may be required to make the section(s) of code testable, i.e. make it a module with a well defined interface. If the code is already a well defined module then good; if not then it should be. Going forward, in an Agile approach, requires good code so if an investment is needed then the investment is made.

Now one of two things will happen.

Possibly the lifted code will pass the tests, this is good and shows that the people who said we should build on the existing were right. We can take a quick look inside the code to make sure its good quality but it probably won’t need much work - after all it just passed the tests. If it happens that a bit of work, possibly refactoring is required then since there are now tests this is quite doable.

On the other hand, if the module fails the test… well, it is a good thing we found out now and didn’t leave it till later! (One wonders how the current system is working but lets not worry about that right now.)

The code has failed tests so obviously needs some work. Nobody wants to ship code which is known to be faulty.

Now we look inside the code, and we make a professional judgement: is it better to patch up this code and make do? Part of this judgement included remember the product is expected to continue for some time to come.

These decisions are made on a case-by-case basis. There is no blanket decision to move all the old system, nor is there a blanket decision to write everything from new. What is good is kept, what is OK is patched up and what is bad is thrown away.

The people to make the judgement call are the people who are going to be working on the code: not the managers, not the business analysts, not the project managers, not the product managers, not even the testers. All these people may have a view but there is one group of people who are recruited and employed because of their professional skills with code.

The programmers, aka software engineers, aka software developers.

Given a code module that is failing tests and is expected to have a long life these people need to make a professional decision on whether the better course of action is to patch and make do or to rewrite.

In making this decision we are accurately aware that sometimes writing from scratch can be faster than patching up something that already exists - faster both in the short run and in the long run when ongoing maintenance costs are considered.

This is especially true in software, especially true when the people who originally wrote the code are long gone and especially true when the original code was written without tests.

These decisions are made on a case-by-case basis. Where code can continue it is salvaged and reused. Where isn’t sensible then it isn’t.

So… no debate about legacy or new build: Opportunistic salvage driven by tests.

If those who believe the legacy product provides a solid base are right then there will be little new code written, sure you will need to write some tests but you will want to do that anyway.

If those who believe the legacy product should be rewritten are right then many tests will fail, code will be found to be crummy and it will be replaced.

Non-Commissioned Managers

The last two blogs have all been about roles and people who are commonly thought of as “managers” in software development but who aren’t - Managers who are not managers and Analysts aren’t Managers - either because they happen to have the word “manager” in their title or because exhibit characteristics which programmers associate with managers.

Those blogs were written to prepare the way for this blog…

Non-Commissioned Managers are team members who fill a management role but aren’t usually recognised as managers. Borrowing a military term I think of these people as Non-Commissioned Managers. These are software team equivalents of a corporate or sergeant.

(I have to beg forgiveness for breaking one of my own rules: I’m making a military analogy. I’m very conscious that like so many people who make military analogies I have no direct first hand experience of the military and there is every chance I’m getting this wrong.)

These are people like: Team Leaders, Technical Leads, Architects, Scrum Masters and Coaches. Some of these people - Architects and Scrum Masters - have specialisations because of their specialisation they have some authority in a special area. Others like, Team Leaders, make the teams work day-to-day, they get a lot of the grief management do but few of the rewards. Such roles are akin to Sargent Majors of their teams.

On any software development teams there are a usually a group of people who are not consider managers but really do fill a management position. They may manage people, they may have authority, specialists skills or knowledge may give them authority and power, they may make decisions on behalf of the team, they may guide/coach/advise people who actually do the work, and they get listened to by the real management.

I’m including Scrum Masters and Agile Coaches here. There specialists skills give them some authority in particular areas. I know some Scrum Masters won’t like this but in many organizations the Scrum Masters is very much seen as the Sargent.

Last October I saw a presentation at a conference where the speaker talked of a company with just two managers - the CEO and the Sales Manager. Everyone else was some form of developer. But on closer examination, when you asked, the developers included technical specialists, team leads and others who filled a management role but weren’t seen as part of management.

This is akin to having an army unit with corporals, warrant officers and sergeants but no Lieutenants or Captains. Such units exist, they are usually small units. Larger units without commissioned officers exist too, perhaps only briefly when officers are killed in action. When commissioned officers are absent then non-commissioned offices fill the void. Even when there are fully fledged managers the NCO managers are necessary to make the teams work. They are on the ground, at the code face, with the team all the time.

On teams without a non-commissioned manager it is not uncommon to see a leader emerge, usually because of technical skills, sometimes because of charisma. In time these people may be recognised by the managers as the NCO/NCM, a kind of battlefield promotion. NCOs get some authority from the organization but most of their authority comes from the team because the team respect them.

(I’ve also NCOs imposed on teams who did not respect the chosen NCO. This is a recipe for trouble.)

Herein lies a lesson.

Very small army units, say a fire team, is commanded by an NCO. Fire teams form squads and squads too are commanded by NCOs. (I should say I’m getting this from Wikipedia, and the terms differ from army to army.)

Squads in turn form platoons, platoons are (according to Wikipedia) commanded by an officer, a Lieutenants. Platoons form companies which are commanded by a more senior officer, a Captain.

Do you see where this is going?

Command, management, is a question of scaling.

Small teams can be managed by non-commissioned managers but as you group into bigger units you might want commissioned managers. Or you might pretend that your non-commissioned manager is OK. If you do there will come a point where the non-commissioned manager will not be doing much except for managing.

One of the problems Agile has right now is everyone wants to know about “scaling” but a lot of Agile thinking and literature rejects management. This problem isn’t new…

During the French and Russian revolutions the bourgeoisie (managers) were shot at the start of the revolution. And now, like Napoleon and Stalin we now find that some of the things we want to do require managers. Without a respected command structure in place we have trouble enacting decisions and strategy.

One of Agile’s “scaling problems” is that we have a mixed up view of management.