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: , ,

Apr 13 2011

Project Development steps (best practices)

Category: English posts,TechnicalIuliana @ 14:18

You’ll find the internet a lot of opinions regarding this matter, but I really want to post here the way I do it, because it might be useful to someone. Being a Java developer, of course I’ll be referring to Java projects, but the steps are common to all projects, regardless of the technology used to develop them.

This is how I do it:

  1. I decide de name of the project. Any project has to have a name that tells a first time user what it does. The name mustn’t be too long or too complicated. The last project I worked on was called Expenses Manager. Well, what do you think? Can you easily infer what it does?
  2. Based on the name of the project I name my packages. Any JBoss package name has jboss in them, any Hibernate package name has hibernate in it and so on. But when the project name is long, like mine was, it is recommended to create a short name composed of the starting letter of the words which compose the project name – in my case em. For example one package of my application was called jj.em.test, jj is my nickname and test is the scope of the classes inside this package, in this case, classes used for testing. Some developers precede package names with com or org. Anyway you decide to name your packages the main purpose is to help a first time developer looking at your code understand the way the project was organized and why.
  3. I Define a logger for my project. Although there are a few logging libraries on the web, my recommendation is to keep things simple and not make your jar bigger than it needs to be or to complicate yourself with classpath  stuff. How do you keep things simple? By using java.util.logging.Logger the logger class provided by the jdk.  If you want an example here is a console simple logger implementation and here is a simple file logger implementation. (I dare you to do better!)  Why would you need a logger? Because you might need to see outputs, values of your variables at a specific step in development without switching to debug and using breakpoints and stuff, because this might slow you down. When you no longer need the logger, you can just turn it off and all the gibberish disappears.
  4. I set up a testing environment or module. Your application will need testing, no matter how small you might consider it to be. It is better to start with a few test classes which you will grow in parallel with your application by adding new test methods. Same as internationalization (point 5), starting to develop the test module when your application is already done might be a pain in the ass.
  5. I Internationalize! You might ask, why is this a key step and why is it really needed? Well, my dear readers, any time you start a project you must think that might be useful not only to you but to people that one day might actually pay for it. Look at the big picture, and internationalize at the beginning, because if you need to do this later, it will be a big pain in your smart ass!
  6. I Use a building tools like Ant or Maven. Ant for small projects, Maven for big ones which have a lot of dependencies. Also, you might want to check out JRebel.

Tags: , , , , , ,