Do it right…Always

The last 2 weeks I have been working on one of our current products which was needing some updates. Whilst it is the current version, it is in VB6 and dates back to 2002. It has had about 10 different coders working on it over it’s lifetime and each one took over after the last one had left, so there has never been any handover or more than one person working on it at once. To make things even more interesting the database has ~90 Views and 230+ Stored Procedures. Now add in only a handful of comments over the whole codebase along with no coding standards to speak of and you can see it’s not the easiest legacy project to work on.

Having seen the state of the code and the fact that every time a fix had to be made or a new feature added the developer that did it just rushed it in so they didn’t have to spend anymore time working on it than was absolutely necessary it is so obvious how the code ends up in the shape that it is.

It has made it very clear to me that no matter what the codebase you are working on is written in, or how bad the code is, you have to stick to the patterns and practices that you would use in the newer projects that you are working on. The previous developers that worked on this product didn’t, and it has lead to some of the worst spaghetti code I have ever seen, 15 nested if’s along with a handful of while’s thrown into a single loop, which in turn is pasted into multiple modules. They cut corners to get the job done quickly.

When I first started on the updates I have to say I fell into the same trap of wanting to just get the job done ASAP and get back to the newer projects I am working on. However, it occurred to me that as well as being the right thing to do, it would also be a great learning exercise and mental workout to stick to the programming principles that I have been trying to advocate since I joined the company, and that is how it turned out.

I now believe it will make me a better developer by having to spend time every now and again working on a project like this and trying to implement TDD, DRY, encapsulation etc. etc. Not copying and pasting or using global variables just to get it working and out of the door.

It is so much easier to write good code using all the latest languages and tools, if you have plugins like Re-Sharper in Visual Studio, and using frameworks like MVC you can’t help but write good code, possibly to the point where you don’t even know why or how. Not that I am knocking these technologies, anything to make my life easier is fine by me and I use as many as I can (note to self: write post about the tools I use). But going back to the older languages and IDE’s and writing good code is that much harder, more of a challenge, but it means you understand what you are doing and more importantly why you are doing it. That can only be a good thing and re-enforce why it is important to stick to what we learn and know works.

I feel my understanding of some of the programming principles I am always banging on about to my colleagues has increased in the last two weeks. When you see the difference they can make to the flow of the code and you see the results you can’t help but feel motivated to do it at every possible opportunity.

So why do people cut corners and not do it? What does that say about you as a developer?

As if to underline why coding this way works the client said they would pay for 65 hrs for the whole project, (the previous developer had originally quoted 100 hrs) the company was expecting to make a loss on this, especially as I was new to the product and there was expected to be a learning curve. Even with documentation and testing the project only took me 45 hrs. I am not sure by cutting corners and working in the same way the previous coders had I would have been able to do it any quicker. Whilst I know how to write code, I am by no means a coding Ninja like some of the guys we have here, I spend as much time using Google to jog my memory as I do actually coding, yet I still managed to make some money by doing the job right. I am also confident the code is reliable, and can be easily maintained if changes are required down the road.

It is something I feel very strongly about, that no matter what you are working on, you need to do the job properly. When I see smelly/bad code I can’t help but question the abilities of those developers that wrote it.

Do you want that to happen to you? I know I don’t.