Fog Creek Software
Discussion Board

Implementing Joel Test From Scratch

I just got hired in a software dev position in a company with no previous developers.  I have been given free reign to run the programming division (just me!) as I see fit, as long as I produce the code.

I see this as a unique opportunity to get things going from the ground up, and I want to do it right.  Is there an order the Joel Test should be applied?  Is it listed in order of importance?  I assume some things might not apply at the beginning, such as "Make Build in one step", or does it still apply?  How do I accomplish this?  Where can I find info on how to create scripts that do the checkout of the code, the build, etc? 

Anything I should consider while trying to implement these steps?  Any words of wisdom you can share?  Thanks!

Saturday, August 02, 2003

Anyone ever used BuildIt? Any other recommendations for a .NET daily build builder?

Saturday, August 02, 2003

Wow, that is quite an opportunity.  Hopefully, you'll get support from management for this.  Is this department expected to grow or will it be just you for a while?

In reviewing the list,  I'd day that 8, "Do programmers have quiet working conditions?" and 9 "Do you use the best tools money can buy?" are ones you'll have to work on right away.  Since these will cost money, you'll have to get support from management.  Having a productive work environment is not only an expense item, but part of the company culture, so it is important to establish that as soon as possible.

Saturday, August 02, 2003

As far as 8 and 9 go, that is where I'm really excited.  While I don't have an office with a door that closes, I will have a cubicle (fairly large) with a door that closes.  Any worries I had with number 9 were alleviated when my new boss said, "We didn't have a computer for you, so we ordered a Dell dual Xeon box for you... it will be waiting for you when you start."

Since I will have the support of management in these kind of things, and it will just be me until I get too much work to handle, I want to concentrate on the things I will have control over, like daily builds, source control, specs, etc.

Saturday, August 02, 2003

Exciting! My suggestions:

Set up your source control asap. Keep everything in there, including documentation such as requirements. Make sure you back up the repository!

One-step daily builds are pretty easy to do. I use Apache Ant to do my build automation. There are undoubtedly lots of other choices.

A bug database doesn't have to be anything fancy -- Excel will do, or, I suspect, FogBugz.

Scheduling can be a tough discipline to adopt as a single developer, but I think you can learn a lot about your own productivity by making estimates and tracking your performance against them.

Much of the other stuff is a matter of environment or execution discipline. Hallway usability testing might be particularly valuable in your situation -- since it sounds like everyone else is a businessperson rather than a developer, you should have no shortage of regular-user types to run paper prototypes by.

Best of luck!

John C.
Saturday, August 02, 2003

Learn CVS, Nant, and Draco.

IMHO they're the best tools for the job, *and* I think you'll impress management by being budget-conscious. Makes you more believable when you ask for tools that cost money.

If it's a MS shop, get them to buy you MSDN Universal.


Saturday, August 02, 2003

My first comment would be to *understand* the test enough so you can answer for yourself if daily builds, etc are important to you, and which test items might be most important for you where you are.

I don't think its worth doing daily builds because Joel says so. I think its very much worth understanding why he said so, looking at the situation you are in, and thinking "yes, thats the case here too" and doing it.

Robert Moir
Saturday, August 02, 2003

Robert - *excellent* point! Joel's test isn't about following a set of rules - no rule can be implemented unless you can justify it to your boss (and your subordinates). Otherwise you give rise to PHB's who say things like "no executable can be larger than 1.4 MB!" (because ten years ago it had to fit on a floppy...)

A good sign for a cubicle wall:
"A foolish consistency is the hobgoblin of little minds"


Saturday, August 02, 2003

> I think you'll impress management by being budget-conscious. Makes you more believable when you ask for tools that cost money. <

I dunno about that. It's been my experience that projects are either big money projects or little money projects in the eyes of the management... Once you go down the path of little money, it may be difficult for them to see why you need to buy things. Then one day they'll decide yours is high enough profile to deserve a budget and.... you won't be the person to do it because you're a little money guy.

YMMV of course.

I suspect mgt isn't interested in your methodology. Make sure whatever you present to them has a bottom line value that they can relate to... Better work environment is all fine and good, but at the end of the day, are you making money for the company?

This isn't about getting some ideal software development process... though that is a worthy thing to strive for. It's about making money for the company. Usually everything at a company is about that. Too much time spent on process will be not enough time spent on code. Rewriting requirements in your style is time not spent on code.

All I'm saying is draw the line between what's necessary - CVS, Nant, etc. and what's not... that Bob the Janitor can pass the elevator test.
Saturday, August 02, 2003

One thing not mentioned in the Joel Test but something I would like to start doing is unit testing of my code.  I have never done this before, and don't really know where to start...  Anyone know a good primer?

I agree wholeheartedly about not following the items blindly - that's one reason I wanted more information about which ones are absolutely necessary, and which ones need to be done yesterday, etc.  Thanks for all the help so far - this has been great!

Saturday, August 02, 2003

To answer my own question about Unit Testing, and seem to be good starting points... Any other good ones out there?

Saturday, August 02, 2003

If you're doing .NET development, then the N-tools are your friend: NAnt, NUnit, NDoc (all pretty much stolen from their Java equivalents, Ant, JUnit, JavaDoc). I recommend them, not because they're free, but because they're best-of-breed in my experience. NAnt gets you 1-step builds, NUnit gets you unit testing, NDoc gets you documentation.

For source control, CVS is good, although there are some quirks about using it that you may not be happy with, especially if you're used to using SourceSafe (it really bugs me that there's no rename, and that folders are not first class citizens in CVS). Some might recommend Subversion (also free), but I haven't tried it. If you're VSS-friendly, then you can use VSS or SourceGear Vault.

I've never tried any of the free bug tracking packages. They all sound EXTREMELY complicated to set up and use. My experience with bug systems has been: if it's complex, nobody uses it unless you force them to, and then they whine about it all the time. We use FogBUGZ. It's the cheapest, easiest solution I've seen.

Good luck...

Brad Wilson (
Sunday, August 03, 2003

Thanks Brad.  I have installed NUnit on my box here at home over the weekend, and it seems very straightforward and easy to use.  I never knew unit testing could be this fun!

I'm glad you mentioned the documentation - In addition to the unit testing I would like to start making a conscious effort to document my code better, and I was wondering if there was something akin to JavaDocs.  I will check that out.

To answer Philo, I believe I will ask for MSDN Universal Subscription.  I personally think it's the only way to go for a MS-Shop, and since that includes VSS I will probably go with that.  I have used CVS in the past, but I think I will just stick with the VSS.

Thinking about Philo and the Camel blog, I think I might start my own blog on starting this programming side of the house.  I doubt it will be of too much interest to the more experienced developers out there, but it would certainly help me, and might be of use to someone just getting started in IT.  I dunno - we'll see.

Sunday, August 03, 2003

I agree that VSS is more than adequate for a 1-person deal. Vault will give you a painless, seamless upgrade when you want to have lots of people, especially when you need to start accessing the repository remotely (VSS is abysmal over anything slower than 10Mbit LANs).

Brad Wilson (
Sunday, August 03, 2003

"I personally think it's the only way to go for a MS-Shop, and since that includes VSS I will probably go with that.  I have used CVS in the past, but I think I will just stick with the VSS"


You *must* learn to articulate reasons why, and this is a good place to start, since you can't say "since it includes VSS" - CVS is free, so that is *zero* justification.

VSS doesn't work unless you have a shared drive - MASSIVE security hole.

VSS's support for branching is weak at best.

VSS doesn't support merging.

Having multiple people work on a project is problematic with VSS; working an ASP.Net project is near impossible.

Remember that while *you* get VSS for free with MSDN, that's just the one client. You have to pay for each client.

So you need to put the pros and cons of each version control system and make an objective decision. Get used to it - there are a lot more down the road.


Sunday, August 03, 2003

ahh, someone else who loves to unit test

there is just something so right, so pure about unit testing

I dont know what I'd do without my NUnit

Infact, I think I will go and run some tests right now... bye!

Dan G
Monday, August 04, 2003

I like the integration VSS has with VS.NET.  I have used CVSNT with Tortoise, and it was nice.  But since it's just myself using this for the forseeable future, VSS should fit my needs just fine. 

I really do not have enough experience with either one to make a truly educated decision about which one to choose.  Since VSS will come with MSDN, I do not have a problem using that.  Remember, it's just me we're talking about anyway.  I haven't run into any problems with branching or merging in VSS, so that has never been an issue for me.  I would think VSS should be fine for me until I develop a large-enough code base where those features would be appreciated...

What do you think?  Should I go with CVS from the start?

Monday, August 04, 2003

"But since it's just myself using this for the forseeable future, VSS should fit my needs just fine."

So you'll be developing in Access then?


Monday, August 04, 2003

Not sure if it helps but here is how I "implemented" the Joel test for our group:
1. perforce
2. nant (of course)
3. nant & custom code on the web server
4. bugzilla
5. yes
6. wiki, major tasks for the 1 month iteration go in the wiki, long term plans in the wiki (wiki).  Currently using phpwiki but are thinking of switching to pmwiki for better revision control of pages
7. spec stored in wiki
8. somewhat, we have productive working conditions
9. yes, vs, perforce, office, good servers (one linux, one windows)
10. yes (though not enough)
11. yes,
12. yes

* CVS is a nightmare.  Choose Perforce, for 1 user it's free.
* Keeping a wiki organized takes thought and pruning but it sure makes getting docs on the server fast and easy
* Bugzilla is a bit of a pain to setup.  If I were doing it again and in your position I'd likely go with FogBugz.

Our group does custom tools and libraries for a large game company.

Gerry Shaw
Monday, August 04, 2003

can you explain what you mean when you say, "CVS is a nightmare"?  It's hard to reconcile all these opinions... I know a large part of it is personal preference, but it'd be nice to get objective reasons.  Philo said VSS doesn't branch very well, and can't merge.  I assume CVS does these well - how does perforce measure up?

Monday, August 04, 2003

Go with Perforce if you can afford it, its an awesome SCC system. Here are some good things about Perforce:

1. Atomic checkin's - When you check in some changes, they are submitted to the Perforce server as a single atomic changelist. This means that if one item fails for any reason, the entire checkin fails and the contents of the server are left in their original condition. This also means that other users don't get half of your changes if they sync while you are still submitting the files.

2. Excellent Windows GUI app - P4Win is a great app for working with files in Perforce. It allows you to easily branch items, manage separate changelists, view revision history for any file in the depot, diff files using your favorite diff utility, etc...

3. Command line client is available on most platforms - I've used Perforce under Windows, Linux, Mac OS X, and FreeBSD and there are clients available for most UNIX operating systems.

4. Plugin available for most versions of Visual Studio - allows you to checkout files, submit changes, add files to depot, etc... from within Visual Studio.

5. Excellent branching support - branching is quite easy from either the command line or the GUI and branched items retain all their previous revision history. Integrating changes between branches is also quite simple.

Jason Allen
Monday, August 04, 2003

CVS can take some getting used to for a VSS user. Search this forum for "CVS" and you'll find some good threads about how to get up and running.

And definitely check out TortoiseCVS - it integrates with Explorer.


Monday, August 04, 2003

For unit testing:

Tuesday, August 05, 2003


Congrats on the job and good luck with your process improvements.

Regarding source control....I've used both CVS and SS. I feel more comfortable with SS because it's what I have primarily used and the "out of the box" integration with VS.NET makes it nice.


You won't have to look very far to find plenty of people that have had tons of problems with SS once you get beyond a handful of developers. I've heard it referred to "SortaSafe" and a handful of other nasty names.

I've never had a problem with it, but YMMV.

Now for CVS...Learning CVS is more difficult than SS and it can be kind of intimidating. However, CVS is quite popular among all types of developers, from Windows to Unix. It's almost a universally accepted source control system.

Bottom line: SS is quick and easy, but learning good CVS skills will probably pay more dividends down the road. It's not that uncommon to find CVS being used even in pure MS shops.

Mark Hoffman
Tuesday, August 05, 2003

*  Recent Topics

*  Fog Creek Home