There’s an interesting dichotomy in software development – anyone wh has spent any amount of time in the field knows it all too well. There comes a point in every project where you have to make a choice – good code or fast code. Sure, you’ll get those “sweet spot” projects that’ll let you work on the “good code” side of things for as long as you’ll need (maybe a personal project?) but more often than not, you’re going to fall on the “fast code” side of the line. It’s sad, really it is.

Every good developer knows that the world could only benefit from having more “good code” in the world. Applications would not only do what they’re supposed to to but they’d do it well and have better performance while doing it. Things would flow smoothly through the paths the user laid out in the planning stages and everything would be magically delicious. Right? Sadly, even when you have the time to make the “good code”, it’s still not that good.

First off, throw out those personal projects – the timelines of those don’t really apply anyway. You can hack away at a framework you’re developing for years and only get most of the way done with it. Unless it gets some kind of larger following, chances are people aren’t going to be putting the pressure on you to make updates and add new feature. The whole realm of personal project timelines is an interesting one – maybe something I’ll look into later on. For now, though, we’re going to focus on software someone else wants you to write. This is where the major part of the problem is – it’s someone else’s timeline, someone else’s thoughts you’re trying to put into code.

I can’t tell you the number of times that I’ve been working on a project and have hd nothing but the best of intentions of how it was going to turn out. I’d planned out the pieces, worked up descriptions of the objects involved and laid out how they’d all integrate together. The code was well-structured and was something that could be both easy to maintain and simple to expand – that is until the customer decided to get involved.

If you’ve worked on any kind of larger project for any length of time, you know the cardinal rule – the customer never knows what they want. Even when they say they do, show them a demo. Their minds will freak out with new possibilities and new features that were never even conceived of in the first versions you’ve developed. Now, this isn’t so much of a problem if you have the customer/client reined in to keep these sort of things under control, but if you don’t…let the bad code pour in.

It never fails – at least one of the new features that the customer proposes as a “strongly like and might need” for this version will go against the code that you’ve already written. I don’t think I’ve ever heard of a project that was able to augment what they were doing mid-stream (yes, even you agile folks) to accomidate every request the customer could make. Some things are easy, but most of these sort of changes are hard.

This is when it gets very hard to keep that “good code” in place. It takes a lot of practice and skill to keep things flexible enough to make the impact of these sort of changes minimal. Writing good code from the beginning is easy – making that good code stick through to the end is hard.

How hard are you willing to work to keep that code good?

Photo credit snappED_up