Wednesday, 10th May 2006

The Joel Test

I applied The Joel Test to the company i work for and it came up with some pleasing results.

The neat thing about The Joel Test is that it's easy to get a quick yes or no to each question. You don't have to figure out lines-of-code-per-day or average-bugs-per-inflection-point. Give your team 1 point for each "yes" answer. The bummer about The Joel Test is that you really shouldn't use it to make sure that your nuclear power plant software is safe.

A score of 12 is perfect, 11 is tolerable, but 10 or lower and you've got serious problems. The truth is that most software organizations are running with a score of 2 or 3, and they need serious help, because companies like Microsoft run at 12 full-time.

Do you use source control? Yes - VSS. Source control for web development is typically done using Microsoft's Visual Source Safe or either CVS or Subversion (SVN). Teams tend to pick a platform and run with it (as is sensible), so ASP and ASP.NET shops tend to run VSS and developers working in PHP/Python/Perl/Ruby/whatever with go with either CVS or SVN.Can you make a build in one step? Yes - The build process is completly automated.Do you make daily builds?Yes - Multiple builds are made daily.Do you have a bug database? Yes - We eat our own dogfood. A module that is integrated with our product is used to track issues (support issues, bugs etc).Do you fix bugs before writing new code?Yes - Priority is to always work on defects prior to enhancements.Do you have an up-to-date schedule?Yes And No - We were notorious for not keeping up to schedule, but are getting better at it.Do you have a spec?Yes And No - Not always, but try to. Do programmers have quiet working conditions?Yes - Total silence except for the odd burst of laughter when someone plays a prank and when people are playing dodge ball downstairs (yes it is true)Do you use the best tools money can buy?Yes - Dual Screens, P4 - 2GB RAM, 160 GB drives, Enterprise editions of all development software.Do you have testers?Yes - The ratio of Developers:QA is 3:2. Aim is for it to be 1:1.Do new candidates write code during their interview?Yes - Programming tests of different categories. (Web developement, SQL, C++, C# etc)Do you do hallway usability testing? Yes - Not in the same manner though. Instead we have 'Buck A Bug' where you get paid for every bug you can find and all employees are invited to participate. Besides any person in the company can submit product defects, enhancements especially since we eat our own dogfood and use the products we sell ourselves.Why It is ImportantSource Control

If you don't have source control, you're going to stress out trying to get programmers to work together. Programmers have no way to know what other people did. Mistakes can't be rolled back easily. The other neat thing about source control systems is that the source code itself is checked out on every programmer's hard drive. A project using source control never loses a lot of code.

Single Step Builds

The number of steps it takes to make a shipping build from the latest source snapshot should be minimal? On good teams, there's a single script you can run that does a full checkout from scratch, rebuilds every line of code, makes the EXEs, in all their various versions, languages, and #ifdef combinations, creates the installation package.If the process takes any more than one step, it is prone to errors. And when you get closer to shipping, you want to have a very fast cycle of fixing the "last" bug, making the final EXEs, etc. If it takes 20 steps to compile the code, run the installation builder, etc., you're going to go crazy and you're going to make silly mistakes.

Daily Builds

When you're using source control, sometimes one programmer accidentally checks in something that breaks the build. For example, they've added a new source file, and everything compiles fine on their machine, but they forgot to add the source file to the code repository. So they lock their machine and go home, oblivious and happy. But nobody else can work, so they have to go home too, unhappy. Breaking the build is so bad (and so common) that it helps to make daily builds, to insure that no breakage goes unnoticed. On large teams, one good way to insure that breakages are fixed right away is to do the daily build every afternoon at, say, lunchtime. Everyone does as many checkins as possible before lunch. When they come back, the build is done. If it worked, great! Everybody checks out the latest version of the source and goes on working. If the build failed, you fix it, but everybody can keep on working with the pre-build, unbroken version of the source.

Bug Database

If you are developing code, even on a team of one, without an organized database listing all known bugs in the code, you are going to ship low quality code. Lots of programmers think they can hold the bug list in their heads. Nonsense. I can't remember more than two or three bugs at a time, and the next morning, or in the rush of shipping, they are forgotten. You absolutely have to keep track of bugs formally.Bug databases can be complicated or simple. A minimal useful bug database must include the following data for every bug:complete steps to reproduce the bugexpected behavior observed (buggy) behaviorwho it's assigned towhether it has been fixed or not .

Fixing Bugs Before New Code

In general, the longer you wait before fixing a bug, the costlier (in time and money) it is to fix. There's another reason, which relates to the fact that it's easier to predict how long it will take to write new code than to fix an existing bug. What this means is that if you have a schedule with a lot of bugs remaining to be fixed, the schedule is unreliable. But if you've fixed all the known bugs, and all that's left is new code, then your schedule will be stunningly more accurate. Another great thing about keeping the bug count at zero is that you can respond much faster to competition. Some programmers think of this as keeping the product ready to ship at all times. Then if your competitor introduces a killer new feature that is stealing your customers, you can implement just that feature and ship on the spot, without having to fix a large number of accumulated bugs.

Up-To-Date schedules

If your code is at all important to the business, there are lots of reasons why it's important to the business to know when the code is going to be done. Programmers are notoriously crabby about making schedules. "It will be done when it's done!" they scream at the business people. Unfortunately, that just doesn't cut it. There are too many planning decisions that the business needs to make well in advance of shipping the code: demos, trade shows, advertising, etc. And the only way to do this is to have a schedule, and to keep it up to date. The other crucial thing about having a schedule is that it forces you to decide what features you are going to do, and then it forces you to pick the least important features and cut them rather than slipping into featuritis (a.k.a. scope creep).

Writing specs

Writing specs is like flossing: everybody agrees that it's a good thing, but nobody does it. I'm not sure why this is, but it's probably because most programmers hate writing documents. As a result, when teams consisting solely of programmers attack a problem, they prefer to express their solution in code, rather than in documents. They would much rather dive in and write code than produce a spec first.

Quiet working conditions

Knowledge workers work best by getting into "flow", also known as being "in the zone", where they are fully concentrated on their work and fully tuned out of their environment. They lose track of time and produce great stuff through absolute concentration. This is when they get all of their productive work done. Writers, programmers, scientists, and even basketball players will tell you about being in the zone.

Best Tools money can buy

Writing code in a compiled language is one of the last things that still can't be done instantly on a garden variety home computer. If your compilation process takes more than a few seconds, getting the latest and greatest computer is going to save you time. If compiling takes even 15 seconds, programmers will get bored while the compiler runs and switch over to reading The Onion, which will suck them in and kill hours of productivity. Debugging GUI code with a single monitor system is painful if not impossible. If you're writing GUI code, two monitors will make things much easier.

Most programmers eventually have to manipulate bitmaps for icons or toolbars, and most programmers don't have a good bitmap editor available. Trying to use Microsoft Paint to manipulate bitmaps is a joke, but that's what most programmers have to do. As joel once saidAt my last job, the system administrator kept sending me automated spam complaining that I was using more than ... get this ... 220 megabytes of hard drive space on the server. I pointed out that given the price of hard drives these days, the cost of this space was significantly less than the cost of the toilet paper I used. Spending even 10 minutes cleaning up my directory would be a fabulous waste of productivity..Top notch development teams don't torture their programmers. Even minor frustrations caused by using underpowered tools add up, making programmers grumpy and unhappy. And a grumpy programmer is an unproductive programmer. To add to all this... programmers are easily bribed by giving them the coolest, latest stuff. This is a far cheaper way to get them to work for you than actually paying competitive salaries!

Testers

If your team doesn't have dedicated testers, at least one for every two or three programmers, you are either shipping buggy products, or you're wasting money by having $100/hour programmers do work that can be done by $30/hour testers.

Code Tests during interview

Would you hire a magician without asking them to show you some magic tricks? Of course not. Same way for programmers.

Usability testing

A hallway usability test is where you grab the next person that passes by in the hallway and force them to try to use the code you just wrote. If you do this to five people, you will learn 95% of what there is to learn about usability problems in your code.

Posted by Nikhil on Wednesday, 10th May 2006 in TechnoBabble | Fun

Comments

1 Do you use source control? Yes, Clearcase. 2 Can you make a build in one step? Yes, I made it into one step process (:D), but it takes ages to build! 3 Do you make daily builds? Yes 4 Do you have a bug database? Yes 5 Do you fix bugs before writing new code? Mostly yes 6 Do you have an up-to-date schedule? Yes 7 Do you have a spec? Yes, that is part of process. 8 Do programmers have quiet working conditions? Yes, for most part. 9 Do you use the best tools money can buy? A big No: 1) I used to get mails that I am exceeding 500 MB limit on my server 2) They refuse to give us anything but stupid CDE as desktop environment on the server, I had a fight with sysadmin because they blocked GNOME! 3) my hdd is 40 GB, I dont have admin rights on my PC.. 10 Do you have testers? Yes 1:1. 11 Do new candidates write code during their interview? Sometimes, the whole interview process seems arbitrary. 12 Do you do hallway usability testing? Not applicable! No code I write is actually UI. I guess my company gets 9/11 :-) (1/2 lost for fix-bugs-before-new-code and make-candidates-write-code questions.)

Posted by: Rajesh Goli on Thursday 11th of May 2006 03:39:28 AM

Hey two issues with using your comment system: 1) How do I make two lines come in seperate lines? 2) If I hit Tab when I am in the name column, the whole screen scrolls all the way up to the top, can't the next tab-stop be Email-address? Same holds for email and URL fields.

Posted by: Rajesh Goli on Thursday 11th of May 2006 03:41:08 AM

Hey rajesh, i checked the tabindex on the from elements on both firefox and IE and they seemed fine. Dunno why you are having the tab problems

Posted by: Nikhil on Sunday 21st of May 2006 12:02:55 PM

ooo

Posted by: