Here is the latest news on Bugzilla
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.
“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
- Adding capabilities and fixes is never as architecturally integrated as the original
- 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.
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.
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.
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.
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.
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…