programming and human factors
by Jeff Atwood
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).
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.
kd on December 19, 2007 9:41 AM"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.
Robert on December 19, 2007 9:54 AM"As long as the customers are happy with the delivered application"
Many developers are simply wrong about the definition of clean code.
They think Clean code is an ideal where developer's can walk up to a code base and get new features out of it without having to solve hard problems. That is called fantasy land, and there is a good reason that most successful code bases don't live there.
I'm not saying the idea of 'techinical debt' is wrong, or that you should celibrate the chores of dealing with a 10 year old Perl code base. I am saying that many developer's idea of Clean code has less to do with Technical debt and more to do with living in fantasy land.
Actually, it's probably no perl, it probably the age of the code base. I have been involved in software programs of a wide variety of size, and while the maintenance/upgrade costs are a function of program language and quality of the coding, it is often very much of function of the age of the code.
It's not that code rusts. If you don't touch it, it doesn't get older. However, continued tinkering, upgrades, fixes, new releases, etc -- each one of the changes not envisioned in the original architecture makes the code base more difficult to touch for the next time. There are two reasons for this
1) Adding capabilities and fixes is never as architecturally integrated as the original
2) The current user base must be kept happy -- requiring keeping compatible capabilities and feel.
I'm sure if you rewrote your system in perl today, you'd find that the new code base was easy to maintain. But you'd get even more advantage from rewriting from scratch in any language (including perl), as this would eliminate the need to stay compatible with the past.
It's the legacy costs that are eating you up. This can be see in industry also. New comers are more flexible -- they don't have the legacy customers to satisfy and they can start with a completely clean architecture.
Michael Chonoles on December 19, 2007 10:18 AMCustomers 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.
Nick Brown on December 19, 2007 10:22 AMIt'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"?
alan on December 19, 2007 11:07 AMIt'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/
ActiveEngine Sensei on December 19, 2007 11:10 AMI'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. :)
Steve on December 19, 2007 11:12 AMUgh. 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.
David Dormer on December 19, 2007 11:33 AMUsers 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.
Andrew on December 19, 2007 11:35 AMJust 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.
Jeff Atwood on December 19, 2007 11:39 AMMy 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.
John Postlethwait on December 19, 2007 11:39 AMEver 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.
chromatic on December 19, 2007 11:45 AMMax 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 Atwood on December 19, 2007 11:49 AM@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.
Buck on December 19, 2007 11:50 AMI 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.
David Dormer on December 19, 2007 11:55 AMI 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...
Stephane Grenier on December 19, 2007 12:27 PMI am by no means anti-Perl, but I've read and heard so many horror stories about Perl from developers that I trust and respect. Significantly more than any other (current) language I can think of. Max is yet another example. I do think there's a kernel of truth there.
I think you need to widen your circle of developer friends. The only kernel of truth is the current code base is crappy.
derby on December 19, 2007 12:36 PMJeff, the truth is that you need both. Code written as well as humanly possible, and user interfaces that are as good as you can make them.
CodeWarrior on December 19, 2007 12:45 PMPerl has actually aged extraordinarily well. Perl has been at the forefront of pushing automated testing for the past several years. Other languages are still playing catch-up. The Perl community has a much higher standard for testing and documentation than most, as you can see in the popular modules on CPAN. Perl has also evolved mature tools for managing code style (Perl::Critic, perltidy) and has top-notch object-relational mappers and templating tools, i.e. the things you need every day in web development.
Perrin Harkins on December 20, 2007 1:07 AMYou're right. Time to recode in a shiny new language.
Incidentally, Shiny New Perl 5.10 is just out :-)
kaare on December 20, 2007 1:38 AMI have to state here that perl is not so bad. Some people can write things that look unintelligable in perl quite easily, but many people stick to KR style that they have grown familiar with from C. Much of the style of perl programming fits with C nicely also, but this goes for much of ruby too.
The thing about perl though is that it's quick to do something that most other languages take a lot of lines to complete. Such as IO::Socket::INET, which lets you do what you want over the wire so easily. LWP::UserAgent and WWW::Mechanize also are great favorites for doing stuff with HTTP sites.
I think people should really not complain about perl being messy, we see this a lot all over the internet that perl is ghastly, but this really isn't the case. The only complaint that I have is that many variables start with $ - simply because it's sometimes hard to find on the keyboard.
ed on December 20, 2007 1:49 AMBugzilla is an opensource project, so if your code looks like crap it will be hard to find developers to maintain it.
Mark Brown on December 20, 2007 2:04 AMOuch, I injured my finger having to use that scroll-wheel to get all of the way down to the bottom. Seems to be quite an issue. So, even through I'll get lost in this mass of comments, I'll still ump in:
Pretty much, Perl, PHP, C, C++, Java, Ruby, etc. are all fundamentally the same. OO or not, there are a few slice and dice differences, but not enough to make any real difference to any implementation. Contrast these languages with APL, Lisp or Prolog and you'll see what I mean. Given that, I don't buy the argument that writing in Perl makes Bugzilla outdated. When used with restraint, Perl is close enough to any of the other languages that it would be hard to tell the difference. "Used with restraint" is key.
So, to me at least, what this is really about is a hugely messy codebase that has not been cleaned up. That 'problem' is independent of language or technology. You can make a brute force mess in any of the above languages just as easily as any other; although some features in Perl and things like macros in CPP make it a bit easier to accomplish.
Our problems lie with the way we are designing and building our code. It comes up again and again: flailing at the keyboard for all hours of the night eventually produces something unmanageable. The problem isn't any specific language or technology, it is the way we creating things. You can't coalesce thousands of rickety sheds into an apartment building, it just ain't going to work.
Paul W. Homer on December 20, 2007 2:43 AMJeff,
I can't belive I just read this post on your site.....
I know that "nobody but I" cares but that's what makes me great, (And nobody cares ;-)
/Jonas
Jonas on December 20, 2007 3:59 AMYes, end users do not care about your code as long as IT WORKS!! The moment it starts behaving weird; causing too much problems; showing too much bugs; then end users starts caring about the other stuff and can easily be bought for polished nice presentations having mentions of latest technology; latest language; UI etc. etc.
Writing on December 20, 2007 7:51 AMJeff,
I agree that usability and the user experience is the utmost. At the same time what about continued maintenance (and future development) of the product. This is when coding conventions and choice of programming language becomes especially important. There is always the possibility of the product outliving the programmer.
Raghav.
Raghavendra on December 20, 2007 8:13 AMJeff, I think you missed the point entirely:
"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."
The guy who wrote the yahoo stores said something similar--he had a competitive advantage because he was using a powerful language, LISP.
No the users don't care what something is written. Yes the user interface is important. Yes programmers need to pay more attention to what the users sees and needs rather than just architecture or plumbing. But in order to keep cranking those features out, a good language and good code is essential. We've ALL been the situation where we can't bring business value to our customers (features) because we're too busy wrangling with code (or languages) that suck. There comes a point where bad code DOES affect the customer, even though they don't know it.
I'm a big fan Jeff, but I think your post is irresponsible and i think you missed the point.
craig on December 21, 2007 1:56 AMUsers SHOULD care what the code looks like, unfortunately they have their own short sighted pressures on them as well.
If I bought a house and didn't go down the basement to see if the pipes leaked, how the wires looked, or what the HVAC looked like ... I'd be a very sad homeowner in a short time.
If you don't address the code to the two target audiences that it will have: the machine it runs on, and the humans needing to maintain it (programmer or analyst) - you are just not writing good code (imho).
david rawheiser on December 21, 2007 7:42 AM
"people only care if it works and how it works e.g. user experience"
I'm sorry, to argue that you can slap some shit together and put the crap out there and it won't matter as long as the UI is pretty is wrong. At best it's far from being 100% right. It's like some contractor arguing that the faster they slap some new house together, the better because people just want it to look pretty. Never mind the mistreated wood trusses for the roof or the overloaded electrical box or the shingles that weren't put on quite right or the landscaping that doesn't quite slope away from the house so that there's a good chance the basement's going to end up damp after a hard rain. Sure, they won't cause issues right away. But they're going to be a huge pain in the ass when they do costly to fix.
Well written code is easier to maintain, always for more time to create new features, leads to better avoiding releasing bugs in software and, when they do happen, being able to fix them more quickly. And the productivity of all these activities affects the cost of building and maintaining that code.
These things are ALL part of the user experience. It's not limited to the UI. It hits their pocket book. How long a bug may exist affects them. So does having a bug in the first place. HAVING GOOD CODE MATTERS.
Allen on December 21, 2007 11:23 AMWell, there's some truth here if you're delivering compiled closed-source code. Your article reminds me of companies who advertise their code as "developed using object-oriented techniques", or, more recently, "developed using agile technologies". As if anyone cared!
But if (as, for example, in the case of Bugzilla) you're delivering something open source and not-compiled, I care deeply about what the code looks like (to me, that includes things like the installation instructions, the license, the documentation). I might need to patch this code, I might want to adapt it; I might even want to join the development team! Code quality is certainly a factor in choosing this kind of tool.
Do you think Bugzila at this point can be rewritten in another language? Say PHP/.net/Java/Ruby? What kind of risks one would accout here? Would that be a sound business call? 10 years development would have historical domain skills accounted in every small function. Will this not be a big risk for migration? What in that case should be the strategy?
Vipul on December 25, 2007 11:44 AMThey refactored Bugzilla to work on mod_perl to speed up it. Maybe it is time to refactor it in modern Perl. And use Perl::Critic.
Sasha on December 29, 2007 9:37 AMWhen I rent an apartment I tend to look at the layout and not the underlying architecture and raw material used to build it. But going ahead, if I do decide to dig a hole in the wall, I would not expect the building to come crashing down! I TRUST the builder. Geez…
It is YOUR responsibility as a vendor to provide solid code that can accommodate changes quickly and continue to maintain the stability of the application. It is NOT the responsibility of the USER. WHY SHOULD HE CARE ? What is he paying YOU for?
Preeti Edul on December 31, 2007 7:06 AMSure,most users don't care about the your code ,if you satisfy their question "does the programme work ?" with a "yes ,it does" then you'll not have any problem with them .But your employers do care about your code so you should as well if you want to stay employed.
gogole on January 2, 2008 7:13 AMFirstly, they guy you were quoting never (in the quote at least) said that their code is ugly. He said that developing big software systems (such as Bugzilla) in Perl is slower than in other major languages. And that is not a surprise because Perl is not suited (and was not designed) for that. From that quote we can't really conclude how ugly or beautiful the Bugzilla's codebase is, so it wouldn't be correct to cite Bugzilla as an example of a popular application with happy users despite it's ugly code base.
And what about Spolsky and Wasabi? Would you label their code ugly just because it's written in Wasabi and not in Ruby? I'm sure their code is very beautiful judged by the Wasabi's beauty standards. Why? Because I assume they have good programmers, and good programmers don't write ugly code.
Good programmers write good-looking code automatically and naturally. Simply because they are good at writing code, and they don't like producing crap. So, ugly code is a sure sign of a bad programmer. Obviously, if you have too many bad programmers on your project, then your project is in trouble. Which brings us to a conclusion: the uglier your codebase is, the more trouble awaits your project.
Yes, it's totally correct that users don't give a damn about how your code looks like (why should they?). So what? Is there really anybody who believes (or have seen) that it's possible to successfully (i.e. well beyond the version 1.0) develop complex applications on a predominantly ugly code base?
EasyBlogger on January 3, 2008 12:58 PMDoes it matters that the house you buy is well conceived?
Does it matters that the foundation of a building are sound?
Does it matters that your diet is correct?
Does it matters that your country/city is well run?
Does it matter that your car is well designed?
Of course it matters! but when you buy a house, construct a building, eat, vote or buy a car; we ask some questions but certainly we miss some very important questions.
I believe that a reasonable level of quality of code is important. Like for the foundation of a house. It doesn't necessary important that they are very beautiful and that they can handle an earthquake of force 10 but its better that they are done correctly and could handle a force 6 earthquake.
The problem is to find a way to define and after that control the quality of code. After that the user, theoretically, the user could ask some level of quality. We have already some methodology that enforce some quality checks. We have also some metrics. But how many time did you find very ugly architecture or code?
DomreiRoam on January 18, 2008 2:03 AMI don't think that a customer cares about your code. Usability and functionality - here is the key. Anyway I had to rewrite code of my software Sitemap Writer when I changed it into Pro http://www.sitemapwriter.com/ After this, anytime I start a new project pay attention on my code. It shouldn't be ugly and easy to be transformed.
cross on March 19, 2008 5:57 AMyeah.... thats a lot of comments.
i think that the whole point of writing good code is that it works better than bad code. if you write bad code and it works then you have gotten lucky and this luck will not last for long, or else your program is really really tiny.
nachtkriecher on September 15, 2008 3:45 AMOho! Nice post. It gets the point across, but there are some vague concepts.
I care what my code looks like. I work hard making sure my code is easy to read, easy to understand, in addition to doing what is expected of it.
Normally, the end user won't care.
They will start caring though, when an error is discovered. Programs written poorly take lots of time and money to fix. Programs that are written well take less time and money to fix.
Beautiful code is code that is easy to maintain, unless there is such a thing as a zero-maintenance system.
I generally have a rule. If I want clean, highly maintainable, nice code - I do it on my own time.
The primary goal of any software company is to make money. That's it, first and foremost.
Code is simply the vehicle to get you there. Now, clearly there's a difference between taking a rusty passion waggon and a Porche to get to your destination.
That said, there is often a point of diminishing return with how clean your code needs to be. As long as the code isn't "stupid" that's probably good enough for most businesses.
It's hard because as a developer I'm naturally a purist. Those instincts die hard in a start-up. If it's a choice between a hack that does it in a day and a more structured approach that takes seven then I'll take the hack.
Sure, the hack might cost more in the long run, but if I continually do the structured approach it may cost so much money up front that I go out of business. In short, I only have to worry about the bad code when I finally get some customers who are paying every month.
Learning that was a tough, harsh lesson of living in a real world small development team.
Simon.
Simon Johnson on February 6, 2010 10:20 PMI admire Joel and Fog Creek immensely for developing their own language, that is the stuff of geekery and hope they are smart enough to get it done.
I'm sure today's post will appear in the perlmonks meditations section, but it reminds me of another meditation one of the monks had. He was thinking about learning other languages to implement things and heard some advice from someone who told him to become a better Perl programmer rather than be a jack of all trades. I think that applies in most cases no matter what language you use. I'd love to translate loads of stuff I maintain from Delphi to C#, but when there's a whole framework that just works, few new features will be needed and I don't know C# well enough, it's better keeping it in Delphi and refactoring it to be a bit more sane.
The language comparison on the bugzilla wiki was interesting and from that it's not clear that Perl is substantially worse than its competitors. I think the issue is probably more design related. I love Perl, which is why I agree with most of the cons, but I'd say some of them are DWIM (Do What I Mean) features, like an array in scalar context is actually its length (although sometimes I have had to use $#array for the length rather than @array).
I wanted to extend Bugzilla for my own company's use (probably site specific, so wouldn't be distributed), but I took one look at the source (we're using 2.20) and developed a parallel system. Which is a bit annoying because it doesn't automatically link together, but hopefully it will do the job.
John Ferguson on February 6, 2010 10:20 PMThere is much truth here. As you say, end users could careless what the underlying technology is or the programming language an application is in, they only care that it works.
However, are they only users of the application? What about the network admins who have to install updates and patches? What about the developers who have to implement updates and repair bugs? Are they not also "users" in a sense?
Over the years as a developer I've inherited many applications, written in a plethora of languages (Perl, PHP, VBScript, C#, VB.NET, VB6, etc). For the most part nearly all code I've inherited has been a nightmare to troubleshoot and maintain, even for applications that "worked" for end users. The handful of times it wasn't a nightmare, the code was well architected and well thought out (granted one case I can think of came from a highly experienced and well seasoned developer).
Yes, of course the end user takes priority, but don't make end user functionality the end all be all. Maintainability and elegance must enter into the equation.
Jon on February 6, 2010 10:20 PMAs a follow up to my previous comments. I guess I (over)react to this given the current project I am working on. Many developers on the team for this project have the attitude "As long as the web page I have to program works, I don't care if my code is poorly written or illegibly written." Not only that but these team members are in the 80% class of developers, and clock out at 5:01 (some earlier!).
I am frequently combatting the "who cares, it works" attitude, and trying to get folks to write code that works for the end user and also is better prepared for future extension and functionality.
I do care what their code looks like. I will likely have to provide support for it when it breaks!
Jon on February 6, 2010 10:20 PM@JW
"Might I suggest that you take stock of your coders, and find the language that the majority of people are fluent in? If that's PERL, stick with it. If not, use the language which presents itself."
Focusing on a skill set should be planned with the lifespan of the project. Take for example, COBOL.
COBOL was the business languages of the past decades. Lots of people programmed reasonably well in it. Times changed, and now, few people can program well in it.
Sticking to current skills without thinking of the future will lead to high costs in the future.
It is difficult to find COBOL programmers. They also get higher paychecks. Training one is expensive as well. Sooner or later, the client is going to notice the higher costs.
Jon Abaca on February 6, 2010 10:20 PMI can't believe everybody missed one of the biggest problems that holds bugzilla back - it has a HUGE userbase that not only values, but demands backwards compatability, not just for their data, but for their customisations, and 3rd party plugins.
When you have a huge install base, with very large projects, dating back a decade or so, with widespread customisation - then that is a substantial burden on the project.
Aaron Trevena on February 6, 2010 10:20 PMIf the code is crappy and buggy, the user interface is usually more or less crappy too. Which is more important: Features, or developers who create the features?
If everything is not under control, pieces of code start to live their own life and maintainability dies. When you get bogged down with too much crap, you don't feel like doing as much progress as you could be doing. Less progress, less results, less revenue, less salary, maybe out of job, unless you change the ways of working.
Of course its the same what components you use if they all work. But before you can use them, you need a standard. Components are not interchangable without a standard.
Programmers make sure that the code is fine. Designers make sure that the design is fine. If you let the programmers design, they have too much to think about. The programmers tend to create such designs, that will make their life easier. But what is easier is not always the right thing to do. The right thing to do is to design the software so that its easy to use, regardless of is it easy to implement or not.
Actually the one who creates the specifications of the software decides what the software will be like. Then the designer creates such designs, that it is as easy as possible for the programmer to implement the specifications.
Even more actually the designer designs only the details of the software so that the software is easy to be implemented. The architect is the one, who creates overall frames for supporting easy designability of features for the programmers to implement.
Don on February 6, 2010 10:20 PMThe comments to this entry are closed.
Subscribe in a reader
Subscribe via email
|
|
Traffic Stats |