So your boss just gave you a new project you didn’t create, or you just started a new role and “didn’t know it was this bad". Let’s be honest not all projects are new green field projects where we get to make all the decisions. Sometimes we have to roll up our sleeves and get to work to make it happen. At the end of the day our users typically care more about how your functionality fixes their problem and not what new language you wrote it in. So let’s focus on some techniques over language patterns to help solve your problems.
In my experiences with Sitecore implementations you never know what you are walking into with each project. Nor should you care. When you are going through the code just remember this guiding principle – “Don’t Leave Broken Windows.” What?!? I thought we were writing code. We are but let’s break this down for a minute. If you haven’t heard of the Pragmatic Programmer book by Andrew Hunt and David Thomas I suggest you find a copy. You can find one at Amazon.
So back to these broken windows. The broken window theory goes like this:
Don't leave "broken windows" (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered. If there is insufficient time to fix it properly, then board it up. Perhaps you can comment out the offending code, or display a "Not Implemented" message, or substitute dummy data instead. Take some action to prevent further damage and to show that you're on top of the situation.
We've seen clean, functional systems deteriorate pretty quickly once windows start breaking. There are other factors that can contribute to software rot, and we'll touch on some of them elsewhere, but neglect accelerates the rot faster than any other factor.
With Great Power Comes Great Responsibility
Great advice in theory but what does this mean for us and how do we use this new responsibility? Just remember that someone will follow you down the coding path and it won’t always be right. But when you find a mistake you need to fix it to the best of the your ability at that time so that the mistake doesn’t get replicated into other projects. Even if that “fix” is just a comment telling others to proceed with caution. You can do this with compiler warnings/errors as well to draw more attention to it. For example:
#error Oops. This is an error.
This will throw a compiler error so that someone is forced to address it. However, you may just want to throw a warning to proceed with caution such as:
#warning This is just a warning.
You can then wrap these in conditional statements with a date to-be-fixed by so that you create compiler time bombs into your code base. This shows others that you are aware of the issue and forces you to address it by a certain date without addressing it right now. For example:
// fix this date issue before Y2K
if (DateTime.Now() > DateTime.Parse(“12/31/1999”))
{
#error We really need to fix this date function before it is too late.
}
This way you are setting the warning sign and forcing it to be addressed before it becomes a real production issue. But be warned with this technique. You are just creating more technical debt to deal with later. You’ve been warned. You will find that a lot of these practices and recommendations are just that.
They sometimes come with side effects that you have to take into consideration. Good architecture comes with trade-offs all the time. It doesn’t have to be perfect but it does need to address the problem.
For further reading, the broken window theory originated with an article written in 1982 by James Q. Wilson and George L. Kelling when they were addressing the “Safe and Clean Neighborhoods Program” in New Jersey. You will find that in software development we didn’t create a whole lot of these ideas but have applied them to our craft so the concepts make sense. Just look at the Agile technique of a SCRUM but that is another topic for another day.
Until next time.