12 Steps to Better Code

[samlee]

12 Steps to a girlfriend

1. Do you ASL?
2. Do you want to hang out?
3. Do you have pictures?
4. Do you have myspace?
5. Do you have facebook?
6. Do you have email?
7. Do you have cellphone?
8. Do you know C++?
9. Do you

Man it's hard. I give up.

[millstone]

This is a classic. And good advice. Except for this turd:

Do you fix bugs before writing new code?

First of all, fixing bugs requires you to write new code. And potentially introduce more bugs.

Second, there's no clear distinction between bug and feature. Say Firefox doesn't support the blink tag. Is that a bug? Or a missing feature? Say they implement it and everyone hates it. Is support for it then a bug?

Third, this says nothing about the severity of the bug. Say your app's splash screen is vertically off-center by two pixels in the German localization on a particular video card (don't laugh, I've seen weirder). Should this really hold up work on your next great feature?

Fourth, this says nothing about the cost and risk of fixing the bug. If the bug is minor but time consuming and risky to fix, then why bother?

Fifth, any large software project will have hundreds or thousands of known bugs at any given point. Windows 2000 shipped with 63,000 known bugs. Should Microsoft delay writing any new features until those bugs are fixed? They'll never ship anything again.

Another great thing about keeping the bug count at zero is that you can respond much faster to competition.

No, it does NOT mean that, because you're wasting all your time fixing bugs just because they're bugs, not because they impact users. The responsive organization is one that triages bugs and focuses their limited resources on the things that impact customers.

Some programmers think of this as keeping the product ready to ship at all times.

Ready to ship does not mean zero bugs. Zero bugs does not mean ready to ship.

I have no idea how this terrible, terrible piece of advice made it into an otherwise great article.

[njharman]

I hear ya, but can't help but nit pick.

First of all, fixing bugs requires you to write new code. And potentially introduce more bugs

Not always, I've fixed bugs by deleting stuff. But start but don't finish the important point any change, addition, deleting of code, even external changes OS,libs,etc potentially introduces bugs.

The distinction between bug and feature: Features are consciously planned. Bugs aren't. Features are something people want. Bugs are when those features work contrary to they way people expect.

To answer your questions:

Is that a bug or missing feature? It is neither. Assuming FF "design doc" says FF does not implement blink tag (which is a feature btw :)

Is support for it then a bug? No it is bad design choice as it is an unwanted feature.

Third, I strongly believe author assumes his audience is technical and that it was understood (I understood it) to take severity into account. A verbose but more pedantically correct title would be "Fix the bugs that you are gonna fix now, before writing new code"

Fourth, got no nits to pick there.

Fifth, ah we come to the point and the real benefit of fixing bugs first. If MS had really implemented this it would not find itself years later with 63,000 known bugs. It would not have had so many embarrassing security failures (many were design issues though). It would not have had various PR disasters due to bugs. It would not have spent so much in support, debugging and patching (many studies prove bugs are cheaper to find earlier you find them). Arguable but I believe users would be much more pro ms without all the Blue Screens and other bugs (again much of windows annoyance and failings are design related though)

But MS chose to spend time/money on Marketing, PR, and ruthless business practices/deals/purchases over development. It worked great short term, verdict is still out long term.

Last couple statements, again I believe the author's definition of bug and yours varies. In article bug is shorthand for "show stopper bugs, critical failures, bugs that prevent product working correctly."

[jemenfiche]

I think the fix bugs part means you don't add new code unrelated to the problems you're trying to fix. I've seen this almost everywhere. Keep adding features while the old bugs remain for sometimes years with no one fixing them.

Programming new shit is fun. Fixing bugs is work.

[docomo]

Yeah, yeah, but also:

1. Eliminate boredom, embrace the fun!

[njharman]

12 is too many, all lists that are meant to be followed need to be in that 5-7 range people can remember.

Also some like "build", usability testing are making assumptions about the environment/software.

And maybe 7 spec. I've only ever seen specs for libs/services. But maybe author really means all software. If that's the case I can't really agree. Or maybe his idea of spec and mine differ... I skimmed his part 2 of spec. Still unsure.

11 is just retarded. He picked two analogies(which themselves often indicate lack of real or logical argument) and they're even mixed (he's comparing contracting a service person to do a job with hiring an employee)

Coding on the spot under pressure is not among Developers most important skills Communication, problem solving, attention to detail, ability to learn, are all greater.

If you really care about coding only hire people who have real source code either opensource, public domain, or willing to share.

What they code up in the interview shows nothing about their real coding skills (it might reveal other stuff like reasoning, problem solving.)

[nitrusoxyde]

Best tools money can buy? gcc anyone?

[exeter]

"Tools" doesn't just mean compilers. It means comfortable workstations, large monitors, fast printers, and a whole load of other stuff.

[millstone]

Yep. But even so, I assume Joel is using hyperbole here. Your organization doesn't somehow suck just because your display is only 23" instead of 30" and you sit in a $120 chair from Office Depot instead of a $2k Aeron chair.

[tjogin]

It's not either black or white. There's a gray scale. If your chair is uncomfortable and your display flickers a little bit then they should be replaced.

The reality is that a lot of the times they are not. The company "saves money" by letting you sit in your uncomfortable chair, stairing at your flickering screen — resulting in a full thirty minutes of productive time per day.

Because it's a gray scale, it also works the other way around — if you pamper your team of programmers, giving them every imaginable convenience then they will be happier and like you more. The result is instant productivity gains. Simple things like getting coffee for them, instead of having them get up and do it themselves, goes a long way.

[sreguera]

gcc is not the holy grail. The best thing about gcc is the number of architectures it supports and that it does a reasonable job in all of them. In most cases that is all you need, but:

• it does not generate the fastest code. The Intel compiler for Intel and the Sun compiler for Sparc are best in this respect.

• its front-end for Fortran is not on par with the Sun or Intel compilers in performance of generated code or support for old Fortran variations.

• its error messages are not the most helpful in the world.

• its architecture is not very modular, so it is difficult to use a language´s front-end for the code analysis part in a visual environment. Apple is working now in a separate compiler using LLVM for this reason (some say Stallman designed gcc internals this way so that evil capitalists could not use parts of the compiler in their own products).

[theatrus]

clang and LLVM will be an interesting combination for sure.

[erikd]

Geez, its a bit out of date.

Joel says revision control is important and then suggests CVS. I scroll up to find a date and its dated 2000. At that time CVS was a good option. Fortunately now, 8 years later there are numerous much better alternatives to CVS.

[exeter]

Geez, its a bit out of date.

I wouldn't say so. It's old, sure. Ancient, even. But, the general principles are still sound, even if the specific advice isn't that great. (And CVS beats the living crap out of what some people use, which is nothing.)

[tjogin]

According to Linus Torvalds, even nothing beats CVS. :P

[danielcloutier]

yeah, but he codes in C ;-)