Good code / Bad code
It’s not always black or white
A couple of weeks ago I read a blog post from someone I consider a good programmer, lashing out on some “bad” legacy code that he had to work on and transform into “good” code.
It’s a very well written post, pleasant to read, with some good insights, but it has a big problem, the code he is lashing out was written by me and my colleagues before he came along…
Well, in reality the problem is not that he is saying our code is “poor quality code” because most probably he is right, at least a part of the code, if I remember correctly it was pretty bad, specially if you look at it out of any context and three years after it was written. The problem is that he makes the comment without knowing the constraints and objectives we had when we wrote it.
As I see it, in a bootstrapped startup kind of environment, code can’t be sentenced as being good or bad in an isolated way. There are a lot of constraints in place and, most importantly, we are not only coders, we are team members doing what’s necessary to make our product succeed.
If we make code that is not optimised for performance, is not easy to maintain, doesn’t follow conventions, doesn’t have any tests, but is what the company needs in order to go from having nothing to being profitable and growing fast… that’s awesome code in my book!
One other problem people tend to forget when dealing with legacy code is that pretty much everytime you rewrite something, you will do it better.
It’s not that the old code was bad when it was written, but as time passes by, in technology, a lot of stuff happens, programming languages get better, new patterns arise, programmers get more experienced, so old code always looks like as it could be improved.
In my opinion it isn’t possible to just look at legacy code and say it is “poor quality”, code doesn’t make sense out of business context.
Using the mentioned project as example, let me explain what I mean by context:
- It was the team’s first rails app;
- It was the first project done as a team for this group of developers;
- It was bootstrapped and done in between consulting gigs;
- Only for one of the developers this wasn’t a first job;
- It was started at least 3 years before;
- It managed to get the product to profitability with hundreds of paying users.
All of this should be taken into consideration before publicly criticising the code and attributing the “poor quality” to the developers capabilities.
So don’t look at a piece of code and jump into conclusions about code quality or worse about the capabilities of who wrote it.