You don’t have any of these, and you say you can write code?

[[129460]]

Have you heard of SEMA? It's a pretty esoteric system for testing how good a software team is. No, wait! Don't click on that link! It'll take you about six years to learn about this stuff. So I came up with my own, comparatively irresponsible, sloppy test for evaluating the quality of a software team. The best part about this test is that it only takes you 3 minutes. All that time you save, you could go to medical school.

The Joel Test

Do you use source control?

Can you make a build in one step?

Do you make daily builds?

Do you have a bug database?

Do you fix bugs before writing new code?

Do you have an up-to-date schedule?

Do you have a spec?

Do programmers have quiet working conditions?

Do you use the best tools money can buy?

Do you have testers?

Do new candidates write code during their interview?

Do you do hallway usability testing?

The nice thing about the Joel test is that it's easy to quickly get a "yes" or "no" to each question. You don't have to dig up lines of code per day and average bugs per inflection point. If your team gets a "yes", score one. The disappointing thing about the Joel test is that you really shouldn't use it to ensure the security of your nuclear power plant software.

Getting a 12 is perfect, 11 is tolerable, but a score of 10 or lower indicates that you have serious problems. In fact, most software companies operate at a score of 2 or 3, and they really need help because companies like Microsoft have been operating at a perfect 12 for a long time.

Of course, these aren’t the only factors that make or break a product: especially when you have a great software team that’s building a product that no one wants, people really won’t buy into it. And it’s possible for a “sharpshooter” who doesn’t do this to still produce incredible, world-changing software. But, all else being equal, if you do these 12 things well, you’ll have a team that consistently gets things done.

Do you use source control?

I've used commercial source control packages, and I've used CVS, which is free, and let me tell you, CVS works great. But if you don't have source control, you're going to be stressful trying to get programmers to work together. Programmers have no idea what others have done. Mistakes can't be easily fixed. Another great thing about source control systems is that the source code itself can be verified on each programmer's hard drive - I've never heard of a project that used source control and lost a lot of code.

Can you compile the program in one step?

By doing this test I want to understand: how many steps are needed to go from a quick copy of the latest source code to a compile that can be exported? In the best teams, there is a single script that does a comprehensive check of the code from scratch, recompiles every line of code, generates EXE files, in their various versions, programming languages ​​and #ifdef macro definition combinations, creates installation packages and final media - CDROM layout, download website, etc.

If this process takes more than one step, it's easy for errors to creep in. When you're nearing completion, you'll want to have a quick cycle of fixing that "last" bug, generating the final EXE, etc. If it takes 20 steps to compile your code, run the install compiler, etc., it'll drive you crazy and cause you to make stupid mistakes.

The last company I worked for switched from "smart" mode to "software installation packaging" mode for this very reason: we required it to be run during the installation process, using NT scheduling to run automatically from a script all night long, and the "smart" mode could not do this, so we abandoned this mode.

Do you compile your code every day?

When you use source control, sometimes programmers accidentally check in something that stops compiling. For example, they add a source file, and everything compiles fine on their machine, but they forget to add the source file to the repository. So they lock their machine and go home, forgetful and happy. But no one else can work anymore, so they have to pack up and go home, unhappy too.

Breaking compiles is bad (and common), but it helps to compile the code every day to make sure that the compile doesn't break without warning. In large teams, a good way to ensure that breaks are fixed quickly is to compile the code every afternoon, perhaps at lunch. Everyone does as much code review as possible before lunch. That way, when they get back from lunch, the compile is done. If it works, great! Everyone checks in the latest source code before moving on. If the compile fails, you fix it, but everyone continues to work on the precompiled, non-breaking version of the source.

In the Excel project team, we have a rule: whoever interrupts the compilation, as a "punishment" for him, will temporarily take care of the code compilation work before others interrupt the compilation. This is a good way to motivate people not to interrupt the compilation, and it is also a good way to let everyone take turns to participate in the compilation work so that everyone can understand the compilation principle.

Do you have a bug database?

I don't care what you say. If you're developing code, even on a one-person team, without an organized database of all the known bugs in your code, you're going to produce low-quality code. Many programmers think they can keep a ton of buds in their heads. That's bullshit. I can't remember two or three bugs at once, and then forget them the next morning, or in the middle of a coding rush. You absolutely have to track bugs formally.

But databases can be complex or simple. A minimal bug database must contain the following data for each bug:

The complete steps to reproduce this bug

Expected behavior

Observed Behavior

What is it designed for?

Has it been repaired?

If the complexity of bug tracking software is the only reason that keeps you from tracking your bugs, just use the simple 5-element table above for these critical fields and start using it.

Do you fix bugs before writing new code?

The first version of Microsoft Word for Windows was considered a "death march" project. There was no telling when it would be finished, and it kept getting delayed. The team worked ridiculous hours, and the project got delayed again, and again, and again, and the pressure was incredible. When the damn thing finally shipped, a few years later, Microsoft sent the entire team on vacation to Cancun, so they could do some serious soul-searching.

They realized that the project managers had been insisting on "schedules" for deployment, and the programmers were simply rushing through the coding process, and because the bug-fixing phase was not part of the formal schedule, they were writing extremely bad code. There was no countdown to try to keep the bugs from happening. On the contrary, it was said that a programmer who wrote code to calculate the line height of text, just wrote "renturn 12;" and then waited for bug reports about his feature to always be correct. The schedule was just a checklist of features that were about to become bugs. Afterwards, this was called the "method of infinite bugs."

To solve this problem, Microsoft has generally adopted something called a "zero defect approach." Many programmers at the company chuckle because it sounds like a management philosophy that can reduce the number of bugs by administrative decree. In fact, "zero defects" means that at any given time, the highest priority is to eliminate bugs, followed by writing new code. Let me explain why.

In general, the longer you wait to fix a bug, the more costly that bug will be (in practice and in money).

For example, when you make a spelling or syntax error that the compiler catches, it's trivial to fix. When you first see a bug in the code you're trying to run, you can fix it quickly because the entire code is still fresh in your mind.

If you find a bug in code you wrote a few days ago, it will take you a while to find it, but when you reread the code you wrote earlier, you will remember everything and be able to fix the bug in a reasonable time.

But if you find a bug in code that's a few months old, you've probably forgotten most of what you knew about that code, and it's hard to fix it. You might also be fixing a bug in someone else's code, and they might be on vacation in Aruba, in which case bug fixing is like science: you have to work slowly, methodically, and meticulously, and you can't be sure how long it will take to find a cure for the problem.

If you find a bug in code that has already been sold, you will incur incredible costs to fix it.

This is one reason to fix bugs right away: because it takes less time. It's about how long you wait before writing new code, not how long you wait before fixing a bug. For example, if I asked you to predict how long it would take to write code that sorts a list, you could give me a pretty good estimate. But if I asked you to predict how long it would take to fix a bug that stops working after installing Explorer 5.5, you'd have no idea what caused the bug. It could take 3 days to track down, or it could take 3 minutes.

What this means is that if you have a schedule with lots of bugs to fix, that schedule is not going to work, but if you fix all the known bugs and all that's left is new code, then your schedule will be incredibly accurate.

Another important thing about having zero bugs is that you can respond to competition faster. Some programmers think this allows the product to be ready for release at any time. If your competitor introduces a killer new feature from your customers, you can implement just that feature before release, without having to fix a ton of accumulated bugs.

Do you have an updated schedule?

This test brings us to scheduling. If your code is important to the business, there are many reasons why the code completion date is important to the business. Programmers are notoriously stubborn about scheduling. "It's done when it's done!" they'll scream to business people.

Unfortunately, this doesn't make everything better. There are so many planned decisions that need to be made before the code is released: software demos, trade shows, advertising, etc. And the only way to do this is to have a schedule and keep it up to date.

Another crucial reason to have a schedule is that it forces you to decide which features to work on, and then forces you to pick out the least important features and kill them instead of getting stuck in a long period of indecision.

At the same time, following your schedule doesn’t have to be demanding.

Do you have standards for writing code?

Writing standards is like flossing, everyone agrees it's a good thing to do, but no one does it.

I don't know why this is, but it's probably because most programmers hate writing documentation. As a result, when a team of mostly programmers is faced with a difficult problem, they are more likely to express their solution in code rather than in documentation. They would rather dive into writing code than write a specification first.

When you discover a problem during the design phase, you can easily fix it by editing a few lines of text. Once you start writing code, the cost of fixing a problem is much higher, both emotionally (people hate throwing away code) and in terms of time, so there is resistance to fixing problems at this point. Software that is not built from a specification usually ends up with poor design and uncontrolled schedules. This seemed to be a big problem at Netscape, where the first four versions of Netscape slowly became a mess, and management stupidly decided to throw the old code away and start over. Then they made the same mistake again with Mozilla, creating an out-of-control monster and wasting years just to get back to the beginning.

I have always maintained that this problem can be solved by sending programmers to intensive writing courses to turn them into near-real writers. Another solution is to hire some smart program managers and have them write the code standards. In both cases, you should enforce the simple rule "no code without standards".

Do programmers have a quiet working environment?

It is widely documented that productivity can be improved by providing knowledge workers with space, quiet, and privacy. The classic software management book, Peopleware, extensively documents the productivity benefits from these aspects.

Here comes the problem. We all know that knowledge workers work best when they are in the "flow," what we call "being in the zone," where they are completely absorbed in their work and completely tuned out of their surroundings. Through absolute focus, they lose track of time and produce great code. This is the process by which they get work done. Writers, programmers, scientists, and even basketball players will tell you to be in the zone.

The problem is, it's not that easy to get in the zone. When you try to measure it, it seems like it takes about 15 minutes to get going at maximum productivity. Sometimes, if you're tired or have done a lot of creative work that day, you just can't get in the zone, and you spend the rest of the day fiddling around, browsing the web, or playing Tetris.

Another problem is that it’s very easy to get out of that zone. Noise, phone calls, going out to lunch, having to drive 5 minutes to Starbucks for coffee, and interruptions from coworkers—especially interruptions from coworkers—can pull you out of that zone. If a coworker asks you a question, causing a one-minute interruption, that will be tragically out of your zone, and it will take you half an hour to be productive again, and your overall productivity will be in big trouble. If you’re in one of those noisy bullpen-like environments that caffeinated dot-coms love to create, with marketers screaming on their phones next to programmers, your productivity will plummet as knowledge workers are interrupted again and again and never get back into the zone.

For programmers, it's even harder. Productivity depends on being able to juggle many small details in short-term memory at once. Any kind of interruption causes those details to come crashing down. When you get back to work, you can't remember any of the details (like the name of the local variable you were just using, or the bright idea you just came up with to implement the search algorithm), and you have to keep trying to remember those things, which slows you down until you can become productive again.

There's a simple algebra here. It can be said (and there's evidence to suggest) that if we interrupt a programmer, even for just one minute, we really do lose 15 minutes of productivity. In this example, let's assume there are two programmers, Jeff and Mutt, in a standard adjacent open cubicle. Mutt can't remember the name of the Unicode version of the strcpy function. He can look it up, which takes 30 seconds, or he can ask Jeff, which takes 15 seconds. Since he's sitting right next to Jeff, he chooses to ask Jeff directly. Jeff gets distracted and loses 15 minutes of productivity (saving Mutt only 15 seconds).

Now let's put them in two offices separated by a door and a wall. If Mutt forgets the function name, he can spend 30 seconds to look it up, or spend 45 seconds to ask Jeff, which involves standing up (this is not an easy task considering the average physical fitness of programmers!). So he will choose to look it up himself. In this way, Mutt loses 30 seconds of work efficiency, but saves Jeff 15 minutes. Hahahaha!

The best tool money can buy?

Writing code in a compiled language right away on your home computer in the park is still one of the worst things to do. If your compilation process takes more than a few seconds, using the latest and greatest computer will save you some time, and while the compiler is running, programmers will get bored, and then they will switch to reading something else, which will absorb their attention and lose hours of productivity.

Debugging GUI code with a single monitor is painful, but not impossible. If you're writing GUI code, having two monitors makes a lot of things easier.

Most programmers end up dealing with bitmaps for icons or toolbars, but most of them don't have a good bitmap editor. Trying to use Microsoft Paint to deal with bitmaps is a joke, but that's what most programmers have to do.

At my last job, the system administrator kept sending me automated spam complaints about me using over 220 megabytes of hard drive storage space on the server. I pointed out that given recent hard drive prices, that amount of hard drive space cost me less than the toilet paper I was using. Even taking me 10 minutes to clean up my mail directories was a ridiculous waste of my productivity.

Top development teams don't torture their programmers. Even small frustrations caused by imperfectly functioning tools can add up and make programmers grumpy and unhappy. A grumpy programmer is not a productive programmer.

Programmers are easily bribed with the coolest, newest stuff. It's a cheaper way to get them to work for you than paying them a competitive salary.

Do you have testers?

If you don't have dedicated testers on your team, at least one tester for every two or three programmers, you're either going to end up with a buggy product, or you're paying a $100/hour programmer to do the same job that a $30/hour tester could do. The money saved on testers is a ridiculous false economy, and I just want more people to realize that.

Do job seekers write code during interviews?

Would you hire a magician without seeing his tricks? Of course not.

Would you hire a caterer for your wedding without ever tasting his food? I doubt it.

Yet, day after day, programmers are hired on the basis of impressive resumes, or because the interviewer enjoys chatting with them. Or they are asked minute questions ("What's the difference between CreateDialog() and DialogBox()?") that can be answered by looking at the documentation. You don't care if they remember a thousand details about programming, you only care if they can actually write code. Or, worse, they are asked "Huh?" questions: the kind that seem simple if you know the answer, but are meaningless if you don't know the answer.

Please, don't do this again. Ask whatever you want during the interview, but make sure to ask the programmer to write some code.

Do you do hallway usability testing?

Hallway usability testing is when you meet a person in the hallway and force them to try the code you just wrote. If you do this with five people, you will learn the answers to 95% of the usability questions you need to learn about your code.

Good user interface design is not as difficult as you think, and it is crucial if you want users to like and buy your product.

But the most important thing about user interfaces is that if you show your app to a lot of people (five or six is ​​enough), you’ll find out the biggest problems people have with it. Even if your UI design skills aren’t great, if you force yourself to do hallway usability testing, it doesn’t cost anything, and your UI will get better.