They also created a new pedestrian crossing next to the tram stop. And there was one thing about it that I noticed. One side of the crossing was connected to the tram stop and the curb there was just rebuilt. The other side of the street had a perfectly fine curb, and it would have been no problems to just paint lines on the street and be done with the crossing. But they didn’t.

Instead, they ripped up the street, curb and part of the sidewalk on that side too. Why? The reason is that they wanted to improve that side of the crossing too. They’re making the sidewalk about half a meter wider and thereby narrowing the street. That makes it a little bit clearer that it is a crossing and therefore makes the crossing safer. They’ll lower the curb for a meter or so which makes crossing by bike or wheel-chair easier. That’s about it, as far as I know.

While arguably better, it didn’t really enable anything that wasn’t possible before. And it did cost money. Money that could have been spent elsewhere. And they had already spent a lot of money on rebuilding the tram stop. So why did they do it? I’m not sure, but I think whatever the reasons were, the same reasons could be used to motivate refactoring of software.

(Alright, that was possibly a crappy metaphor… but it’s my blog, and I’ll post what I want. )

Multitasking doesn’t work,
but it would be so nice if it did
that we try anyway.

That’s about the best summary of (human) multitasking I’ve heard.

This picture is pretty good too, though.

I very much liked the idea, that a set of very low level instructions, carefully chosen and carefully followed, could create something so complex and beautiful. Jurgen Appelo has expressed similar ideas regarding complexity theory, and how ant hills or bee hives are complex structures created without a master plan through individual bees’ actions. Yet another connection would be local search algorithms, which find maxima in a landscape through looking only at their immediate surroundings.

Next, my brain started linking these ideas to software development. For example, Test-Driven Development. It is in its essence, a set of very simple rules. Write a test, write needed implementation, refactor. These three simple (at least in theory) steps is all that there is to it, when properly adhered to, it can give great results. Designs tend to be much more easy to use, contain less bloat, be more testable (duh!), and so on. Refactorings are another great example. A set of rules or recipes for how to transform a code base into a better code base.

Obviously, choosing the right set of rules to follow is the important part, as a bad set of rules will lead to crappy code just as an unwanted mutation in a human body may lead to e.g. cancer. But I guess the point I was trying to make is that there is immense power in follow simple rules.

Constraints are good.

To me, that statement sounded rather odd. Constraints is a negative word to me, so intuitively I want to remove constraints. Thus, I asked him to clarify. And here’s what he said (or rather, my interpretation of it).

A big advantage of software development is that we can build virtually anything. However, that same fact also represents one of the biggest problems. “Anything” includes all the great things that we envision, but also all the crappy things which we typically produce.

Since the possibilities are endless, in theory nothing prevents us from creating something truly great. But — and here’s the thing — by adding wisely chosen constraints, we can eliminate some of the undesirable outcomes. That means, that even if we screw up a bit, we’re more likely to create something which is at least not half-bad because we’ve eliminated the really bad outcomes. If we stay within the constraints, that is…

Another way to see it is that just as any society needs some laws and rules in order to function smoothly, a software development team does too. Whereas an example in the first case may be “do not kill”, an example in the second could be “do not commit code which breaks the build”.

As a keynote speaker at a software conference, Enrico Zaninotto, an Italian economist, pointed out that the underlying economic mechanism for controlling complexity in just-in-time systems is minimizing irreversible actions.

The notion of “minimizing irreversible actions” strikes me as a better way of capturing that whole idea than the more established “last responsible moment“. The latter suggests that you should delay making decisions for as long as you can. I feel that sends the wrong signal. You can make decisions. You must make decisions. Not making a decision is a decision in itself. Just don’t make decisions that you cannot change — keep your options open. By thinking that you must not make decisions until the “last responsible moment”, it is easy to delay the decision longer than is actually responsible.

I believe this is especially true for software architecture. In the name of “last responsible moment”, many developers avoid making architectural decisions, thinking the architecture will emerge by itself. But to quote Grady Booch in a response to a letter “The Relevance of Architecture” in IEEE Software (Volume 24 Number 5).

Every system has an architecture; some are accidental, others intentional.

Which is yours?

Every time I manage to actually do a proper cleaning of my apartment, I usually think: “Okay, now the apartment is clean, it shouldn’t be too difficult to keep it this way. I’ll just make sure that after every day it is still clean.” That’s a great rule in theory but it never works in practice. As soon as you slip, and let the apartment get messy, you’re lost. It has now become more of a mess than you can muster energy for to clean up.

A different strategy

But my friend suggested a different strategy: “Before you go to bed every night, make sure that the apartment is at least a little bit cleaner than it was when you woke up.” This rule has worked out extremely well for me. They both work fine as long as I follow them every single day. The difference is when I slip, when I allow the apartment to become a bit of a mess, I won’t automatically freeze and ignore it. All I have to do is to remove one single thing from the floor or wash one single glass, and I will have fulfilled my promise. If I just keep doing this, my apartment will eventually be clean. And also, once I’ve picked this single thing from the floor, or washed that single glass, it’s rather easy to take another and a third one as well.

When your apartment finally is clean, you’ll have to use a bit more imagination to fulfill the rule. You might archive those payed bills lying in your closet, remove the clothes you never use in your wardrobe and send them to a suitable charity, or do any other thing that you’ve long thought of doing. This would never even have happened with my first rule as it would have acknowledged my apartment as clean and I would need to do no work.

In software development

The reason I’m talking here about cleaning my apartment, is that I believe the very same principle applies to software development as well. It’s easy to ignore accumulating technical debt in your system, become paralyzed by it, and not have energy to deal with it. In that situation, just ensure that the system gets a little better by every commit, and one day, you’ll realize that your system is really in quite nice shape. So don’t aspire to be perfect, just to become better every day and you’ll get there (or at least very close ).

No matter exactly what task it is, we’ll assume that completing it is something that would require many man-weeks to complete. Time that we typically do not have in the condensed schedule of a modern software development project. Thus, it can be hard to motivate spending the resources that would be required to perform such a change. All to often, this leads to a situation where change is regarded as “something that should be done, but which we don’t have time for right now”. That is the same thing as “something we will never do”. Furthermore, as we typically perform the improvement in order to make the code base easier to work with in the future, we want to prioritize the parts of the system where we spend most of our development time.

A simple rule

In situations like this, I suggest the following rather simple rule.

Every time you commit, ensure that all files in that changeset are updated to the new standard.

Thus, if your current commit touches a controller which contains business logic, you may not commit until you’ve extracted and merged it into the model. Or if your commit touches an undocumented or untested class, you may not commit until that problem has been corrected.

Rationale

The rationale behind this recommendation is twofold. First, the performing the change won’t feel like a gigantic task, as it only involves modifying a couple of classes at any time. This helps to get around the “something that should be done, but which we don’t have time for right now” problem. This helps to amortize the work over the course of the project.

Secondly, you don’t spend time on updating files on which no one is working. This connects to the assumption that the improvement is done in order to make the code base easier to work with. Thus, as long as no one is working on a file, there is no need to make the improvement there. However, as soon as someone touches that file, it will brought up to the new standard. This is really just the Last Responsible Moment principle, or YAGNI, put in a slightly different context.

As a bonus we reduce the risk that the change introduces bugs. This is because, as opposed to performing the change in one big go, only code on which the developer has just been working is updated. Thus, the developer is more familiar with the code and is in a better position to avoid introducing bugs by breaking non-obvious relationships and dependencies in the code. This advantage becomes more important the worse shape the code in question is in.

Possible drawbacks

To be fair, I should mention possible drawbacks. The major argument against this method is that the system is left in a “in between” state for an extended period of time. Depending on the type of change this could become problematic. If you’re switching from using one library to another, you might for a while be dependent on both libraries rather than any one of them. This might in turn create confusion about what library to use. Or if the system is in the middle of a major large scale refactoring, developers might in the same way be confused about the correct way to implement a feature.

I think that the best solution to this problem is to ensure that all developers are aware of what is happening. It’s really a question about communication within the team. Exactly how to solve this potential problem depends on the team. You can create a list of ongoing improvements which everybody can check when in doubt or when committing. You can emphasize collective ownership of the code and use pair programming to spread knowledge. Do whatever fits your team, as long as you consciously considers and manages the risk.

Summing it up

All in all, I think performing large scale changes in many smaller chunks is the preferred way to go. Pay off some of your technical debt every day, rather than all of it at once. After all, to pay off your whole technical debt at once, you most likely will have to take on debt of some other kind — economical, working overtime, or implementing less new business value.