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
contributors.
I know that a few years back when I got a small software house using Bugzilla, the fact that a few of us knew enough Perl to customise the code for our use was a significant bonus.
Another concrete example: I use the Unison file synchronizer, which is written in OCaml. The choice of language allowed the original developers to get their ideas implemented really quickly, and as a simple user of the program I’m happy with their decision. But if I want to contribute, to fix bugs or add features, my first obstacle is learning a new programming language which I have no other real interest in. I believe that the choice of programming language in this case has limited the number of people who can transition from being a user into being a contributor and then a developer.
Or you could just be like MySpace, and write code that is all at once terrible and ineffective, yet still be insanely popular.
what your code looks like will start to matter when a customer asks for a new feature, and you take way too damned long implementing it because your code base looks like Britney Spears’ career.
Users generally do care that the underlying code is pretty. Well, I should rather say they care that the application will be developing and improving. Which is in direct correlation with easily modifyable and sustainable code. Which is in direct correlation with pretty code.
A good analogy is a car engine. As a driver, you only care that the engine works so that you can drive to and from work. But when you need engine work, you do care if the engine is designed so that the corner mechanic can fix it, or if the shop has to special order parts from Eastern Slobovia.
Clean design matters. What language is lees of a concern, unless you are going beyond the constraints of the language (high-performance web servers in Visual Basic, or predicate login in C).
I like Simon’s comments.
“Those instincts die hard in a start-up.”
The reason so much code looks bad these days is that it is built upon a successful startup. These people are, by definition, concerned only with what is immediately valuable to the customers. If they aren’t they go out of business.
The big factor here is leverage. For a startup, the market saturation is small, the investment in development can only be leveraged a small amount. For established projects, however, the leverage is huge. Most companies spend something like 10% of their revenue on development. This means that the development work has a 10x leverage. Do you really think that companies care about developer productivity when they get that amount of bang for their buck?
I don’t care about the quality of a code base if:
a. I don’t have to work with it.
b. It is thoroughly documented and has a thorough accompanying set of tests.
Poor code is slower to change and you are more likely to introduce bugs through a change if it is not clear how it works.
That is why I think code quality is important.
(Bugzilla is my favorite tracker)
You missed the point of that message. Max said, Bugzilla cannot keep up development pace with other trackers because of the fact that it is written in Perl. This is why he was advocating switching to another language. If you had been following the bugzilla mailing list, you would have recognized that this discussion has largely fallen wayside as of late. Max was wrong about the Bugzilla codebase; there are several reasons it hasn’t advanced in recent years nearly as much as any competitors:
- The old codebase was horrid and extremely difficult to advance
- 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)
- Most mainstream software engineers (the ones used to maintaining programs the size of Bugzilla) don’t know Perl and hence are very unlikely to enhance it (though this is arguably not a correct statement)
Around version 2.16 of Bugzilla (2003), enhancements had become so difficult to add that it almost wasn’t worth it. 2.18 and 2.20 were both welcomed versions that fixed a tone of things that should have been fixed, but still they were built atop a codebase that was effectively unmaintainable. Max and fellow devs have done an enormous amount of refactoring work to get the codebase in a much better place today (this is one of the biggest reasons the last release was 3.0 instead of 2.x). The codebase is still getting architecturally better and as it does, enhancements will continue to become easier to do.
yes, yes, Jeff… yes… but then again NO, sorry.
End-users don’t care about the look of our code base.
Customers don’t care about the looks of our code base.
Both end-users and customers, though, care about the cost of fixing a bug or introducing a new feature. And that, I fear, is directly related to the state of our code base, which includes its ‘look’.
F.O.R.
As a consultant, making code well organized and “pretty” can be very important. My customers often take over maintenance of my code as soon as I’m done with the contract, and they often have very stringent requirements on coding conventions. It’s amazing how important they can make it. Still, I’d agree that the first and most important thing is to have code that just works. In the open source world, even though the projects you work on are often a labor of love, you are still working in limited time in the wee hours of the morning, and often don’t have time to comment and beautify your code. From the end-users point of view at least, all that matters is that the code works, but my customers really do care about how the code looks. My coding philosophy has always been, code until it works, and then clean refactor until the time runs out. If there is limited time, they will just have to deal with sloppy but working code.
I totally disagree with this one, Jeff.
You first explain in detail why customers don’t care what your code looks like. Fine, I agree, customers don’t care what your code looks like or even in which programming language it’s written.
But then you silently change “customers” to “nobody” and conclude that nobody cares what your code looks like.
The article totally lacks any argument why nobody (instead of just customers) cares what your code looks like.
And ofcourse I don’t have to explain how important it is to make code maintainable. Code is written once, but read many times - good code is readable code.
Ok, sure, the bottom line is you have to make a product that works, ugly code or not. But I would say that generating ugly code is a bad practice. A good developer who takes pride in his work will always attempt to write elegantly structured code. I say if you’re going to do a job, do it right. You can clean a room by shoving everything into the closet or you can put things where they belong. Which way is better in the long run? Hey, we all have written code we’re not proud of, but whenever possible, strive to beautify your code.
My experience after 16 years in the biz is that:
Customers care about features, cost, support, does it work and how soon can I get it.
Customers don’t care about programming languages, how hard it is for you to maintain or even what technology is used - that’s your problem.
And – the only interface customers care about is the user interface:
http://softwareindustrialization.com/WhatsNewInSoftwareDevelopmentFor2006Part3.aspx
andemann is absolutely right. The problem with Bugzilla that they are pointing out is that it is too hard to maintain the code because it is too difficult to enforce any kind of standard.
On the surface, no the users could care less. I have tried to explain code to people before and it makes no sense to them that words on a screen can end up as their favorite video game. What they do care about is when it takes 3 months to patch a bug because one developer spends 2 months and 29 days figuring out what another guy wrote. THAT is where the value in well structured, well written code is and I could make a case that the customer ABSOLUTELY cares about that.
@Eric Wise - They didn’t teach you cobol and rpg in college because they are not good languages for teaching the concepts of programming. If you think you’re going to learn a language in college to prepare you for work, then they should also teach you how to prepare for a short career. Classes in college should teach you concepts, not languages.
You need more than comments and well written code for open source projects. I think you need a SDK, a data dictionary, and clear instructions on how to implement typical customizations. For example, I customize a shopping cart where a typical change would be to add a new field to the customer address. All of the steps to modify the code to accomodate a new field should be documented. You should also document solutions for frequent problems and difficulties reported by developers.
Disagree strongly, Jeff.
The user interface is not the application; the user experience is. It’s a subtle distinction, but very important. Things like crashes, arcane error messages, spinning pizzas of death, and slow window updates disrupt user workflow and provide a bad experience. In HCI terms, the application moves from ready-to-hand to present-at-hand: the user is no longer focused on the task but on the application itself. A bad code base is a chore to trace, difficult to debug, and impossible to tune. Bad code oozes forward to the user experience. Bad code reflects sloppy thinking.
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.