A change in attitude - Legacy code

Attitude is a little thing that makes a big difference.  ~Winston Churchill 

 
Not long ago, I gave a talk about Software Craftsmanship where I asked who liked to work on greenfield projects. Almost everyone raised their hands. Then I asked who liked to work with legacy code. Besides one or two friends that were there, almost everyone kept their hands down.
 
It is always nice to start a project from scratch, be able to choose the technology, use the latest frameworks and have a lot of fun writing code without worrying about breaking existing features or having to understand existing code. Working on greenfield is great, mainly with an experienced and disciplined team using TDD since day one. Progress flows naturally and quickly.
But as soon as we are working with code written by people that are long gone, no tests, no documentation, we go mental. We notice we are going mental by the number of WTF we say during the day. We may get moody and start hating to work on a specific system or in parts of it. Frustration becomes a constant.

A change in attitude

If you don't like something change it; if you can't change it, change the way you think about it.  ~Mary Engelbreit

 
Although I wrote "we" and "us", that was really how I used to feel when working with legacy code. However, in the past few years, I learned many things. An obvious one is that moaning, complaining and cursing won't make my life easier or better. If I want things to be better I need to do something about it.
 
Today, when I look at legacy code, instead of moaning and getting frustrated, my attitude is to try to understand it and make it better, constantly applying the Boy Scout Rule.
As my friend David Green said in a twitter conversation, what I agree 100%, improving and understanding legacy code can be massively rewarding. The process of trying to make sense of a big ball of mud seems daunting but if we just focus in small parts of it, one at a time, and start improving them (writing tests, extracting methods and classes, renaming variables, etc), bit by bit, things become much easier and enjoyable. 

Working with legacy code is almost like solving a big jigsaw puzzle. We don't do that all at once. We start by separating the pieces into groups, often starting with the edges and corners and then separating other small pieces by colour, pattern, etc. We now have a few (logical) groups and we start to form a higher level model in our head. What before was a bunch of random pieces (or a big ball of mud), now is a bunch of smaller groups of random pieces. Still not very helpful or encouraging, but nonetheless some progress. Bit by bit, we start working on one of these groups (parts of the code) and we start putting some pieces together (writing tests for the existing code, which will help with our understanding of the code, and refactoring it).

Once we start putting some pieces together, we start seeing a small part of our jigsaw puzzle picture. We get excited because now it's getting real. It's starting to make sense and we are happy we are making progress. The more pieces we put together the more excited we are about finishing the jigsaw puzzle. The more pieces we put together, the easier it gets to put more pieces together. And that's exactly the feeling I've got when working with legacy code now. For every piece of code I make better, more I want to make the whole code better. The feeling of achievement is really rewarding. What before was something I could barely read and took ages to understand, now reads like a story and every developer can understand it with no effort at all. Maybe when a good part of the code is stable (covered by tests, loosely coupled, well defined responsibilities, etc), I could even introduce the cool and new frameworks that I always wanted to use. I could upgrade some library versions. I could even throw a lot of code away and replace it with a framework because now my code is clean and modularised and replacing one part of the system will not break another. I don't even need to envy my friends working on greenfield projects any more. 

Different challenges 

Another cool thing about legacy code is that it forces you to think in a different way. In greenfield projects, when developing a new feature, we write a test and start implementing stuff. In legacy, sometimes you can't even instantiate a class in order to test it due to all its dependencies. A change in one place can cause an impact in obscure parts of the system. We have an option here. We can see these challenges as a pain in the ass or can be see them as very interesting problems to solve. I prefer the latter.

The professional side 

Although it is OK to have fun and enjoy what we are doing, we always need to remember that we are professionals and being paid to write software. Software is an asset and a lot of money and time is invested on it. As every investment, clients want to maximise the return of their investment. The more we improve and keep the software clean, the longer the client will be able to benefit from it. Stretching the lifespan of a software also maximises the client's return of investment.

Conclusion

At the end of the day, it does not matter if you are working on a green or brownfield project. It's your attitude towards your job that will make it more or less enjoyable.

Spinus and nmrdb.org

I don't remember how many years ago I discovered the web. I was excited by how many things were available for free. There were a lot of curious and interesting things but, I was the first to admit, nothing really serious that could substitute a true book, or a true CD or a true computer program. The great thing about the internet was that I could easily read the opinions of other people around the world. I mean: ordinary people just like me.
Things began to change with the appearance of SDBS 14 years ago. It was the first really useful thing I found on the web.
The last discoveries are Spinus and nmrdb.org.
SPINUS-WEB

SPINUS (Structure-based Predictions In NUclear magnetic resonance Spectroscopy) is an on-going project for the development of structure-based tools for fast prediction of NMR spectra. SPINUS - WEB currently accepts molecular structures via a Java molecular editor, and estimates 1H NMR chemical shifts. The predictions are obtained from ensembles of previously trained feed-forward neural networks, and corrected with data from an additional memory.
SPINUS - WEB predictions are restricted to:
CHn protons (no predictions for hydrogen atoms bonded to heteroatoms are made),
compounds containing elements C, H, N, O, S (some oxidation states), F, Cl, Br, or I.
For a data set of 100 independent structures representing a wide variety of structural features, SPINUS gave the following average errors for chemical shifts: 0.16 ppm for aliphatic class, 0.23 ppm for aromatic class, 0.35 ppm for non-aromatic pi class, and 0.29 ppm for rigid aliphatic class. A global average error of 0.23 ppm was obtained for the 952 predictions. A global error of ca. 0.6 Hz was observed for coupling constants.

This service depends on a number of Java applets that apparently do not work on my computer. Who cares, an alternative interface is available at nmrdb.org. In practice you can forget about Spinus and just connect to the latter. Spinus will be called in the background.
When you arrive at the home page of nmrdb.org, you find 4 applications: Simulator, Resurrector, Assigner, Predictor. The latter lets you draw a formula, from which a H-1 spectrum is generated. No alternative is given: if you already have the ChemDraw formula, it's of no use. You have to draw the formula again, which is easy and funny, I have to say.
The Simulator allows to simulate a second-order H-1 spectrum, so it's nothing really new. The required input are the values of chemical shifts and Js. Every time you change a value, a new FID is generated and FTed. Too slow for running it on the web, in my opinion.
The Resurrector transforms a list of peaks (copied from a PDF paper, for example) into the picture of the corresponding H-1 spectrum. How many formats are recognized? As you know, different journals may require different styles for reporting the NMR values. The ACS style is of course recognized. They have described nmrdb.org on a scientific paper, which probably contains all the details; I have not found them on the web page for the Resurrector.
The Assigner is something that does not work but suggests you to move to another site, called mylims.org:

The principe of mylims.org is very simple:
You upload a jcamp file
You process your spectrum
You save the result of the processing
You retrieve the ACS assignment for publication
Using mylims.org you will be able to make fourier transform, phase correction, baseline correction, “smart” peak picking, auto peak picking and even be able to assign 2D nmr !

The NMR Predictor brings us back to our starting point. This picture gives you an idea of how it works:

You hover the mouse over an atom in the formula or over a peak in the spectrum. Two yellow squares appear, that hilights the correponding spots into the formula and into the spectrum. Just what you expect, because the similar programs all work in this way.

HOLY SHITTING CHRIST BATMAN! NEW SCREENSHOT!

This shows the third and final environment, set amongst rolling farmland, which confusingly will probably be the first used in-game, with the forest second and beach last. Unless I end up using forest first and this one second. I'm not sure yet. To add variety each environment has three time periods - day, night and sunset, and the sky, lighting and ambient sounds will change accordingly.

You'll no doubt also have noticed the big circular saw blades to the left and right of Jack. When the game's eventually released you may want to avoid touching these.

Right! Time to design some levels!