DESTRUCTIVE THOUGHT
How much of the project life cycle is consumed by maintance ?
(10 marks)
How can coding standards and choice of language influence this ?
(15 marks)
I care 
Tho I do laugh at my own code sometime. When you go through all the crap one writes to make something work. Cleaning it all out to leave only the working part, some of that junk that creeps in can be entertaining.
In an “I actually write that crap?!” sort of way.
The customers might not care about how my code looks but my co-workers sure will.
Steve McConnell recently blogged about “technical debt”, which is the other side of this:
http://blogs.construx.com/blogs/stevemcc/archive/2007/11/01/technical-debt-2.aspx
Sometimes you do have to write or extend a system which has fundamental flaws, but you are creating a debt that has to be paid back at a later date, with interest.
Any work on software that has gone past it’s natural life is slower and can be become demoralizing, which creates a tendency to put off doing what is needed, and fix unavoidable issues with easy hacks. The whole thing is then on a slow death spiral, and will probably be replaced with a totally new system when nobody can bear to work with it any more.
I suspect that the underlying problem is that the Bugzilla codebase is old, so it has grown crufty, and the architecture feels dated and cumbersome. In this MVC/AJAX era the architectures of a lot of older Web applications probably now seem clunky.
Yes. It’s surprising that most application developers forget that what’s important in the end is what the user can use. Nothing else.
I would think that it’s partially correct. It’s like the ‘greener’ or ‘ecological’ choice : A incandescent light bulb “works” for the end user but CFL or compact fluorescent lamps are better and cheaper in the long run.
it is true that no user cares what the code looks like. it just has to work.
the problem here is that making it work, or keeping it working is so much easier if the code actually looks good.
so obviously if you don’t have to change a function you don’t need to refactor the horribly written function, but when you have an idea about how to implement a new function of your program, but can’t seem to make it work with the current code… make it look pretty. make it easier on the next poor soul who has to change something.
Directly you are right, no one cares about the code.
Indirectly they do.
For instance customers should care that iTunes is written like a dung heap. We know iTunes is written poorly because it uses hardcoded paths to find Quicktime. It must be a tangled web of crap for Apple to not be able to change it.
Why would a customer care that they use hardcoded paths? If they are on a x64 machine and want iTunes to find Quicktime… they should care.
(iTunes looks for Quicktime in C:/Program Files/Quicktime, which it will never be in on an x64 machine)
They should care that the reason an iPhone can’t be synced to iTunes on an x64 Vista box is such crappy programming.
As someone who has been programming for only 2 years… I’ve been on projects where the only thing i can to is scratch my head and wonder if the person before me ever read an OOP book ever. My code isn’t great but i try to make it understandable for others. If only to make sure a jr developer doesn’t waste a week.
Speaking as someone that is both a CPAN admin and has actually hacked on Bugzilla, I’d have to say that bugzilla is quite possibly one of the worst web application codebases I have ever seen.
It was utter crap, even by 1998 standards.
The PROBLEM, if any, is that Perl was powerful enough and flexible enough to let a badly written product by mediocre programmers rise to become one of the world’s most popular bug tracking systems.
(Which is also the primary value of PHP according to Rasmus)
@rfunk
"I’m amused that this appears around the same time as Steve Yegge’s latest missive. “It turns out you have to have something bad happen to you before you can hold my minority opinion. The bad thing that happened to me is that I wrote a beautiful game in an ugly language, and the result was lovely on the outside and quite horrific internally.” (Which made it unmaintainable and he had to take it down.)"
I’m having trouble with this idea of “had to take it down”. According to the post, the game “needed” some upgrades, so he had to remove it. And yet people were happily playing it up till that point. So what were these “needed” upgrades. Were they just desired upgrades that the programmer felt were essential, or were they truly necessary (e.g. crashing/security).
Because otherwise, this actually proves Jeff’s point. The users didn’t care that the game was buggy/out of date. They didn’t care that the code was 10 years worth of bloat. They just ENJOYED THE DAMN GAME. And then it was taken away because… the code wasn’t pretty. And now they’re mad.
Reminds me of this week’s xkcd. ( http://www.xkcd.com/359/ )
“Guys? Didn’t you hear me? STOP HAVING FUN!”
Also, 9 freakin’ pages? About how bloat is wrong? Is anyone here familiar with the term irony? (Actually, is this irony? Meh, it’s the world’s most misused term, it’ll pass)
Yes, ugly code that works is only good for the short-term. If you want to go the long term you must have well factored code. Remember, quick-and-dirty only works on a clean codebase! Mabye we shouldn’t care so much about customers and managers not caring about our code.
I worked once at a company where refactoring was considered evil and “unproductive” because it didn’t add new features. How narrow-minded is that!
I disagree.
The customer may never see your code, but when they want some new feature or they find a bug they’ll care what it’s like. That’s when you have to haul though all that ugly code and try to explain to the customer why it’s taking so long to add some simple feature or fix that bug. So indirectly they do care about your code. Like the way you care about the design of your car’s engine - you might never bother to look under the hood, but you’d be mad as hell when the mechanic hands you a bill for a couple of grand just to change a spark plug because the car’s designer decided to stick it somewhere that requires the entire engine be dismantled to replace it.
I agree that developers should develop applications that deliver what the customer has requested. I also think we should spend more time on making things look good. But I think time needs to be spent making your code pretty. That’s pretty in the sense of using a good design and looking for ways to make it easy to enhance the application at a later date.
albear said :
quote
I complete agree with you Jeff, I have been saying this to my coding team for years, people only care if it works and how it works e.g. user experience
The most important thing is to have it work, and release it on time and to budget. only after these factors you take what its written in or the underlying architecture into account.
There is no point is writing it in the newest language and making sure its the most elegant code, if you deliver the project half working and late.
/quote
This is pretty much word for word what all the worst managers I’ve come across have said about coding. Architecture, code quality and language choice have a pretty direct effect on releasing “on time and on budget”. This is especially true after the 10% of a program’s lifetime spent writing v1, and you get into the 90% of time you’re in maintenance mode.
There is not point in writing crappy code that “just works”, or you are pretty much guaranteeing all future work will be “half working and late”.
And this is before you get to things like employee morale.
As for Jeff’s remark that “perhaps we should also focus a bit more on things the customer will see and care about, and less on the things they never will”, well, that’s just plain wrong. I want the joints in my furniture to be well-made whether or not I can see them.
We should focus on both things. To do otherwise is both unprofessional and detrimental to your business. One does not have to come at the expense of the other.
Except possibly if you use Perl 
This is the mentality of “engineers” that more often than not hack together code rather than write good software. What the code looks like is very important. The aesthetics of code is something that should not be underrated. As others have mentioned, in the long run you pay (and sometimes dearly), for a poor codebase. Dealing with code that’s worse than a dog’s breakfast will hurt you down the road when those users want things, and want them now. You’re tangled up in a web of hard to decipher and maintain code and are slowed to a crawl trying to deliver the same quality product you may have had at the start. It’s an uphill battle.
Yes, you have to be pragmatic about time, schedules, cost etc., but you also have to take pride in what you do and the codebase is the core of the product. Everything depends on that codebase.
Not caring what the code looks like is the view of the code hack and manager who doesn’t care about anything, other than getting it to compile and out the door as soon as possible. And that way of thinking is a mistake.
Reading this was a friendly reminder, and I am glad you posted it. I can admit that at times I tend to nitpick at my code changing stuff that, in the end, is totally insignificant and not worth the time spent. I used to do this all the time. Over time I realized it and started stopping (lol). This friendly reminder to keep it up should be all it takes to shake that bad habit completely.
Writing good looking code is definitely not to be shunned, but you certainly gotta draw the line somewhere. By the way, reading about ANY code base written in PERL makes me laugh hysterically. Them poor bastards.
At a conference I attended, the speaker said that as we don’t care about how the phone system works, we only want to get a line when we dial 9 and we want our customers not to get a busy signal, the rest of the organization doesn’t care about how we do our jobs. They only want their systems running.
Anyway, when we do things right it’s us who reap the benefits of that.
I agree that users don’t care about how pretty the code is. I don’t care what my engine under the hood looks like, as long as it works. But when something goes wrong and a professional has to reapir it, the job has a much higher chance of success if everything is orderly and clean. I wrote a multiplayer-mspaint program when I was learning Java a few years back. It wasn’t too extensive, it worked fine, but it was written terribly. I abandoned it for a year and when I decided to resume the project, I couldn’t understand my code. It was really painful tryting to figure out what was going on. My point is, even if your code works for the user, it may not last long when the base gets too cluttered with bad code.
"I want the joints in my furniture to be well-made whether or not I can see them."
Really? So you actually care about, for example, whether they used flathead or phillips screws in the joints? Or whether the frame’s sanded? Or whether
"Like the way you care about the design of your car’s engine - you might never bother to look under the hood, but you’d be mad as hell when the mechanic hands you a bill for a couple of grand just to change a spark plug because the car’s designer decided to stick it somewhere that requires the entire engine be dismantled to replace it."
Yes, if you make stupid decisions during the creation, there’ll be problems, but that’s not a language-dependent issue. (I know, heresy, right?) You probably don’t care that much about what metal the plugs are made of, as long as they conduct. Or do you check with the garage every time you buy a car?
Anybody that frequents this blog post should know that Jeff is a fan of well written ‘beautiful’ code. We’re mostly all programmers here (professional or hobby), and we love beautiful code too. I think people are getting a bit caught up in a few sentences and failing to see the point of the post.
The point being - even old code, that isn’t particularly well-written, can sell and be used by a significant audience. That isn’t to say that as long as it works it’ll sell. But from a user standpoint, they don’t care.
I took the point of the article as Jeff re-clarified in his comment: strike a balance. Perfect code is extremely hard to reach and the customer will usually suffer for it - because it takes so damn long.
Write the best code you can then come back to it if there’s time. If there’s a significant problem spend the time to write a good solution instead of an ugly hack. But if it comes down to a marginal performance gain or a marginal maintenance gain - and it’s going to take you 3 weeks to do it… wait until a future update or forget it completely.
Every programmer, does (should) care what their code looks like. If you are working on a product then there is more room to maintain and improve old code. It is in your interest and the businesses interest to do so as this keeps the maintenance cost down in the long run.
From my experience, project based work is the nemesis. Here you are asked to add x amount of functionality in the minimum amount of time, often working on code developed else where. You just don’t have the time or the luxury of cleaning up the old code. Instead you find yourself layering on new code over old code while keeping you fingers crossed that your change isn’t the change that breaks the application.
The programmer cares about the code, but the project manager doesn’t. They’re the ones who are measured on delivery on time, on budget and on spec. Their perspective is purely myopic. They can see to the end of the project and no further.