Oct 22 2018

The Midas principle

Category: MiscellaneousIuliana @ 22:11

A few years ago I was working in a company that had an application used for quite a critical purpose all over the world, but that had the ugliest code I’ve ever seen. Nonetheless, the application was a necessity, as it was and probably still is the only one on the market that performed that specific function, and not using it meant that you had to hire hundreds of economists to make and validate the computations the application did automatically. The specifications for the applications were provided by a validation entity, that also defined when the said computations and validations should be completed and going over that deadline made your entity eligible for some serious fines. Yes, I am talking about a banking application. Anyway, the code was bad, because when the deadline is not negotiable, the new specifications deviate from pre-defined patterns and data to test the changes is almost missing, or anonymized so that sensitive details are hidden, but that makes it no longer relevant for your tests, you are put into the position of writing crappy code. Because maybe you started with good code, but when you are required to do changes to fix something that needs to be delivered in a few hours, so the client does not get fined, sometimes you have no choice.

The code being so bad, it was the ideal company to work for if you liked doing improvements. There were a few managers that over the years realized that the technical debt will probably be the reason why the company will go bankrupt and there were some managers – like my direct manager and my mentor – that dared to take some risks and take some heat to try to reduce the technical debt. This is where I come in the picture. In 2014 I was on the run from a heartbreak and on run towards a career. And boy, I was given the opportunity to do so! Anyway I pioneered quite a few changes in that company, took the risks and took the heat together with my mentor and not all my work was exemplary, but I did the best I could with the resources I was given and within the context I was provided.

One of the things that I did was to present to a group of 100 developers or even more, I think, how to properly think your solutions and your code in the difficult position we all were. Because technical debt is demoralizing for people that like their job. And I had to be optimistic and assume people were doing that job because they liked it at some point. So, I started with motivational quotes, book recommendations, basic common sense about how to work in a team, but I needed something new because all the things I mentioned could be found in any presentation about clean code and competent solutions.

While struggling to find something relevant to our company and to our code, it hit me. Our development style so far has been like fixing and adding new features to an airplane while it was flying with all our customers in it. And the quickest method to develop in this case was copy-paste. We even had managers that believed it so. Problem is, that sometimes people were copying code that was crappy and thus propagating crap; new hires, people less experienced and in the heat of the moment even experienced developers were doing it. Obviously, we were not in the position to ever get rid of this behaviour, but what we could do was to improve our code when working on bugs, as to turn it into code worthy of being copied. Because copy-pasted good code, is still good code, even if the Don’t Repeat Yourselves principle has to suffer.

So I named it The Midas principle: every time you develop something, you leave your mark, you transform it. When your work is shared with your colleagues, your style of working gets propagated. If your work is gold, that is what gets propagated. So, when you are working on an existing functionality, turn it into gold.

Sure, this is 90% similar to Robert C. Martin’s Boy Scout Rule: “Always leave the code behind in a better state than you found it.”, but I like Greek mythology more, and I just love the legend of King Midas.

So there you have it, something older than a boy scout rule to compare your development style to.

Stay safe, stay happy and propagate gold!

Tags: , ,

3 Responses to “The Midas principle”

  1. Chiranjeev Gupta says:

    Totally agree. I am a naive open source developer, nonetheless learning from others code has helped me a lot. For me writing proper commit messages for commits has rung the bell around my team. They appreciate the way of doing so (I follow (this Commit Message guidelines) [https://github.com/angular/angular/blob/master/CONTRIBUTING.md#-commit-message-guidelines], and they are awesome), and I have been involved just for a year or so. Our client prefers SVN to Git, and that sucks, I have been persuading my team manager to migrate to Git as well, `Old is Gold` was what I got. I try hard though, but SVN is the forbidden apple I have to bite, I prefer falling one on my head. Thanks for the share yet again! :))

  2. Iuliana says:

    To convince a company to drop a tool and migrate to another, you have to create a business case that clearly underlines the advantages using the new tool with bring. You can make a presentation in which you compare the new tool with the old one and add a migration plan. Without a clear plan containing gains, risks, and deadlines, nothing will happen.

    Managers will approve anything if they are convinced the end goal is to reduce costs and if there is somebody to do the work and to take blame in case of failure. So if you want to migrate to Git, you have to take ownership of the whole process: sell the tool to management, set up the tool, train people on how to use it, maintain the tool and support the people using it.

  3. Chiranjeev Gupta says:

    Makes sense, also I still am not sure if the decision will be judged by my experience (has just been an year). Thanks for the advice, it’s time I ‘git’ some responsibility.

Leave a Reply