The (Fun)da - mentals : Are you getting what you pay for?

Is your code or code base a mess? If you think it is do other people that you work with also think so? Do you constantly feel like you 'HAVE' to rewrite the code (more then a simple refactor)? If you answered yes to any of these questions I have one more for you that in part attempts to address the above questions: Do you practice what we all know are the fundamentals of programming regardless of the language you happen to use? Lets turn the rock over and see.

So you say that the speed with which new business code can be developed is slowing down. Maybe you are even saying that new implementations of business features are being hampered by the existing code base. Lets assume for the purpose of this post/discussion that you have been in your current position long enough to notice and potentially make comments about problems that you are spotting in the code base. Lets also assume that you are attempting to be constructive rather then just calling the offending code items pure tripe. When you speak of the offending code what are you saying? What I tend to say these days is that it doesn't meet the fundamentals very well. People often ask me what I am saying when I speak of fundamentals when looking at code. So here is what I explain.

You have to want to learn from past experience, by this I mean both the past experience in the company itself but also the past experience of developers that may have tread where you are now. Keep in mind that there is almost always someone that comes before you and they may have done something similar if not exactly like what you are doing now, at some time in the past. It does happen now and again that you get new novel problems to solve, but these are becoming more rare in corporate America and more the stuff of universities and start ups. So start by attempting to address what happened that lead to where the code is now.

Now you have some history - you can attempt to look at the specific areas in the code that are not done well, you can start to focus on the specific items that make you want to say "I need to rewrite this code" (beyond, of course, your personal distaste of the implementation). This is where the fundamentals come in.

So we all know what problems can exist in code but it might be interesting to see a refresher, so here it is. If you think / want to rewrite your code base and you have done your home work on this history then you can use the fundamentals to start bottom up and address the programmers actions that got you to where you are now.

Code smells - generally after working in a code base for a little while I bring this up as a topic to investigate. Code smells can lead to a code base that no one likes to work in. Teach your programming team to notice and raise these smells as concerns more constantly. Visibility makes these items hard to ignore and you can start to quantify what draw backs the code smells are providing to getting features implemented.

YAGNI - You're Not Gonna Need It. Lots of people ignore this one by way of attempting to be overly flexible in their implementation to attempt to accommodate a schizophrenic business that can not decide on what is the most important thing to do in the company. This is larger then the programming team, but is certainly one of the fundamentals that should be applied and paid some attention.

DRY - Don't Repeat Yourself. The urge to cut and paste working segments of code from one place to another is tempting. However when you find yourself taking the same block and copying it all over the codebase it starts to scream out that you should do something to provide that block as a common item rather then blindly copying the block all over the codebase. Both achieve usage, and both styles work, but when copying the block all over the place if the business logic in it changes rather then one spot you now have many to go fix. Taking more time then you need to to make what should be a simple change.

KISS - Keep it Simple Stupid. Along the lines of YAGNI this is a big fundamental item. Do not over complicate the problems you have, solve them. Solve them elegantly if you can and if not do just the minimum that solves the issue. Don't over do it, don't gold plate, and don't over complicate it. All that over complication will make things harder then it need be later in maintenance mode.

Fail Fast - In almost all cases you want your program to fail fast rather then waiting to bubble up and error at some point in the future. Future based errors or attempting to run when a part of the process is known broken can cause errors that occur much later, and disconnected from their initial cause. This makes for a nightmare debugging, root cause analysis problem. The error is not connected to its root and as such nearly impossible to find.

Refactor - Good god - this might be the most important of all the fundamentals. If you are not taking the time to notice problems and then make them visible and then ADDRESS them you might as well be ignoring a wart on your nose. Refactor always and do it within the confines of the other fundamentals and the risk tolerance of the place you work.

There are many more fundamentals and I would encourage the reader to do the diligence, go find the other fundamentals. Work them into how you do your work, attempt to work them into how your teams of programmers do their work. Use them as guidelines to development and you might be very happy with the result. You may find that over time the ship seems to steer itself and the codebase starts to look better and you don't feel like the code you work with is complete poo all the time. Let your bosses get what they paid for, a seasoned developer that will work to both improve the code, the people they work with and the processes of the company.