In The Problems of Perl: The Future of Bugzilla, Max Kanat-Alexander* laments the state of the Bugzilla codebase:
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
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.
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
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.