December 18, 2007
In The Problems of Perl: The Future of Bugzilla, Max Kanat-Alexander* laments the state of the Bugzilla codebase:
Once upon a time, Bugzilla was an internal application at Netscape, written in TCL. When it was open-sourced in 1998, Terry (the original programmer), decided to re-write Bugzilla in Perl. 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.
In 1998, there were few advanced, object-oriented web scripting languages. In fact, Perl was pretty much it. PHP was at version 3.0, python was at version 1.5, Java was just starting to become well-known, ruby was almost unheard of, and some people were still writing their CGI scripts in C or C++.
Perl has many great features, most of all the number of libraries available and the extreme flexibility of the language. However, Perl would not be my first choice for writing or maintaining a large project such as Bugzilla. The same flexibility that makes Perl so powerful makes it very difficult to enforce code quality standards or to implement modern object-oriented designs.
Since 1998 there have been many advances in programming languages. PHP has decent object-oriented features, python has many libraries and excellent syntax, Java has matured a lot, and Ruby is coming up in the world quickly. Nowadays, almost all of our competitors have one advantage: they are not written in Perl. They can actually develop features more quickly than we can, not because of the number of contributors they have, but because the language they're using allows it. There are at least two bug-trackers that I can think of off the top of my head that didn't even exist in 1998 and were developed rapidly up to a point where they could compete with Bugzilla.
In 1998, Perl was the right choice for a language to re-write Bugzilla in. In 2007, though, having worked with Perl extensively for years on the Bugzilla project, I'd say the language itself is our greatest hindrance. Without taking some action, I'm not sure how many more years Bugzilla can stay alive as a product. Currently, our popularity is actually increasing, as far as I can see. So we shouldn't abandon what we're doing now. But I'm seeing more and more products come into the bug-tracking arena, and I'm not sure that we can stay competitive for more than a few more years if we stick with Perl.
It's a credit to Max that he cares enough about the future of his work to surface these important issues. Perhaps it would make sense to rewrite Bugzilla in a friendlier, more modern language.
Neither Perl nor the circa-1998 Bugzilla codebase have aged particularly well over the last 10 years. I don't think Bugzilla is anyone's favorite bug tracking product. It is utilitarian bordering on downright ugly. But-- and here's the important part-- Bugzilla works. It's actively used today by some of the largest and most famous open source projects on the planet, including the Linux Kernel, Mozilla, Apache, and many others.
I have a friend who works for an extremely popular open source database company, and he says their code is some of the absolute worst he's ever seen. This particular friend of mine is no stranger to bad code-- he's been in a position to see some horrifically bad codebases. Adoption of this open source database isn't slowing in the least because their codebase happens to be poorly written and difficult to troubleshoot and maintain. Users couldn't care less whether the underlying code is pretty. All they care about is whether or not it works. And it must work-- otherwise, why would all these people all over the world be running their businesses on it?
I gave Joel Spolsky a hard time for his Wasabi language boondoggle, but I'm now reconsidering that stance. Fog Creek Software isn't funded by the admiration of other programmers. It's funded by selling their software to customers. And to the customer, the user interface is the application. I might point and laugh at an application written in some crazy hand rolled in-house language. But language choice is completely invisible to potential customers. As long as the customers are happy with the delivered application and sales are solid, who gives a damn what I-- or any other programmers, for that matter-- think?
Sure, we programmers are paid to care what the code looks like. We worry about the guts of our applications. It's our job. We want to write code in friendly, modern languages that make our work easier and less error-prone. We'd love any opportunity to geek out and rewrite everything in the newest, sexiest possible language. It's all perfectly natural.
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.
* I desperately want to provide full name attribution here, but I was unable to find Max's last name on any of his pages-- which drives me absolutely bonkers (see # 3).
Posted by Jeff Atwood
*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.
"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.
"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:
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. :-)
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.
Oh and also:
@chromatic: Well-stated as usual. :-)
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.
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.
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.
How much of the project life cycle is consumed by maintance ?
How can coding standards and choice of language influence this ?
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:
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)
"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!
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 :-)
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.
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:
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
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.
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.
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:
Welsh os gwelwch yn dda / Welsh (5 syllables)
English please / English (1 syllable) ( more strictly, "if it's your good will")
thus leading to the proposition: English is more efficient than Welsh.
Welsh Ga'i beint o ddwr?/ Welsh (4 syllables)
English May I have a pint of Water?/ English (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).
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.
"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.
Bad code = (hard to fix bugs OR hard to implement new features)
= unhappy customers.
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.
""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.
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.
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 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 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.
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.
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...
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 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
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'.
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:
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.
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 istill/i 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.
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.
As developers, we often need to re-focus on WHY we're actually writing this software.
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.
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.
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.
"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.
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.
I'm amused that this appears around the same time as a href="http://steve-yegge.blogspot.com/2007/12/codes-worst-enemy.html"Steve Yegge's latest missive/a. "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.)
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."
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.
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? :)
We want to write code in friendly, modern languages that make our work easier and less error-prone.
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.
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.