Why Do I Break The Rules? And Who Can Stop Me?

I've been developing software for quite a few years now and I notice that sometimes I break the rules, those best practices that I know are right to follow.  With so many blogs, books and articles covering the best way to develop software, the temptation to do your own thing still can take over - even when you know it's wrong.

Ashamedly, I know that I've broken these rules in the past, as I'm sure most software developers have.

Test Driven Development 

There's no question in my mind that the best approach to developing any piece of code is to do tests first and then code. It focussed the developer in a different way than other approaches. You'll find that you start a fresh project with good intentions and write your tests first. Then, as you get further along the way, you start to run out of time, so somethings got to give - it will usually be your tests. 

There's no excuse for this. All IDEs have JUnit built in to them and any developer with experience knows that it works. All developers who think that unit tests can be skipped should read Pragmatic Unit Testing. The authors put it best when they proclaim "unit testing means never having to say you're sorry".

Ignoring Broken Windows 

Sticking with the Pragmatic Programmer series of books, one of the big lessons for software development is to have "no broken windows". A broken window is a piece of badly written code that exists in your codebase. If the window isn't fixed, then it will lead to other broken windows. 

While I might not be the first one to pollute a codebase, I'm as guilty as that person for not fixing, or at least logging, the issue. I don't know how many times I've gone through code, looking for where I need to add in my fix, and ignored rows of broken windows on the way. 

Once again, there's no excuse for this - I'm aware of the rule, I know that it makes sense, but I'm too caught up in getting my part done.

Mixed Up Spagetti Code 

These days most of us declare the wonders of modular architectures - being able to seperate code down to bundles of responsibility and redeploy those bundles anywhere. So we create a bundle (or package) with UI responsibilities, and then we create another for logic. How many times have you seen that logic code starts to creep into your UI bundle? Of course this doesn't become apparent until too late unless you've been following a test driven development approach, and have been testing anything that you can do on the UI through the logic layer. 

Of everything on this list, this is the one that I hate the most, and as such is the one that I'm least prone to.

Diving Right Into The Code 

It's new project day, and you know you're going to be using some cool technologies. Even if you're using the same technology, at least it's a clean slate. Nothing of the past three habits is going to get in the way this time. Or will it? 

The tendency to avoid analysis, and dive straight into the code is common with all developers. It's a natural thing as we like to get things running. It's even excusable if you do a quick run through, take the lessons learned and then go through an analysis stage. But it's the going back that's the problem - once we're in the code, we're happy there.  Sometimes we sugarcoat this as an "agile approach" but is it really?

The Solution 

The software industry would be in a much better state if we had a ready made solution to these bad habits. There's a common theme through all of my failures above, and that is time. Doesn't it look like I'm always up against the clock? Maybe that's my fault for not giving clear enough estimates. But if I bump up an estimate to ensure I follow all these rules, am I just going to waste the extra time I'm given?

Of course there are things that can be done such as peer reviews, but nothing can beat good programmer discipline. Maybe we need to introduce some kind of hippocratic oath for software developers?