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
blog.phpdev 
“…the customer never knows what they want…” Nail on the head my friend. So true. I long for the day when a customer says. “Do what you think’s best…” Idealist? Maybe.
LikeLike
Sad but true. I believe it’s almost impossible to keep the code clean when the requirements change. Nice post!
LikeLike
The good news is, we can always maintain the good code for as long as we want. The “fast code” maybe would solve the problem at once. But if we compare it to the maintenance in time, it sometimes make troubles. Especially if we use the “fast code” from others (a.k.a plug-ins, snippets, function, etc.)
Of course, the “fast code” in this type could become a very good code if we understand how they work and for what purpose. I’ve also been in many projects for many years and in relation with many customers/clients. You’re right. They never know what they want until we show them demo. Although we do show them the demo, I’m still sure they really don’t clearly know what they want.
LikeLike
Any code that does what it’s supposed to do when it’s supposed to do it is good code. Code that falls over, code that costs more than it’s worth, or code that is too late to do anybody any good is bad code.
Any other definition is asinine. I am my own customer so I am always happy…
LikeLike
As you said, “Their minds will freak out with new possibilities and new features that were never even conceived of in the first versions you’ve developed.” so I consider it important to clearly define the project and explain to the customer that you are billing them for X, not X Y & Z if they happen to arise. At this point I explain that to most people before beginning a project so I can code it to completion and only after completion do we start over again with the whole process of request > quote > code > test > completion. It seems to always allow me the benefit of creating good code over simply “gluing in another feature” on a whimsy request. It also forces the customer to put more thought into their new ingenious ideas. It’s easy to get caught up quickly gluing in features if that’s the way you interact with your customers. I’ve done it but now do my darnedest to avoid it. It’d be ideal if the result of a customers light bulb turning on after producing a custom solution for them was considered a service & incorporated into your work rather then a cumbersome problem to be reckoned with but that’s just my wishful thinking. I prefer good code. Hire someone else if you want your building constructed of super glue and particle board.
LikeLike
good article! I think so!
LikeLike
Its hard making decisions about code in this way and I often find the simple/fast “wrong” solution doesn’t occur to me in the first instance and I find myself saying “well actually” in the middle of a sentence.
As coders we always have a vision of perfection in our heads that we can never quite realize when it hits the computer screen. The problem is we are not building something to be viewed in an art gallery and most of the fruits of our labor are only appropriated by others like us. Even amongst ourselves there is no one consensus on what good truly means.
Chris hits the nail on the head with “it’s someone else’s timeline, someone else’s thoughts you’re trying to put into code” perhaps we should judge ourselves on what that someone else thinks more than the amount of technical debt we leave behind.
LikeLike
@david hmm, i’m not sure that all working code could be dropped into the “good code” bucket. There’s boatlods of lines of code out there that people just days into PHP have put in place (sometimes on production systems even!) that makes most of the worst practices cringe. Thankfully, this level of development seems to get better soon after starting, but there’s always the possibility. It all depends on the context, of course.
@josh man, I wish I had clients like that – I think we all do! It’d be nice to lay out the process in front of them and say “okay look, here’s how things are going to run…” and get their understanding that tossing things in mid-stream is one of the worst things that could happen to their project.
LikeLike
Nice piece ;D
Well, still the code’s quality depends on the pespective don’t you thing?
I mean, from the point of view of the client, as long as he/she is satisfied; the code works as efficiently as the customer requested. Being some parameters such as speed at run time and size.
Of course, it would be wonderful that all the code was as efficient as the craftsmen working on it wished it would, but the end user is the one who has the final word don’t you think? So, if it’s a personal project your point of view as a programmer or designer doesn’t have as much priority as the point of view of you as the end user right? XP
Well, just my thought.
LikeLike
It also really depends on how you develop the code and what process you use to communicate with the customer.
If anybody’s still using waterfall-style processes, good code is about as likely to happen and survive over time as winning the lottery. In literally scores of waterfall projects I’ve worked with or observed, I can think of exactly one that had any sort of “good code” associated with it — and that was feasible because the regulatory requirements for that software were 95% of the spec; what remained was branding and minor UI details. Since the regulatory environment changed slowly and predictably, with lots of lead time, keeping good code current wasn’t really all that difficult. But that happened *once* since 1979 – when I got into this craft.
On the other hand, I was doing agile long before there was Agile – back when it was called “Lockheed-Martin Rapid Quality Iterative Prototyping” and five or six other variations before Kent Beck and crew brought it all together. My historical project metrics show that the *third* agile project I worked on was *four times as productive* as the best waterfall project ever (that hyper-regulated system above). You may or may not make fewer mistakes, but you will find and fix the ones you make faster. Keeping code “good” in an agile process is *part of* the process – the old “red, green, refactor” iteration ensures that you’ll have as few surprises originating in your code as our craft is presently able to deliver. It’s not perfect – but it does help keep all the stakeholders in the loop and honest about schedules, costs and deliverables. That in and of itself, in my view, is well worth the price of admission.
LikeLike
@jeff What a great quote… “If anybody’s still using waterfall-style processes, good code is about as likely to happen and survive over time as winning the lottery.” Agile and other non-waterfall methods definitely help the situation, but there’s no denying that it till takes a special kind of effort to keep “great code” from becoming “good code” (and even slipping down into “bad code”).
LikeLike
Great article.
Delivering requirements to the satisfaction of the customer and meeting your own requirements for good code are two disciplines that I feel are very hard to master. In my opinion clients operate on a very visual level with regard to what they have asked for and in understanding what they receive.
Personally, I find it very useful to present clients with visual representations of each iteration during a development project. I do this in the hope that I may freak their minds out at a stage where I can easily integrate their new requirements. I pin them down to each iteration contractually before I start and they pay for any major requirement outside of the current iteration spec.
That said, If I think I can accommodate their changes without too many problems or I feel that making the sarifice would benefit the client/contractor relationship in some way I will work it into the current iteration.
This way I find that I can accomplish a product that meets both my client and my own standards.
LikeLike
Think of code clean-up as optimization. We all know Knuth’s mantra – “Premature optimization is the root of all evil”.
So, why not write code quickly at first, and take the time later to make it cleaner incrementally as you go? The customer / employer doesn’t care what the code looks like, as long as it works properly. Therefore, your code clean-up is basically for yourself and no-one else. So, why not spend your free time doing this if you can, else leave a comment of apology to the next developer, 😛
P.S. Your amount of free time is relative, but I am currently working 60 hours a week, taking Masters courses, and working on 2 freelance websites (and somehow my code manages to stay clean). It really depends on you…
P.P.S. This is why a hard set of requirements are elicited in the first stage of any software engineering model – to prevent “snowballing”. I always set up a relatively hard set of requirements with a set maintenance rate for addendums. If you allow the client to change your requirements mid-project, simply reply “Yes, we can do that. Do you have $XXX / hr for the maintenance rate?” 90% of the time, they won’t, and when they do, you’ll be making more money for your sleepless nights, 😀
LikeLike