The sad thing is how good code can be forgotten and left to gather dust as easily as bad code can persist and gain fame.

Assuming that his nickname isn't used by too many others, this should be Max: http://www.mozillazine.org/members/profile.html?user=11230

Thus his name is Max Kanat[-]Alexander.

- m_eiman

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.

I'm agree with you halfway. As was stated in your quote from max. Bugzilla updates slower. It's all good now, until it can't stay with the pace of the other programs that come from behind. And I think that is the general thing that happens when you have messy code. Bug fixes and new functionality become slower and more tedious since the code gets messier. It slows down the whole update process. In the end the users will be notice this and move to the application with better functionality and less bugs

I really wish there was an edit function here. I'm not awake yet, and it reflects in my typing

Even though you customers doesn't care what your code looks like in a working product, the second something isn't working as it should, they will be very pleased that your code is structured and you have a fix ready in notime.
Maintainting your own methods of 1500 lines is no problem. Attempting to maintain a method of 1700 lines written by an inexperienced and unavailable external developer is painstaicingly.
I just spent 3 hours finding a mistyped variable in c# code. I whish this code had looked a lot better, and I intendt to make shure it does befor it reaches the servers of our customers.

Andreas

Oho! Nice post. It gets the point across, but there are some vague concepts.

I care what my code looks like. I work hard making sure my code is easy to read, easy to understand, in addition to doing what is expected of it.

Normally, the end user won't care.

They will start caring though, when an error is discovered. Programs written poorly take lots of time and money to fix. Programs that are written well take less time and money to fix.

Beautiful code is code that is easy to maintain, unless there is such a thing as a zero-maintenance system.

Silly! Of course I care about what my code looks like, and I sure as hell care about what my team members code looks like. Theres a high likelihood I'll have to deal with it sooner or later.
Next time you feel the urge to write an ugly hack so you can go home early, remember this: requirements change and someone will have to read your code.

If it works and does what they want then users do not care what the code looks like or what language it is in...

As soon as it does not work or they want you to change it, they still technically do not care, but they soon complain when it takes you longer to fix things ...

Jeff makes a good point,

Perhaps sometimes we focus on things that do not matter. However another point is that people, as in the customers, do not get a peek inside to judge the quality of the code by the coding standards, at least in the proprietry world.

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)

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.

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 :

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.

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 :-)

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 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?

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.

Users don't directly care about the state of the code, that's right.

They care about what affects them which includes bugs, the pace of development and features they need.

And all of those are affected by the state of the code.

[)amien

Max was saying that he thinks they should consider changing to a different language because of the amount of time involved when coding in Perl is greater than the amount of time his competitors are spending doing similar things with different languages.

That's not really the same as Max saying that he cares about how his code "looks".

bad code does take longer to maintain - so I think I missed your point in this post.

:)

"But 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."

This is kind of a chicken and egg situation if you ask me but I would argue that how your code looks will have an immense effect on the customers overall experience.

The easier your code is to understand, modify and debug the more time you can spend on the user experience and the better the end result will be.

Not to beat an already dead horse, but I think you are off base here.

Code quality matters. Code quality is completely invisible to the users and marketers and sales droids and CEO. However, its effects are nebulous yet dramatic: projects taking an extraordinarily long time to complete, long break/fix cycles filled with unexpected regressions, innovation stagnation. These are highly-nebulous effects. How are you to know if Widget X is taking a really hard time because your codebase is stuck in 1989 or because making widgets like Widget X is just a complicated problem?

Code meeting customer goals, working, performing well enough, getting sold: all these things are first-level effects of your product. When they are no happening, you know immediately. Fixing these is an easy task to diagnose (relatively speaking) and engineer.

It is, therefore, a great engineer who concentrates more on the "cleanness" of his code, its maintainability, its documentability and documentation, over the specifics of the feature set or performance. The entire rest of the company can bring those deficiencies to his attention, if they exist. Only HE can see that his code is structured like ropey pasta and takes a 100-page dissertation to explain the whats and whys of a 2-screen method.

@Brian:
"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."

You say "You just don't have the time" ... who defines what time you have? If it is a poject manager making up engineering LOEs from whole cloth then your organization is severely F*'d. Get out while you can, or change it from within: it will implode in just a few development cycles if this doesn't change!

It is true that there is a tendency for projects to be under-estimated and over-scoped, but I'd not blame it on project-based work, but rather on a poor management (and this is the part of the engineering manager, not the engineer, unless no such beast exists in the organization) of LOEs from engineers. Engineering managers should always be asking their engineers: does that LOE map to the "right" solution or the "easy" solution? What are the long-term impacts of this solution on the code? Are there smaller-scale bits we need to add to this project as dependencies? This will get sent up to the project after having been multiplied by an escalation factor (ideally specific to the engineer and his past estimates as well as the relative state of the code being modified and the risk attendant in the project).

The time you have is what you define it to be. If that is not enough time, you need to revise your estimates up (this project) and learn to be more conservative in the future (next project).

The responsibility of the project manager is to take these LOEs and put together a project plan which keeps everyone busy and makes the dependencies and high-risk items get developed first. It is, further, to track progress on tasks at the high level to make sure the overall plan isn't falling behind (or, rather, to react properly and quickly when it does). This is plenty of work for the project manager; he shouldn't be adding "question the engineer and pressure him to complete a 2-week task in 3 days"!

Now, all that having been said, you ALSO have to schedule time for "engineering projects". That is, a project which does nothing other than fix the code you thought was good when you wrote it but have butted your head against six times in the last three months. There are no customer features here: this is an investment in all future features and performance. If your org can't allow these types of pojects, again, it boils down to the Engineering Manager to "slipstream" such efforts into existing projects, although this only works to a certain level (rewriting the app in a whole new language is unlikely to get slipstreamed into the "Add non-blocking relationships between bugs" project).

Moving to an open source model, you probably don't have anyone acting in the EM role, so all the above falls to the engineers. Seems like it all still applies though.

"we should also focus a bit more on things the customer will see and care about, and less on the things they never will"

Think of this scenario: What will answer children if you ask them whether to go to school or not? Or to wash their teeth or not? Many will answer they prefer not to. If you let them choose, many will choose the worst option, so if you change your ways depending on their choice, you also choose the wrong way.

Now, you ask a client to assign a value to a software product. And he's like a child: he hasn't knowledge enough (no "education") to do it right; so, probably he will choose the wrong parameters to make the decision, e.g., "how pretty it looks". If you support him because he and many people think the same, and you don't realize they are unawared of what is really important in software, then you support this lazy-man way of making decissions.

Teachers teach children to understand the right way of living, and programmers should also try to teach: a car is not good because it looks good, only a fool would think that!

But it's easier to go with the flow: I'll give you what you ask for, without trying to teach you that you are wrong, and that a well coded app has better mainteining, etc.
Really, don't you think that programmers should also be "teachers", somehow?

I think you would't say, as you do:
"and less on the things they *never* will".
Beacuse this word, *never*, also depends on you, and how you teach your clients!

Jeff in reguards to:

>>The next time you're knee deep in arcane language geekery, remember >>this: nobody cares what your code looks like. Except for us >>programmers. Yes, well-factored code written in a modern language >>is a laudable goal. But 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.

This sounds like when your boss is pushing you to get your code complete. (You might want to right a blog titled "How a product manager can affect coding style") But code complete is more than completing code. It is about being proud of what you do. It is about reading a book like "Code Complete 2" and putting those values into practice. It is true that the main focus on creating a program is to solve a customer's problem. But what you do behind the scenes does matter. It will especially make a difference during the maintenance stage. Never let anyone take your style, if not they are taking your soul.

The end user may only care about a pretty interface, but to get the pretty interface it is much easier to debug pretty code.

It is difficult to have a pretty application with ugly code behind it.

@Tom:
""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?"

No, but I imagine he does care about if the chair was built using oak or balsa wood. And, I do care about if my table is solid wood or micron-thin veneer when I go to refinish it.

More to the point: if the table being made was designed such that it needs a contortionist midget to screw the top onto the base, thus causing the factory to employ a fleet of contortionist midgets, thus raising the cost per table: I the consumer don't care overly much, I just buy the cheaper table from the guy that designed it right in the first place. Similarly, if you are working on a bad foundation causing your costs to go up and/or your agility to plummet, your customers likewise won't care nearly as much as they'll just pick a different vendor for whatever it is you produce.

In any case, the car analogy is better (as cars need service far more than furniture, although less so than software it seems). Does anyone care about the metal used in the spark plugs? Well, if it is the wrong metal and causes corrosion, you as a customer might care, and I as a designer or mechanic sure as hell care.

Poorly designed software is precisely equivalent to an engine requiring a complete rebuild to replace a fan belt. To hand-wave this scenario away is to hand-wave the vast majority of poorly-designed software (and, thus, the vast majority of software, period) away.

@Jim Cooper

i never said write crap code, what i was aiming at is dont always try to reinvent the wheel with new flashy architecture, using the project to test the lastest features.

This is what we as programmers like to do, we just need to remember that in the end there is a deadline (if there isnt then go for it.) and if we have to use an older style to hit that then although we might not like it, but that is what we should be doing.

I would never recomend that we dont use coding standards or write crap code. just dont always push for the newest flashest way toi do things cos you as a coder want to.. the end result is what is important.

> I would never recomend that we dont use coding standards or write crap
> code. just dont always push for the newest flashest way toi do things
> cos you as a coder want to.. the end result is what is important.

Bit of a pointless argument though. I've never heard anyone suggest the end result isn't what's important. Is this even disputed?

But as a developer, the code IS important, and I like it to be clear, commented, indented, logically designed, not relying on magic numbers or dirty hacks etc etc. Maintainance is often/usually (pick one) more expensive than the coding was, and I've seen enough crappy code where the end result met the user's requirements thanks very much.

@Tom

You're right, I don't check with the manufacturer about the metal used in the sparkplugs. However, I do assume that they're correct. I also assume that the engineer has done a good job while designing the car.

Customers do the same when they buy your software from you. They believe that the people who developed the software and are now willing to charge money for it have spent some time designing it. Developers should spend time developing quality software, ie. software that delivers the customers requirements, is easy to maintain and enhance and is reliable.

You are absolutely right Jeff, end users do not care one whit about whether it's written in Assembler or Ruby on Rails. All they care about is whether or not the end product satifies their needs.

This is of course how it should be. If you don't build a product that sells then you don't get paid, your company does not make money and you will find yourself on the un-employment line pretty quickly.

For us geekazoids, well, the language is everything. It is the tool that enables us to do what we do. To us, the journey is the reward.

But always remember, just like the homeowner who does not give on whit whether or not the carpenter uses a hand saw or a skill saw to cut the rafters, our users only care about one thing, the house that we build them. In their case it's not the journey, it's what's at the end that counts...

I generally have a rule. If I want clean, highly maintainable, nice code - I do it on my own time.

The primary goal of any software company is to make money. That's it, first and foremost.

Code is simply the vehicle to get you there. Now, clearly there's a difference between taking a rusty passion waggon and a Porche to get to your destination.

That said, there is often a point of diminishing return with how clean your code needs to be. As long as the code isn't "stupid" that's probably good enough for most businesses.

It's hard because as a developer I'm naturally a purist. Those instincts die hard in a start-up. If it's a choice between a hack that does it in a day and a more structured approach that takes seven then I'll take the hack.

Sure, the hack might cost more in the long run, but if I continually do the structured approach it may cost so much money up front that I go out of business. In short, I only have to worry about the bad code when I finally get some customers who are paying every month.

Learning that was a tough, harsh lesson of living in a real world small development team.

Simon.

Correction, in the above post I meant "If you build a product that doesn't sell the you don't get paid..."

So much for my own proofreading...

It's not quite as simple as all this. There's a delicate balance to be struck Jeff. Yes, you must meet the needs of your customers reliably and efficiently to be successful.

However in the long term business viability of your product you also need something that is cheap to maintain (shorter release cycles, smaller staff == more profit), something that is developed in a language that you can attract more talent too (larger talent pool == higher quality, lower costs).

I entered programming in 1998, when I was in college, they didn't teach cobol and rpg. Yes there are still these systems in the wild but you honestly couldn't pay me to work on them, I'd have to learn a dying language and it would do almost nothing to prepare me for my next job. These systems won't necessarily be replaced because they are faulty, most are rock solid, but they will be replaced because it will be too damn hard and expensive to find people to work on them.

I've always had a "problem" with worrying about how my code looks. I tend to spend way too much time playing with whitespace so that everything looks clean.

FWIW, all the 'pretty print' code that I've seen is wasteful. For instance, in the name of readability must we create instance variables of objects which are only going to be used once in a function. Furthermore, if it's a function that's called constantly. If it's only being used once, don't malloc to the stack. Then again, I prefer nested function calls and recursion; perhaps I'm just a sick individual.

I admire Joel and Fog Creek immensely for developing their own language, that is the stuff of geekery and hope they are smart enough to get it done.

I'm sure today's post will appear in the perlmonks meditations section, but it reminds me of another meditation one of the monks had. He was thinking about learning other languages to implement things and heard some advice from someone who told him to become a better Perl programmer rather than be a jack of all trades. I think that applies in most cases no matter what language you use. I'd love to translate loads of stuff I maintain from Delphi to C#, but when there's a whole framework that just works, few new features will be needed and I don't know C# well enough, it's better keeping it in Delphi and refactoring it to be a bit more sane.

The language comparison on the bugzilla wiki was interesting and from that it's not clear that Perl is substantially worse than its competitors. I think the issue is probably more design related. I love Perl, which is why I agree with most of the cons, but I'd say some of them are DWIM (Do What I Mean) features, like an array in scalar context is actually its length (although sometimes I have had to use $#array for the length rather than @array).

I wanted to extend Bugzilla for my own company's use (probably site specific, so wouldn't be distributed), but I took one look at the source (we're using 2.20) and developed a parallel system. Which is a bit annoying because it doesn't automatically link together, but hopefully it will do the job.

I think everyone's missed one important point: Bugzilla is an open-source product, not a closed source one like Joel's. Open-source projects need to satisfy users who might want to graduate into being contributors on the project, not just users who will never see the code. As Max says in the original post:

> My understanding is that he re-wrote it in Perl because a lot of
> system administrators know Perl, so that would make it easier to get
> contributors.

I know that a few years back when I got a small software house using Bugzilla, the fact that a few of us knew enough Perl to customise the code for our use was a significant bonus.

Another concrete example: I use the Unison file synchronizer, which is written in OCaml. The choice of language allowed the original developers to get their ideas implemented really quickly, and as a simple user of the program I'm happy with their decision. But if I want to contribute, to fix bugs or add features, my first obstacle is learning a new programming language which I have no other real interest in. I believe that the choice of programming language in this case has limited the number of people who can transition from being a user into being a contributor and then a developer.

Or you could just be like MySpace, and write code that is all at once terrible and ineffective, yet still be insanely popular.

what your code looks like will start to matter when a customer asks for a new feature, and you take way too damned long implementing it because your code base looks like Britney Spears' career.

Users generally do care that the underlying code is pretty. Well, I should rather say they care that the application will be developing and improving. Which is in direct correlation with easily modifyable and sustainable code. Which is in direct correlation with pretty code.

A good analogy is a car engine. As a driver, you only care that the engine works so that you can drive to and from work. But when you need engine work, you do care if the engine is designed so that the corner mechanic can fix it, or if the shop has to special order parts from Eastern Slobovia.

Clean design matters. What language is lees of a concern, unless you are going beyond the constraints of the language (high-performance web servers in Visual Basic, or predicate login in C).

I like Simon's comments.

"Those instincts die hard in a start-up."

The reason so much code looks bad these days is that it is built upon a successful startup. These people are, by definition, concerned only with what is immediately valuable to the customers. If they aren't they go out of business.

The big factor here is leverage. For a startup, the market saturation is small, the investment in development can only be leveraged a small amount. For established projects, however, the leverage is huge. Most companies spend something like 10% of their revenue on development. This means that the development work has a 10x leverage. Do you really think that companies care about developer productivity when they get that amount of bang for their buck?

I don't care about the quality of a code base if:
a. I don't have to work with it.
b. It is thoroughly documented and has a thorough accompanying set of tests.

Poor code is slower to change and you are more likely to introduce bugs through a change if it is not clear how it works.

That is why I think code quality is important.

(Bugzilla is my favorite tracker)

You missed the point of that message. Max said, Bugzilla cannot keep up development pace with other trackers because of the fact that it is written in Perl. This is why he was advocating switching to another language. If you had been following the bugzilla mailing list, you would have recognized that this discussion has largely fallen wayside as of late. Max was wrong about the Bugzilla codebase; there are several reasons it hasn't advanced in recent years nearly as much as any competitors:
1. The old codebase was horrid and extremely difficult to advance
2. Most bz contributors were not software engineers, rather most were sysadmin types who use Perl as a batch scripting language (the 5 liners rather than the 50,000 liners)
3. Most mainstream software engineers (the ones used to maintaining programs the size of Bugzilla) don't know Perl and hence are very unlikely to enhance it (though this is arguably not a correct statement)

Around version 2.16 of Bugzilla (2003), enhancements had become so difficult to add that it almost wasn't worth it. 2.18 and 2.20 were both welcomed versions that fixed a tone of things that should have been fixed, but still they were built atop a codebase that was effectively unmaintainable. Max and fellow devs have done an enormous amount of refactoring work to get the codebase in a much better place today (this is one of the biggest reasons the last release was 3.0 instead of 2.x). The codebase is still getting architecturally better and as it does, enhancements will continue to become easier to do.

yes, yes, Jeff... yes... but then again NO, sorry.
End-users don't care about the look of our code base.
Customers don't care about the looks of our code base.
Both end-users and customers, though, care about the cost of fixing a bug or introducing a new feature. And *that*, I fear, is directly related to the state of our code base, which includes its 'look'.

F.O.R.

As a consultant, making code well organized and "pretty" can be very important. My customers often take over maintenance of my code as soon as I'm done with the contract, and they often have very stringent requirements on coding conventions. It's amazing how important they can make it. Still, I'd agree that the first and most important thing is to have code that just works. In the open source world, even though the projects you work on are often a labor of love, you are still working in limited time in the wee hours of the morning, and often don't have time to comment and beautify your code. From the end-users point of view at least, all that matters is that the code works, but my customers really do care about how the code looks. My coding philosophy has always been, code until it works, and then clean & refactor until the time runs out. If there is limited time, they will just have to deal with sloppy but working code.

I totally disagree with this one, Jeff.

You first explain in detail why *customers* don't care what your code looks like. Fine, I agree, customers don't care what your code looks like or even in which programming language it's written.

But then you silently change "customers" to "nobody" and conclude that *nobody* cares what your code looks like.

The article totally lacks any argument why *nobody* (instead of just *customers*) cares what your code looks like.

And ofcourse I don't have to explain how important it is to make code maintainable. Code is written once, but read many times - good code is *readable* code.

Ok, sure, the bottom line is you have to make a product that works, ugly code or not. But I would say that generating ugly code is a bad practice. A good developer who takes pride in his work will always attempt to write elegantly structured code. I say if you're going to do a job, do it right. You can clean a room by shoving everything into the closet or you can put things where they belong. Which way is better in the long run? Hey, we all have written code we're not proud of, but whenever possible, strive to beautify your code.

My experience after 16 years in the biz is that:

Customers care about features, cost, support, does it work and how soon can I get it.

Customers don't care about programming languages, how hard it is for you to maintain or even what technology is used - that's your problem.

And – the only interface customers care about is the user interface:

http://softwareindustrialization.com/WhatsNewInSoftwareDevelopmentFor2006Part3.aspx

andemann is absolutely right. The problem with Bugzilla that they are pointing out is that it is too hard to maintain the code because it is too difficult to enforce any kind of standard.

On the surface, no the users could care less. I have tried to explain code to people before and it makes no sense to them that words on a screen can end up as their favorite video game. What they do care about is when it takes 3 months to patch a bug because one developer spends 2 months and 29 days figuring out what another guy wrote. THAT is where the value in well structured, well written code is and I could make a case that the customer ABSOLUTELY cares about that.

@Eric Wise - They didn't teach you cobol and rpg in college because they are not good languages for teaching the *concepts* of programming. If you think you're going to learn a language in college to prepare you for work, then they should also teach you how to prepare for a short career. Classes in college should teach you concepts, not languages.

You need more than comments and well written code for open source projects. I think you need a SDK, a data dictionary, and clear instructions on how to implement typical customizations. For example, I customize a shopping cart where a typical change would be to add a new field to the customer address. All of the steps to modify the code to accomodate a new field should be documented. You should also document solutions for frequent problems and difficulties reported by developers.

Disagree strongly, Jeff.

The user interface is *not* the application; the user experience is. It's a subtle distinction, but very important. Things like crashes, arcane error messages, spinning pizzas of death, and slow window updates disrupt user workflow and provide a bad experience. In HCI terms, the application moves from ready-to-hand to present-at-hand: the user is no longer focused on the task but on the application itself. A bad code base is a chore to trace, difficult to debug, and impossible to tune. Bad code oozes forward to the user experience. Bad code reflects sloppy thinking.

Honestly, a good developer and work his way through any code that works, even if it does look like spaghetti. The reason many developers complain about "sloppy code" is because they are amateurs. Complex applications with high performance code, complex mathematics, or maybe a complex custom painted GUI, are going to be ugly. Often what seems ugly is very beautiful and creative to another developer that can see the efficiency and creativeness that was involved.

Reminds me of a quote I once read:

As a user, I don't care if I get my job done with hierarchical, relational, or object-oriented databases (or black magic, for that matter). All I care about is getting my job done.
―Alan Cooper

As developers, we often need to re-focus on WHY we're actually writing this software.

Perhaps Perl 6 (and Parrot) will pull Perl back up into the competition?
http://dev.perl.org/perl6/
http://dev.perl.org/perl6/faq.html
http://www.parrotcode.org/

I'd like to know the name of this opensource database..but anyway, I tend to disagree with the bulk of the article.

A user might not care about the code since s/he will never even glance at it, more so if it is propietary. However, the quality issues related to bad code will filter down to the user eventually, whether it is the long time to release an update, or fix a big, or the high cost of maintenance.

Eventually, upon seeing these problems, the user will probably realise that something is wrong, and change supplier.

But what I think you mean is that it's useless to use the newest kid on the block simply because it's there. One should adhere to well tried and tested programming techniques, not get obsessed over the latest programming methodologies.

Customers care if you stay in business. Code that can be easily expanded and modified, thanks to its design and language of implementation, leads to lower Cost Of Goods Sold (COGS), thanks to lower maintenance costs to the developer, and hence lower cost to the consumer or greater margin to the seller.

No one has ever shipped a perfect product.
And you aren't going to be the first.
Bad code that works is still bad code.
No design ever survives its implementation.
The only code that doesn't change is code that's never used.
Code is frequently the victim of its own success.
The lastest thing is not necessarily the latest best thing.

http://coverclock.blogspot.com/2007/07/irresistable-force-and-unmovable-object.html

Nobody cares what your code looks like.

Until the fact that it is so freakin' ugly means that people miss obvious errors and spend 5x longer debugging because they can't find what they need.

Trickle down.

All I know is this: every application software millionaire I ever met made has it on an old code base. And I've seen many who should be rich ultimately fail because of this sort of urgency to rewrite their applications.

"But 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."

If your customer ever asks for features, with this viewpoint, you're done for. Unless you're banking on the fact that it will take you longer to hack your own code and therefore charge more.

Overall, functionality and code style are hand in hand. If you favor one over the other, you risk major issues.

Case in point: I've spent the past few months completely rewriting a core piece of a product because of one key issue. Nobody could figure out how it worked...

If you need to add a feature or fix a bug in horrible code, it's going to take an exorbitant amount of time. Time that the person who wrote said horrible code is now costing you.

-Clif

"Customers do the same when they buy your software from you. They believe that the people who developed the software and are now willing to charge money for it have spent some time designing it. Developers should spend time developing quality software, ie. software that delivers the customers requirements, is easy to maintain and enhance and is reliable."
Of course they should. I'm not saying that you shouldn't care about the product you produce, or that you shouldn't try to make it as maintainable as is reasonable.

But, at the end of the day I'd take a "90% feature complete" product that was hard to patch over a "60% feature complete" product that was easy to patch, because the chances of the other 40% ever being done decreases with each day of use. The only fixes/updates that will be definitely be done are those that are essential. And they'd be done for both. Oh sure, patches for the 60% will come out quicker, but the money's already spent, and you don't get called out by a company because "the GUI's not very usable".

It's the eternal lie; "We'll fix that when we have the time". Like anyone ever said, "It's Tuesday, let's go through the old source code and see what we can fix!"
Well... maybe at Google.

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.)

Sorry my link to Yegge's post got lost:
http://steve-yegge.blogspot.com/2007/12/codes-worst-enemy.html

> Neither Perl nor the circa-1998 Bugzilla codebase have aged particularly well over the last 10 years.

Why do people feel qualified to make statements about Perl who appear not to have the foggiest idea of Perl? Everyone knows it's a write-once language where you write executable line-noise. Hah hah hah. I've only heard those tired lines about a quadrigazillion times.

To the contrary, Perl has aged extremely well. I defy you to look at the code of any of the popular modules from the CPAN and tell me that it's an unreadable, unmaintainable mess. (Next, I invite you to show me another dynamic language that has anything which can compete with the CPAN.) Show me something, anything, that would back up that claim.

I'm just here to stand up for Perl. :-)

It's not Perls fault the code is crap, or is organized poorly, or has poor programmatic interfaces, etc. That happens in any language. Perl can be just as 'neat' and easy to use, and easy to extend as any other language.

Perl is not the problem here. The problem is that Bugzilla went way too long without code cleanup, without code standards (Perl::Critic) and without re factoring. Now it's paying the price by people thinking that it's easier to just start afresh with a new language.

Move Bugzilla to a new language. Ahead, I'll wait. And if that new version also doesn't have coding standards, a good programttic interface, and doesn't refactor often, it too will suck in the end. Then we can pick yet a 3rd language.

People will complain when you can't add features in a timely fashion, though, and that maps directly to "how it looks."

Is this article deliberate flamebait? Other programmers care, managers care (due to impact on timelines), users care indirectly (longer to release new versions, more bugs likely if code is crap). Has coding horror jumped the shark? :)

How does this not translate into good things for the customer? I know that, in the long run, they will care.

I'm thinking that the points Max and you are making are completely different, Jeff.
Max's point was that it was difficult to provide better features for Bugzilla or to maintain code standards in Perl (sounds like clean up time). Your point is that Max wants to abandon Perl for a modern code just look like they're keeping up with the Joneses.

http://www.codinghorror.com/blog/archives/001007.html
Hypocritical?

Excellent post again Jeff. This is exactly what got me into programming back in the day. We have to be artists and scientists for a really good program.

We're scientists in that we need to do good memory allocation, good architecture (for performance, maintenance, enhancements, etc.), interact with datbases, file systems, etc. and maybe even deal with platform issues.

We're artists in that we need to develop an application that the end user is going to enjoy using and continue to enjoy. On top of that we have to write code that is elegant to ensure that we can rapidly fix or update things.

On top of all that we get to be the middleman, balancing the "far scientist" end of bosses and technology issues against the "far artistic" that just wants it to look pretty and do X, Y, and Z for them.

I think everybody's post up to this point really nails this point home, no matter where the chips fall.

Sometimes code is consumed not by users but by other coders. Last year I was reading a numerical analysis paper and didn't understand its description of the author's algorithm. So I contacted the author and asked for his source code, as the paper had mentioned benchmark results. He responded with a piece of entirely illegible Fortran 77; he might as well have sent me an ASCII dump of /dev/random/ (and I _do_ read Fortran 77 passably well, as I know something of the LAPACK sources).

I think your post makes sense in the light of one of your earlier posts, in which you chastise people who talk a lot about pretty code but don't produce any code at all. One must start with _something_, and only then work on restructuring and improving the something.

Hi, I'm a user and this is straight on point. I should say I'm a user who's forced to be an analyst and design consultant for proprietary software. I'm very familiar with software we use to build the apps. Having said that, I'm familiar because I need to make judgements on putting in "cool" features versus being functional. Good and bad code is relative. I don't really care how my coders get from A to B just as long as they get there. If it's 15, 150 or 1500 lines from a user side I can't tell. Same applies to bad code if it doesn't go from A to B I don't care how many have to be re-written.
Jeff's blog is right on point. "we" don't care about the code just that it works.
Must say I'm amused as I browsed through the responses and some were defending code because it's cheaper in the long run and some talked of educating the user. Hate to tell. You're job is to write my code. I write the checks you get so let me worry about the money being spent.
The education of users if esspecially amusing. I worked on a project that I fully understood the business needs for and I communicated them clearly. Daily 2 coders pulled me into a room and said we can do it the right way or your way. Guess which way it was done.
As developers, programmers and coders you guys are geniuses about coding. Don't assume you know anything the business you're writing for listen to what they tell you and code it.
Just an observation.

Here is the latest news on Bugzilla

http://use.perl.org/comments.pl?sid=37834&cid=59445

"You missed the point of that message. Max said, Bugzilla cannot keep up development pace with other trackers because of the fact that it is written in Perl."

That is a bunch of crap. Sorry had to say it. It isn't Perl's fault that the code is crap...it is the programmers. You can write crap in any language you care to name.

Most people who say stuff like that have no idea about the current state of Perl and are talking about Perl from years ago. Like nothing changes at all.

"As long as the customers are happy with the delivered application"

Many developers are simply wrong about the definition of clean code.

They think Clean code is an ideal where developer's can walk up to a code base and get new features out of it without having to solve hard problems. That is called fantasy land, and there is a good reason that most successful code bases don't live there.

I'm not saying the idea of 'techinical debt' is wrong, or that you should celibrate the chores of dealing with a 10 year old Perl code base. I am saying that many developer's idea of Clean code has less to do with Technical debt and more to do with living in fantasy land.

Actually, it's probably no perl, it probably the age of the code base. I have been involved in software programs of a wide variety of size, and while the maintenance/upgrade costs are a function of program language and quality of the coding, it is often very much of function of the age of the code.

It's not that code rusts. If you don't touch it, it doesn't get older. However, continued tinkering, upgrades, fixes, new releases, etc -- each one of the changes not envisioned in the original architecture makes the code base more difficult to touch for the next time. There are two reasons for this
1) Adding capabilities and fixes is never as architecturally integrated as the original
2) The current user base must be kept happy -- requiring keeping compatible capabilities and feel.

I'm sure if you rewrote your system in perl today, you'd find that the new code base was easy to maintain. But you'd get even more advantage from rewriting from scratch in any language (including perl), as this would eliminate the need to stay compatible with the past.

It's the legacy costs that are eating you up. This can be see in industry also. New comers are more flexible -- they don't have the legacy customers to satisfy and they can start with a completely clean architecture.

Customers also don't care about whether or not you us a quicksort algorithm or a bubblesort algorithm. They do, on the other hand, care about the performance of your application, which your algorithm choice affects. They don't care about the algorithm directly, but they sure as hell care about it indirectly.

Similarly, you are right in that customers generally don't directly care what the underlying code looks like. They do care about things that indirectly effects, such as your ability to get it out on time, root out bugs, and apply fixes in a decent amount of time. Any professional software engineer can testify how code quality affects those things, thats why we spend so much time complaining about it.

Yes, customers don't care about implementation details. Way to go Captain Obvious. What they care about is the things that implementation produces.

It's strange, the developer lists reasons why the choice of language is harming (even threatening) the project, but your response is "who cares, it works"?

It's our responsibility to communicate why this matters. I have a client that everyday I have been beating over the head with "the codebase supplied by your vendor is not supportable, and if they change platforms, you are in grave danger of losing your customizations ...".

Guess what happened? In the move to .Net, the application will not support old customs nor the old database schema. Care about how the screens look now?

We have to get better as acting as our clients advocates, even if the communication between both parties goes like this:

http://activeengine.wordpress.com/2007/11/15/hang-dai-wu-hang-dai/

I'd have to say Perl has aged very well, particularly compared to PHP. I've had PHP programs run fine in one version, crash in the next, and then start running fine again in the next. Perl has been stuck on 5.8 for a long time because IT WORKS. Try creating an array with a few hundred thousand values in PHP, the memory use grows exponentially and when you try to access the values it returns garbage. Perl is much more stable and mature than PHP.

Anyone who says Perl is holding them back is trying to start a fight, or just ignorant. I get defensive when someone picks on my favorite language. :)

Ugh. This was thoroughly debunked on Max's original blog post. The fact that the code wasn't very good and unfortunately maintained by less than stellar programmers was *not* the fault of Perl.

Max received a number of suggestions regarding current Perl best practices and I hope took a lot of the advice on board.

Just to be clear-- at no point in this post do I advocate writing crap code. I find that developers tend to obsess over insignificant details in their code and often miss the bigger picture of how what they're doing will impact the audience/customer. It's the same thing I always say, really: strike a balance. Consider what you're doing, and why. Realize when you're going too far in one direction [excess code hygiene] or the other [quick and dirty 5 year hacks], and make corrections.

> This is the first post on your blog that I've strongly disagreed with. What a sad day.

I'm curious-- if you agree with *everything* I write here, then what's the point of visiting? To confirm what you already know? Personally, I find it difficult to learn from people whom I never disagree with.

> 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.) http://steve-yegge.blogspot.com/2007/12/codes-worst-enemy.html

I agree Yegge's article is great, as usual. Perhaps this is true for a one man development shop -- but is it true for an open source project like Bugzilla? Why didn't Steve just open source his game?

> I've only heard those tired lines about a quadrigazillion times.

I am by no means anti-Perl, but I've read and heard so many horror stories about Perl from developers that I trust and respect. Significantly more than any other (current) language I can think of. Max is yet another example. I do think there's a kernel of truth there.

> the developer lists reasons why the choice of language is harming (even threatening) the project, but your response is "who cares, it works"?

You'll note that Bugzilla is still written in Perl, and their wiki states that they probably won't switch languages for the forseeable future.

Ever look under the hood of popular blogging platform Wordpress? Your eyes will bleed.

You need to quit admiring your bellybutton.

> I am by no means anti-Perl, but I've read and heard so many horror stories about Perl from developers that I trust and respect. Significantly more than any other (current) language I can think of.

I've heard similar horror stories in every language I've ever used, and several I haven't. Perl by no means is the only victim of sloppy coders, but the language also has very few barriers to entry for novices and dilettantes. They often don't write good code, but they get things done.

Just don't hire them to maintain important codebases, and you'll be fine.

> Max was saying that he thinks they should consider changing to a different language because of the amount of time involved when coding in Perl is greater than the amount of time his competitors are spending doing similar things with different languages.

> People will complain when you can't add features in a timely fashion, though, and that maps directly to "how it looks."

It's true. There's no shortage of Bugzilla competitors. Many of them are quite good. Bugzilla has evolved very slowly, perhaps because it was written in 1998 in Perl, and was originally maintained by mediocre programmers.

And yet, as Max points out in his original article, the adoption rate of Bugzilla is *growing*, and it's actively used today on many of the largest and most important open source projects in the world.

What conclusion can we reach, other than the obvious one: working code trumps every other consideration. Yes, in a perfect world, that working code would be well-factored code written in a modern language, too. But that just doesn't seem to happen very often.

@Jeff (the analyst)

Your opinion is certainly valid from a user standpoint. From a standpoint of a developer, the code still has to be maintainable. If all you care about is that the code works, it's probably going to have little or no documentation or comments, be written in a haphazard manner, be poorly formatted, or all of the above. I have taken over many projects from other people, and I know this to be true.

As to this article, Jeff (Atwood) could have used a better example of why users don't care about bad the code is. The blurb about Bugzilla talked about being able to maintain the codebase; completely different from everything else in the article and probably responsible for 90% of the comments here.

>I am by no means anti-Perl, but I've read and heard so many horror stories about Perl from developers that I trust and respect.

Well, to be fair, there are horror stories about *every* language. I can write bad code in C/Java/Lisp/Perl/Python/Ruby without it being any fault of the language itself.

There is much truth here. As you say, end users could careless what the underlying technology is or the programming language an application is in, they only care that it works.

However, are they only users of the application? What about the network admins who have to install updates and patches? What about the developers who have to implement updates and repair bugs? Are they not also "users" in a sense?

Over the years as a developer I've inherited many applications, written in a plethora of languages (Perl, PHP, VBScript, C#, VB.NET, VB6, etc). For the most part nearly all code I've inherited has been a nightmare to troubleshoot and maintain, even for applications that "worked" for end users. The handful of times it wasn't a nightmare, the code was well architected and well thought out (granted one case I can think of came from a highly experienced and well seasoned developer).

Yes, of course the end user takes priority, but don't make end user functionality the end all be all. Maintainability and elegance must enter into the equation.

I agree that a rewrite is rarely a good thing. But perhaps in this case where changing/updating the code is much more expensive than others. If it costs you 2-3x more development effort to add/fix something because of the language, then at some point you will have to bite the bullet and upgrade your language. The bigger question is when is the right time...

>I am by no means anti-Perl, but I've read and heard so many horror stories about Perl from developers that I trust and respect. Significantly more than any other (current) language I can think of. Max is yet another example. I do think there's a kernel of truth there.

I think you need to widen your circle of developer friends. The only kernel of truth is the current code base is crappy.

Jeff, the truth is that you need both. Code written as well as humanly possible, and user interfaces that are as good as you can make them.

As a follow up to my previous comments. I guess I (over)react to this given the current project I am working on. Many developers on the team for this project have the attitude "As long as the web page I have to program works, I don't care if my code is poorly written or illegibly written." Not only that but these team members are in the 80% class of developers, and clock out at 5:01 (some earlier!).

I am frequently combatting the "who cares, it works" attitude, and trying to get folks to write code that works for the end user and also is better prepared for future extension and functionality.

I do care what their code looks like. I will likely have to provide support for it when it breaks!

*Nobody* cares what your code looks like?

Let's enter the real world. Where code has to be maintained, upgraded, and possibly licensed or acquired by a new company.

As someone who has run several engineering operations and had to deal with having someone support someone else's code after they left - I can tell you we cared how your code looked. When we were acquired and the due diligence team came in to see if they wanted to buy our code base - they cared how the code looked. When an engineer went into someone else's code to add functionality - they cared how the code looked.

So, if you're writing a one-off program that you and your 2 friends are going to use, then nobody cares how the code looks. But if you are going to develop some real code that solves a real problem for a large customer base, you're going to need to care. Or get acquired real fast by some dumb company that doesn't look under the hood.

@Jeff Atwood:

"And yet, as Max points out in his original article, the adoption rate of Bugzilla is *growing*, and it's actively used today on many of the largest and most important open source projects in the world."

I don't understand what point you're trying to make here. Just because something is "selling" well (today) doesn't mean that trend will continue, especially not if development is becoming mired down. Would you propose they just ignore the state of the codebase until such time as people start uninstalling it and it has such a negative buzz that people are paying good money to non-free vendors just to avoid using it? At that point, add a few years to rewrite (pulled that LOE straight from my nether-regions), and the rewrite is likely to hit an established user base of approximately 0 customers.

Seems like a gross waste of product momentum.

This isn't a wholly novel situation. I'm sure you've seen rotting application infrastructure before. Think back: of the applications you've seen with the rotting infrastructure, did those who addressed the infrastructure proactively end up better or worse in the marketplace than those who waited until the rot was so thorough they were losing business? I've seen both, and I haven't *ever* see the latter turn out anything but disastrous.

The side question is: who really knows when the infrastructure is bad? A valid question, and engineers do tend to over-represent the cruftiness of the codebase they work on each day (just like most people tend to point out the failures of their work environment rather than point out the positive). So, the engineer's perspective will generally skew towards rewrites and refactorings more aggressive than makes sense. However, the art is that you need to start with that estimate - because there's not a single person in the entire world with a *better* view of the state of the code - and then tone it back one or two notches. If you're the engineer, realize that a certain percent of your "we need to rewrite this" missives will not get the "okay, do it" response, the larger the more often they are sent up the chain. If you're the manager, apply slight pressure back on the engineer to prove his case, and act on it early when he can.

It just seems the absolute *wrong* response here is "I don't care what the undercarriage looks like; I just drove this jalopy across town therefore it will do great in the cross-country race." If you don't care what your engineers are saying about the code they live in, why would you hire engineers in the first place? Seems like the logical end of your approach would be to stop all development on the first product sale (infinite growth! How could you top that?) and milk that product forever.

@Jeff (analyst):

"I worked on a project that I fully understood the business needs for and I communicated them clearly. Daily 2 coders pulled me into a room and said we can do it the right way or your way. Guess which way it was done."

(the wrong way?)

"As developers, programmers and coders you guys are geniuses about coding. Don't assume you know anything the business you're writing for listen to what they tell you and code it."

Wow, you must be an absolute dream to work for! If you want developers who take a set of requirements and code them precisely to spec and question nothing, you can get that in numerous third-world countries, and shouldn't have much trouble finding that wherever you live either. See a previous blog post or two about the 80% of programmers that just follow orders and take a paycheck home.

Where I work, requirements have bugs just like the software does. If the engineer is not questioning up the chain then crap gets pushed out the door, said crap gets blamed on the engineer (because we all know that engineers own the code) and the task of fixing said crap on the engineer's planned week off also falls to the engineer.

If you want a mindless drone taking imperfect specs (or, are you saying you are the one analyst in the world who makes perfect specs?) and translates them directly into crappy software, I hope you're not paying them any more than McDonalds wages. I also hope your job req doesn't list anything with the keywords "engineer" or "developer" in it, as both of those imply problem solving and creativity.

I guess a good analogy to use with the user community is that of a flight on the airlines. The passengers want their food, want to get to their destination, and do not want to consider the consequences of technical failure as they are very dire. Do they want to know what all the jargon with the air traffic controllers means - no. However, when the system falls apart, they will care.

The user base needs constant education concerning the economics behind what they are using. Yeah, screens are cool and that's all they consider, but it makes it no less a responsibility on our part to hit them over the head with the realities.

Hence these two phrases in client communication tool kit: "We have two goals - the application does what you want it to, and it is written so that I can make changes easily and not run up your bill while you wait for me to give life to your new ideas."; or, for the environments where you need to be harsh "You tell me the what and I'll tell you the how."

I have been passed over for the quick solutions because the client wants the screens that look cool and care about nothing, but in the end I tend to nor want those people as my clients.

If you have to maintain that code, you're going to care what it looks like.

You know what else no one but programmers care about? If your HTML code validates. No one cares about that pretty little box that says your page validates. Google and Yahoo don't even validate. MSN does though, go figure.

I'm not sure I'm getting the point Jeff is trying to make here. Of course the end users don't care about how nice or ugly your code looks. They do care however about your app working, just like you said. What Max was implying in the cited piece wasn't that bugzilla was bad because it is written in Perl, he was saying that with Perls inherent limitations in maintainability bugzilla would be hard to keep working well in the future.

In my current assignement part of the job is actually working with an archaic and very complex build system written in Perl back in -97 and kept alive ever since, the last years on life support. From this experience I know exactly where Max Kanat is coming from here: Perl makes it hard to keep large systems working well while at the same time adding new features required by the users, and those things the users, like you said, do care about.

Gee, I'm on Coding Horror! :-) I'm honored. :-)

I responded here:

http://avatraxiom.livejournal.com/70947.html

I'm sorry about not having my full name on any of the blog pages--it just hadn't occurred to me, since it's all over my other pages and the developer lists in general. The blog was originally a personal blog, and a lot of it still remains that way, so I guess I was assuming that most of the readers would be people who already knew me. :-)

I've fixed my profile, now, so it actually explains who I am. :-)

-Max

I'm sick of people bagging Perl. If you think Perl will get you into a mess because of no coding standards, it's *you're own* fucking fault! If a company adopted sane coding standards and stuck with it, language wouldn't matter.

At Apache, Bugzilla is being gradually replaced with JIRA, some projects already made the transition, others didn't, new ones are all set up with JIRA for issue track:
http://wiki.apache.org/general/ApacheBugzillaToJiraMigration

Oh and also:

@chromatic: Well-stated as usual. :-)

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.

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)

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.

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.

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.

Jeff, I can’t help but feel that you used the wrong example for your topic. The example seemed to question the choice of language, in hindsight, rather than the attractiveness of the underlying code base. I will grant that the end user may not care about either one, but the example and the topic are not synonymous.

This blog has already been pretty well flogged but I’ll add my 2¢.

Many of the respondents focused on pretty code which I also think is off the mark; yes pretty code is easier to maintain than not pretty code but the “prettiness” is not the real issue IMO. It is the underlying design. An app with pretty code and a poor design is still hard to maintain. A well designed app, even with not pretty code, is easier to maintain.

Some current IDEs, like VS2005 & 2008, take care of the prettiness of the code for us, almost more than I’d like; what they won’t do is address the design of the app. I started coding with db3 and FoxBase where you could make for some butt ugly code and designs; I found along the way that if I made it pretty I also started learning how to design it better. At this point I’ll write something, getting it working then refactor it, especially if I need the same chunk of code again and it get’s encapsulated. The use of meaningful names for objects and variables goes along way to easing on maintenance too, although this is not a prettiness item it is even more important, IMHO.

On a larger scale your topic “Nobody Cares What Your Code Looks Like” is also a comment about our society at large, and is true. If it weren’t you would not see all the crap from Wal-Mart/China. Things that look good in the shrink-wrap but after a few uses start falling apart; that’s the result of shopping for the lowest price and it affects all of us everyday at the cost of many quality oriented businesses that customers were not willing to support because they did not know/understand what went into producing a quality product so shop for price not quality.

Reminds me of the old saying:
Cheap
Fast
Good
Pick two – the one you don’t pick is the one you don’t get.

Keep up the good work.

Merry Christmas, Happy Hanukah, Merry Kwanza

Indirectly, I care greatly about the code in a piece of software: specifically I care about how fast and how secure it is. The majority of managers I have spoken to care greatly about productivity and security, both of which are affected by code design. Here I present my case. (I would be interested in hearing counter arguments :) )

I can personally describe ideas in English and Welsh (very inelegantly), but I have many colleagues who can describe the same ideas in English, Chinese, Japanese, French, German, Spanish, Dutch, Welsh (beautifully), Hindi, and I'm sure I've missed some.

Some of these languages have optimisations over others. For example:

os gwelwch yn dda (5 syllables)
means
please (1 syllable) ( more strictly, "if it's your good will")

thus leading to the proposition: English is more efficient than Welsh.

However:

Ga'i beint o ddwr? (4 syllables)
means
May I have a pint of Water? (8 syllables)

so we can now improve our previous proposition to: English is more efficient than Welsh in certain situations.

I am English, and don't remember learning to listen, speak, read or write. I can naturally hear grammatical errors, even less-than-optimum grammatical structures, and I'm sure that this is also true for you in your native language. I learnt to speak some Welsh at University, and do not consider myself fluent. I am incapable of hearing grammatical errors, let alone sub-optimal constructions, in Welsh - although I can make myself understood (at least some of the time).

Whilst recently I have specialised in Perl, I have been lucky enough to teach Perl, Python, PHP, Javascript, Java, C, C++, SQL, sed+awk+shell+commands and a couple of others in a UK University. OK, I'm being loose with my definition of language, but the point remains: I can write any of those of the top of my head, but I will be more "fluent" in one than an other.

It is important to strive to know the language as best as possible, and to use it's features in the most optimum fashion - which may not be the same across all languages.

Might I suggest that perhaps it's not the language directly that is the problem. Perl is a language designed to be exceptionally good with strings - mostly, a web server (even the new technologies supported by a web server) use text based strings. It is reasonable as a coder to expect fast and intuitive string manipulation techniques built into the language for free.
I'm sure no-one here is suggesting to me that there is stopping you using AJAX with Perl or mod_perl, it's all string manipulation in the end.
However, if most people are competent but not fluent in Perl, the project is going to run into problems.

Watching people learn to write algorithms in University, the observation I have made is that a problem with an algorithm is always going to be catastrophic compared missing a brand new feature that you have been given in a different language. Remember: on a small project one language will outstrip another, like Welsh will always outstrip English when politely ordering water in a bar. On a larger project, there will be bits that perform better, and others that will perform worse, when you compare to other languages.

One of the most important resources in any coding community is people. If you have many people willing to donate their time, and have a fluency in a particular language, do not ignore that. If you do, I think you'll find sub optimum grammatical structures, which will only serve to hurt you in the long run.

I am no zealot for GNU Linux, BSD, Sun, Apple, Microsoft products, Perl, C, C++, Ruby, etc. However I strongly advocate the correct tool for the job-in-hand.

Might I suggest that you take stock of your coders, and find the language that the majority of people are fluent in? If that's Perl, stick with it. If not, use the language which presents itself.

Bad code => (hard to fix bugs OR hard to implement new features)
=> unhappy customers.

Simple.

I'm just wondering if, in 20 years time, people will be describing Ruby, Python, etc. in the same way they describe Perl today. I think the signs of doing it with Java and C are already pretty evident.

"Bad code => (hard to fix bugs OR hard to implement new features)
=> unhappy customers.

Simple."

Code => hard to fix bugs OR hard to implement new features.
Seriously, name 5 mainstream products that've been constantly easy to fix/improve for more than 5 years. A definition of "easy" here may be a bit variable, but, for example, it does NOT mean, "I can do it, and everyone else is stupid."

I couldn't disagree more. The quality of the code directly affects the application performance, available features, the difficulty in addressing bugs and the ease and cost at which new features can be added. Users definitely care about those issues.

Further, bad code attracts bad programmers because the good programmers don't want to be wasting their time working on junk.

A badly written working product of today might be widely used, but a well written product will inevitably overhaul the market leader in a fair market.

@JW

"Might I suggest that you take stock of your coders, and find the language that the majority of people are fluent in? If that's PERL, stick with it. If not, use the language which presents itself."

Focusing on a skill set should be planned with the lifespan of the project. Take for example, COBOL.

COBOL was the business languages of the past decades. Lots of people programmed reasonably well in it. Times changed, and now, few people can program well in it.

Sticking to current skills without thinking of the future will lead to high costs in the future.

It is difficult to find COBOL programmers. They also get higher paychecks. Training one is expensive as well. Sooner or later, the client is going to notice the higher costs.

Is it really Perl that is at fault? I do Ruby on Rails work and I've seen (and produced from time to time) some really horrible bunches of code.

I think that I could go write a Perl application and do it well, I might balk and seeing any Perl now but that's because I haven't done any serious development in it, and I haven't written any for 4 years.

I think the quality of the code is important to a point, someone (maybe even you) will have to maintain it at some point. Some complete junk I wrote in PHP years ago is still being used to run a business. Begging for a rewrite with OO tech but... still.

The thing that makes me most sad is the monumental effort that went into libraries you can get on CPAN. And the advent of alternative languages we're leaving that all behind to re-implement.

I'm certain you could write good Perl.

It's sad to see that you think that writing good code is just geek masturbation that is somehow disconnected from the interests of the end user. We write "well factored" code because of the end user, not merely to satisfy our own egos, because the code ultimately translates into user experience.

Imagine where these projects could be if their code wasn't so bad.

Tell you what...

Starting immediately after you read this comment, please begin prefixing all your local variables with an underscore.

Do this for a year.

In fact, go one step further. Declare ALL local variables at the top of your method declaration.

At the next company holiday party, you will know exactly how many people care about how your code works. You will find it in the comments they put in as they try to track down bugs in a hellish sea of underscored local variables. No one will sit with you because they all are still sore from sifting through your code over long weekends trying to follow the logic. The underscores make it difficult to follow the code with the eye, and shifting between places in the code to find the variable types for all 25 variables defined at the top of the method is a royal pain.

This may seem strange, but do it and you'll understand exactly what type of hell you can create with bad coding. The customers won't care what your code looks like, but they also won't care that it takes your people twice as long as it should to fix a bug because the code is so damn confusing.

Hey, another defender of perl here.

If you've coded something up of substantial size with it's roots in perl version 5.005 or earlier, then it's going to be a bit evil, especially if coding standards were absent from the project. But with coding standards (Perl::Critic), tests (Test::More) and a general awareness of how to get the best bits off CPAN then perl is no less an "enterprise class" (whatever that means) language than anything else, and a damn sight less ugly and broken-by-design than say PHP (or VBscript maybe).

I spend a fair bit of time in a lisp-like statistics programming environment, and I can tell you before I understood the functional programming idiom, the code I wrote there was ugly, unmaintainable and pure evil. These days what used to be hundreds of lines of code usually boils down to 1-5 lines.

Users care if your software works, has more "features" and if it is the right colour.

When deadlines are involved, you can either have fewer features or lower quality code, and the users don't care about the code.

Commercial success depends on getting more of the customers. It costs the customers more to retrain and change to another system than to stay with an existing one.

Still, we are often left to wonder why organisations (particularly goverment organisations) made the decision to spend so much money on such awful software.

My issue with this stance is not that you are wrong (you are not, making the end-user happy is the main goal.) My issue is that it ignores a segment of the user-base of the application being developed.

The way I think about my code is that while 99.9% of the people using it will be using it through a front-end and never see one line of code, that other 0.1% using it are interfacing through the program via my classes, methods, etc... It doesn't matter how you are using my application, if it be the front-end, or developing for it, you are a user. If my code is crappy and unusable that breaks the "usability" of my application, even if that be the "usability" of the code in general and not the front-end of the application.

As the end-goal is to make money, you have to have the future in mind (an investment if you will.) A bad code-base can only be iterated on for so long before you end up grinding to a halt as Max had predicted for the Bugzilla code-base. Sure, they are having a nice high adoption rate now, but what about in 2-5 years when other products are developing circles around them? I doubt they will still be keeping that upward trend.

The longer they go without fixing the code usability the more the issue will perpetuate. If they step back and start to work on it now, they may develop things slower RIGHT NOW but I imagine overall development within that 2-5 year time-block will increase and keep them in the competitive market, more-so than if they just said: "Meh, screw it, customers don't care about bad code."

A product is all about features and how those features cure a pain of the end-user, if you can not keep up with the development of those pain-curing features/enhancements you are going to be left behind and no amount of scrambling will save you. Keeping the code maintained is an investment that needs to be balanced with delivering the product, not something that should be ignored entirely in favor of delivering more quickly right now.

You're right. Time to recode in a shiny new language.

Incidentally, Shiny New Perl 5.10 is just out :-)

I can't believe everybody missed one of the biggest problems that holds bugzilla back - it has a HUGE userbase that not only values, but demands backwards compatability, not just for their data, but for their customisations, and 3rd party plugins.

When you have a huge install base, with very large projects, dating back a decade or so, with widespread customisation - then that is a substantial burden on the project.

Jeff,

I can't belive I just read this post on your site.....

I know that "nobody but I" cares but that's what makes me great, (And nobody cares ;-)

/Jonas

Yes, end users do not care about your code as long as IT WORKS!! The moment it starts behaving weird; causing too much problems; showing too much bugs; then end users starts caring about the other stuff and can easily be bought for polished nice presentations having mentions of latest technology; latest language; UI etc. etc.

If the code is crappy and buggy, the user interface is usually more or less crappy too. Which is more important: Features, or developers who create the features?

If everything is not under control, pieces of code start to live their own life and maintainability dies. When you get bogged down with too much crap, you don't feel like doing as much progress as you could be doing. Less progress, less results, less revenue, less salary, maybe out o