Fog Creek Software
Discussion Board

Joel's 12 point Test and Small Businesses

I thought I would apply the 12 point Joel test to my own self employed business to see how I rate. Also uncle Joel says to tell him how your software organization rates so he can gossip (!!?) And I want to know how others view the applicability of Joel's test to small businesses.

Before starting, let me repeat I'm the *only* person involved in this business. It is software for a special highly unprofitable niche that for some strange reason has been neglected by the market. Although I've been going for a while it's still in start-up mode. No-one else has any involvement with the computers, documentation etc. It runs under Windows and I have no involvement with Macs, Unix, Linux, OS/2 or other O/S. So here we go...

1. Do you use source control? (0.5)

No. I should, but I'm the only person here and I've given higher priority to other tasks like getting the product done. I do version-based backups to archived CD-Rs which makes it possible to roll back mistakes, guards against losing code and helps track when problems surfaced. So I'll give myself half a point.

2. Can you make a build in one step? (1)

Yes. After trying and failing with Finalbuilder, I wrote a VB script program that builds everything (about 4 hours). It has a nice little desktop icon, does a virus scan when it starts, does the actual build and shuts down the computer when it finishes. So I get one point here.

My build script doesn't burn the CD. And I still don't know if
I like or hate VB script. I don't like the way Microsoft change the function names and make you use bogus OO notation. VBS != OOP and it doesn't matter, Microsoft.

3. Do you make daily builds? (0.5)

Yes if I did any coding that day. No if I spent the day down the beach (dream on). I deserve at least half a point.

4. Do you have a bug database? (0)

No. If there were 2 or more people here I would, and if I had customers who reported bugs I would. I haven't so I don't. I agree with Joel that you can't keep the list in your head. So I fix most bugs when they appear. If the bug is more a design flaw or something that can't realistically be done or needs re-design, the offending code is removed and the re-design task goes in the spec.

So I get zero points here, especially since this whole site is about bug tracking software!

5. Do you fix bugs before writing new code? (1)

Yes (see 4). Joel's comments under (5) are very profound and true. So re-read them!!! I've put the link at the end.

6. Do you have an up-to-date schedule? (0.5)

Yes. Although it's mixed in with the spec and I tend to blow all the deadlines. I used to have really vague deadlines like 'write compiler - one month' but now I subdivide all the tasks. So I get about half a point here.

7. Do you have a spec? (1)

Yes. I like writing specs and documents. The more carefully you write the spec the more focused the code will be. I like the feeling I'm saving days of coding by hours of thinking. Also my spec is divided into 'essential' and 'optional' tasks with time estimates to help the schedule.

8. Do programmers have quiet working conditions? (1)

Yes they (I) do. This is important, and one of the advantages of being self unemployed is you can control your environment more.

9. Do you use the best tools money can buy? (0)

I would like to but don't have the cash. In fact I disagree with Joel on this question. The reality for any start-up is you're in a race to build revenue before running out of money. The basic law for any business is DO NOT run out of money. So I only buy stuff I can't get second hand, or can't find in trial versions on the web.

I feel strongly about this, but won't go on too long in case it
turns into a bitter rant. Preserving cash is paramount, without it your business and your life become complicated and unpleasant in ways you can't imagine. If any readers are thinking of becoming self employed, use money from your present job to buy nice PCs development tools printers etc before you start. Or give away 90% of the product in exchange for inadequate external funding.

Anyway I get zero points here. But I have a lan so I can do other things while compiling. Also web access is very expensive where I live so I don't feel tempted to log on and read the 'onion' or peruse any other online vegetables while compiling.

10. Do you have testers? (0.5)

I have test suites that reproduce most bugs that can be recorded, and this includes regression tests. Also my software has internal testing modes that check internal integrity, memory block lists, heap leaks etc, and these are run as part of the build script (see (2)). I don't employ myself in a formal testing mode of going over existing code trying to find problems, though. So I deserve half a point.

11. Do new candidates write code during their interview? (0)

No. But I can't pay myself yet, let alone anyone else, so the question is not applicable.

12. Do you do hallway usability testing? (0.5)

I do usability tests (see Disclaimer below) on my own software. Over the years I've become impatient with crashy/buggy/non-functioning/confusing software. It annoys me and I usually remove it on aesthetic grounds. If I have to live with it I provide a sarcastic running commentary on the product's deficiencies for the benefit of the neighbours. Flaws in my own product annoy me just as much so I generally fix them (although see Disclaimer below). 'Flaws' includes not only bugs, but things that
don't behave the way they should. Most Windows developers have an 'internally wired' expectation of how a product should operate, and I make sure my product conforms to this.

Since my usability tests are done by me (see Disclaimer) I only deserve 0.5 point.

Disclaimer: I realize usability tests should not be done by the person who wrote the code. I promise, I really do realize this. Undoubtedly my product has usability problems I've got used to, and so I can't see them until they're pointed out by someone else. But I do know how similar products operate, so I *can* fix deficiencies in relation to the 'expected' behaviour. So although my self-applied testing is flawed, it's a lot better than nothing.


I make the total 6.5 which looks OK but anything under 10 indicates problems according to the test. While working through this test I think some questions are not applicable:

(1), (10) and (12) are for business with more than one developer.

(9) is too idealistic for most start-ups. For many new businesses the doors close when the credit card limit is reached.

(11) does not apply to self-employed.

Apart from these I think the Joel test is accurate and contains a lot of insight. Certainly it got me doing one step builds ((2) and (3)) and I didn't realize how much I needed this until I got them working. And I think that for any 'normal' business that employs people and makes money, all the questions apply. Although (9) only applies if you make a healthy profit!

All the best
Bill Rayer

PS: Joel's test is at the easily remembered URL (:-)

Bill Rayer
Tuesday, April 22, 2003

Your comment regarding source control only being for >1 developer is common, and I believe entirely wrong. I personally obviously use source control when doing team development, but I also absolutely use it on small projects that only I work on: The ability to do change auditing is absolutely invaluable. I make it a habit of checking in (keeping checked out) files frequently to ensure that I don't lose hours of work, etc. While you could theoretically do this with backups, the likelihood that you will do it with the frequency that people do in source control is tremendously unlikely.

Dennis Forbes
Tuesday, April 22, 2003

I fully agree SCCS are important. But if you run a small business in the 'pre-scrawny' stage (to borrow Joel's terminology) many important tasks are not done because the essential tasks take priority.

For an individual most of the functions of SCCS can be implemented by rotated version-based full backups stored off site. I would estimate over several years full time development, I have not lost more than 2 or 3 hours through not having a SCCS.

Bill Rayer
Tuesday, April 22, 2003

I also use source control, although I am the only developer on my project. For me, it's a safety net. If I royally screw up something I can always rollback the changes.

I use a bug tracking system too. My client never sees the bug list, nor does anyone else but it keeps me straight since I know that I will forget a glitch that I recorded at 3:00 AM in a caffeine induced haze. I also make small notes when I resolve an issue and that has proved useful a few times when I encountered similiar bugs.

Mark Hoffman
Tuesday, April 22, 2003

Even if you're the one and only one developer, a good source control system makes your life much easier.  Download perforce and use it for free.  2 developers run for free, and its very easy to admin.

Nat Ersoz
Tuesday, April 22, 2003

Me too!

Ah, oops, sorry 'about that. But I have to chime in and agree with everyone else that you should probably stop whatever you're doing and get your code under version control. Right now! Stop reading this and do it!

And don't worry about "best tools money can buy". Go to and get the windows version of CVS. Good instructions there. You can have it set up in under an hour.

And a bug tracker too while you're at it. One of the first things I did at my new job was took an old computer that no-one was using, put some linux distribution on it, put CVS and bugzilla. And there you go, the company now scores 17% higher on the Joel test.

Bill Tomlinson
Tuesday, April 22, 2003

I agree that if there was ever more than one developer on this project, or if the project generated income, or if I had more free time, or if this was a 'normal' business, I would use a SCCS.

But given that I've lost 2 hours in the last 3 years through not having SCCS, is it really going to make me more productive by installing a fresh PC on my LAN with suitable SCCS software?

This article wasn't about ideal development practice. It was more like "which of Joel's rules save useful amounts of time". Using one-click build has saved me 100s of hours. Not having SCCS has cost me 2 hours.

Bill Rayer
Tuesday, April 22, 2003

Anyway I'll take a look at and
I would prefer not to have to buy another PC though (see rule 9!)

Bill Rayer
Tuesday, April 22, 2003

You *don't* need another computer - there are plenty of source control systems available for Windows.

Don't just count the amount of time lost due to lost changes. Also consider the increased productivity by being able to quickly & easily being able to see when changes were made, what the old source looked like, when bugs were introduced/fixed, etc.  Not losing changes is only a small reason to use source control.

Since a simple source control system would take about an hour (or less) to set up and not add any appreciable time to development I don't see a problem with this.

Tuesday, April 22, 2003

Nat & Bill mentioned and perforce which was why I looked at those two. They need separate servers and probably won't work over IPX/SPX (perforce won't). My heart sank when I read the faqs for those two, they are definitely not two-hour install products.

I agree it would be handy to see changes, sort of like using windiff to compare the current version 1.n to 1.(n-1) or whatever. The only Windows based version control system I used was source safe (I think) that was about 6 years ago.

The 1-hour install single user systems you talk about sound more appropriate. I will do some research (google here I come)..

Bill Rayer
Tuesday, April 22, 2003

>My heart sank when I read the faqs for those two, they are definitely not two-hour install products.

You're right, CVSNT is definitely not a 2 hour install product - I just installed CVSNT in 10 minutes with the installation walkthrough on that site.  And it works =)

Tuesday, April 22, 2003

I'm the only developer in our company. I run Perforce on my development machine (no additional server required). It took less than an hour to get set up and definitely has been worth it.

Richard Lawrence
Tuesday, April 22, 2003

"You're right, CVSNT is definitely not a 2 hour install product - I just installed CVSNT in 10 minutes with the installation walkthrough on that site.  And it works =) "

It would take me longer than that to download, and I don't have a Windows 2000 machine for a server. You must be smart to get it going that quickly!

I'm thinking that something like sourcesafe is better for single-user development. I like the warm feeling of security that comes from using Microsoft products...

Bill Rayer
Tuesday, April 22, 2003

Google on "Sourcesafe Corrupt" before you make that decision...


Tuesday, April 22, 2003

SourceSafe was a nightmare. I don't recommend it if you have an alternative. Now that I've switched to Perforce, I finally understand how useful source control can be. Specifically, the two major issues I had with SourceSafe were (1) data getting corrupted and (2) not being able to branch and merge in a managable way.

Richard Lawrence
Tuesday, April 22, 2003

I like the warm feeling of security that comes from using Microsoft products...


Nat Ersoz
Tuesday, April 22, 2003

You don't need a separate server for cvsnt. I run a copy of it on my laptop and it works great. I also used to be a single developer and went looking for a SCCS when a few other part-time developers appeared in the picture. I now use cvsnt (with TortoiseCVS and WinMerge for diffs) even for my own home personal projects.

Bob Willis
Tuesday, April 22, 2003

Here is my test... (and yes, I do own the company)
Do you use source control?
- yes.

Can you make a build in one step?
- Yes, however this is a function of system complexity.  In this regard I have to disagree with Joel.  I do not buy that MS is a 12 out of 12 on this one.  Does anyone really believe value exists in being able to "make Office XP" as a single event?

Do you make daily builds?
- No, but I also see little value in daily builds on complex projects.  The more complex they are the more time a build itself takes.  Builds should be logical units of work.  Source control keeps you from losing interim versions.  Yes, people will break things, but they will regardless.  That being said, checking in unbuilt code is a performance issue.

Do you have a bug database?
- Yes, however a better wording would be " Do you have a bug tracking mechanism."  It doesn't matter if a person uses emails and a spreadsheet as long as bugs can be tracked effectively.  The more tool the better, but a sledge-hammer for a fly swatter is not a better value.

Do you fix bugs before writing new code?
- Sometimes.  Bugs fit into a priority schedule like anything else.  Treating them as "special"  alters the business focus for what is important to what is broken.  Assuming they are always the same is a mistake.  Joel's comment "In general, the longer you wait before fixing a bug, the costlier (in time and money) it is to fix."  is true of the any feature introduced later in the product lifecycle.  The cheapest features are those whose definition is complete during the design phase.  The most expensive are those completed post implementation.  Bugs are the same way.  Again, I am unwilling to believe that MS would not ship a product with a known bug because it was broken early in the life cycle.  Interesting is Joel contradicts himself in the next question.

Do you have an up-to-date schedule?
Yes, as those things exist.  However, "up to date" is an illusion fostered by people with the idea that we can somehow track how many widgets of code are produced and that one widget is equal to all other. The reason so many software projects are "late" is supporting this illusion becomes more important than getting the product out the door.  Excellent reference:

Do you have a spec?

Do programmers have quiet working conditions?
When necessary.  I have seen the studies and given a specific task "X" developers do better in such an environment.  However, I have seen teams produce better projects working where they can overhear each other.  A whiteboard at the end of the hall where people can discuss "on the spot."  Also, the 15 minute rule is a terrible over generalization.  Read the reports and they do not reflect that one to one relationship as Joel implies.

Do you use the best tools money can buy?
Yes, but --- No and neither does anyone else.  By the time the team is trained and in place, the tools have been updated.  Also a classic mistake is to assume introducing a tool will allow you to finish a project sooner.  Equally dangerous are those people insistent on upgrading tools during the cycle.  Unless something you need is broken or missing stay away from upgrades, those are productivity killers.

Do you have testers?
Yes, and I agree to a point again.  Having three $30/hour testers sitting around is not cost productive either.  The business objective is to figure out what the number needs to be and how to staff for the ebb and flow.

Do new candidates write code during their interview?
No. I see too many people great at test taking. If you are worried about the magician, the bring them on as a consultant. Test them out and then you know.  I have seen some very good people fold under the tests given during in-house training.  I certainly would not eliminate them in an unrealistic situation.  If you are worried about performance under pressure, try before you buy.

Do you do hallway usability testing?
Yes, and for people who don't this will save you plenty.

Mike Gamerland
Tuesday, April 22, 2003

Regarding "best tools": I cannot agree with you more. Several examples that I know of, people started company, got most expensive computers they could find (really, for about 15% more speed, twice the cost), got all software they could think they possibly wanted... then went bankrupt.

Of course, buying tools is a matter of cost vs effect. If you have many millions and are short on time then money doesn't matter. On the other hand, if I had many millions, I wouldn't be here alltogether, but on a nice sunny beach with a Marguerita and a big smile. However, if not having a particular tool is putting a huge dent in your productivity, and the increase in productivity justifies the cost, then you will have to do it.

Regarding source control: they say it's a great thing, and probably it is, I have never used it. I tried it once and hated it. What I do and find extremely efficient is to backup everything on a ZIP drive. They are cheap, store 250 megs, and you use them as a diskette. I have a cd-burner as well, but never use it. You can save on the ZIP fifteen times a day, you'd never do this on a CD.

My two cents.

Btw, lingo sounds interesting. One question, why didn't you write your compile-it-all script in it?

Tuesday, April 22, 2003


A word to the wise, I spent 3 years supporting Zip drives for Iomega...don't use it as your only backup. 


Tuesday, April 22, 2003

Ditto on ZIP. They're crap technology. What's wrong with CD-RW? I find it plenty fast enough. 700MB in a few minutes.

Brad Wilson (
Tuesday, April 22, 2003

700Mb in a few minutes.
300Mb in a couple of minutes.
100Mb in one minute.
10Mb in one minute.
1Mb in one minute.

CD-R is too slow for small/frequent/incremental backups.

Tuesday, April 22, 2003

Source Control / Revision Control is essential.  Even if you are the only developer, the time and productivity benefits will pay off in no time at all.  There are plenty of $0 options that can install on the same machine you are using for development.  (I will use CVS to refer to all source control system)

With manual periodic backups, you cannot easily compare two different versions of a file to see what has changed.

Say you notice a bug that wasn't there before.  You test your previous builds, if you kept them around, using a binary search pattern to find out the general time the bug was introduced.  You can do this with either manual backups or CVS.

With a manual backup, you'll have to locate the file containing the right dated build, hope you didn't already throw away all the builds that old (re-using the zip disk), get the archive off the zip, unzip the archive, and then manually diff the appropriate files.  Keep in mind you'll need to either locate and unzip two different builds manually OR you'll need to compare the last unaffected build with the most current version, which may have LOTS of changes since then.

With CVS, you just click on the file, highlight the versions on either side of the bug-introduced-date, and click the Compare button (or something similar).

The fact that it is so much easier makes you much more likely to do it.  Humans are naturally lazy.  We tend towards the easier path, even if it isn't the best path.  Luckily, we can use tools (like CVS et al) to make the Right Thing(TM) easy enough that we'll actually do it.

Source/Revision Control.  USE IT.  Even if you are the only developer.

Note:  Backups are still essential as well.  Source control won't save you from a dead hard disk on the source control machine.

Richard Ponton
Tuesday, April 22, 2003

Oh, and don't use ZIP disks.

Get an external hard disk if you don't want to use CDRs.  If you already have a LAN, then you can just copy your backups to another computer and burn a CD periodically.

Hard disks are so cheap nowadays that you can afford a redundant one.

Richard Ponton
Tuesday, April 22, 2003

If you are running on windows get Tortoise cvs. You can create new local repositories and  add modules in a very few minutes. It does not get much simpler. An easy way to  add an extra half point to your score.

Tuesday, April 22, 2003

Maybe this is off-topic, but I recently discovered the P2P company Mojo Nation has resurrected itself and its P2P technology to create Hive Cache creates encrypted backups of your data on a pseudo-RAID disk using P2P clients. I had this same brainstorm just a few weeks ago, but they've actually done it!  <:-)  Beware, their software is still beta.

Tuesday, April 22, 2003

I have to say that it BLOWS my mind to hear people say that they don't use source control and don't know why they should.  WHAT?  I have to wonder how much experience you actually have if you don't know/understand the benefits.

Like others have mentioned, backups are just one minor part.  The history of the files, both the descriptions and the actual code diffs are truly the greatest value, at least for me.  Without those, there is no way that you could accurately track down a bug in a complex system and understand how and why it got there.  What looks like a bug now may have been a reasonable decision at the time, but you'd never know that without history.

Incredible.  Seriously, if you aren't using source control, start, and do some reading to learn how to use it properly (check in only code that will build, document the reason for your checkin, label your builds, etc.).  I would probably put it above every single other thing on Joel's list.  In fact, I considered it so fundamental, I barely remembered that it was in his list.

Tuesday, April 22, 2003

Any online books for Perforce?

Prakash S
Tuesday, April 22, 2003

We use sourcesafe here, and I use it at home. Due to the piss poor design of this software, it is incredibly difficult to have multiple developers work on different aspects as a lot of functionality is coded into individual screens.

In one case, we'll call it Form 'A', complete functionality for one major operation of the software is wrapped up in one form. Not so bad, you may think. However, all *supporting* functionality of this one major piece is *also* in this form. If developer 'A' needs to do work on requirement 'A' and developer 'B' needs to do work on requirement 'B', and they both happen to be on form 'A', you're screwed. At some point you are going to have to manually merge two files together.

Now, due to buildability, you may have to keep one file outside of source control for weeks on end. You may also have to touch other files to complete the task at hand. Blah blah. It's a nightmare. Things are constantly being half checked in, written over, erased completely, missed in builds etc.

There has been one shining light of recent days. One of the developers came up with the idea of running seperate copies of source safe on the local machines. That way you can work properly under source control, and it also makes merging your changes back into the mailine code much easier, as you can just run a search over sourcesafe for files you've changed since your last merge date, and label every merge.

It's beautiful, and seems to work like a treat at the moment. So now we are using double the amount of source code control. :)

Geoff Bennett
Wednesday, April 23, 2003

"We use sourcesafe here, and I use it at home. Due to the piss poor design of this software, it is incredibly difficult to have multiple developers work on different aspects as a lot of functionality is coded into individual screens"

This is an artifact of your development environment and coding practises, not your source code control system.

Some IDEs make it remarkably easy to draw screens, and place all of the implementation into a single file. This is not the same as doing modular design. If each feature is in a separate module and shared code is also in its own module, then it is significantly easier to share code, even if your source code control system is limited to locking entire modules.

I'll admit that something like CVS which is reasonably good at allowing multiple developers to work on the same file is a wonderful thing, but it's no substitute for splitting an application into decent modules.

andrew m
Wednesday, April 23, 2003

There's a lot of noise being generated about source control here.  Bill's original method (and probably continuing one) is source control, that it doesn't maintain diffs and trees and what have you is beside the point.

However, how many using more sophisticated source control tools know how and under what circumstances backups are done?  Are they done at all?  Has any test recovery ever been done?

Simon Lucy
Wednesday, April 23, 2003

Believe we're one of the top 5 in North America. (I'm not based there tho ...)

1) Do you use source control?

2) Can you make a build in one step?         
No, not generally.

I would rephrase this:
"Is the build procedure documented, easy to follow and relatively quick?" (Yes)

3) Do you make daily builds?             

I'd rephrase this:
"Do you make regular builds?"

Also, what are these builds for? I'd add a question
3a) Do you make regular releases? (are they tested?)

An app may build successfully but if loosely coupled may not run ...

4) Do you have a bug database?         

Each project will have an issue tracking system. Once a project is complete this will be archived. The helpdesk then uses 2 apps - one to handle calls the other for bugs. Developers working on a new tranche of a project won't generally have access to the helpdesk bug system. Clearly this is not good enough ...

5) Do you fix bugs before writing new code?     
I'd echo the comments of an earlier poster, bugs are given a priority and worked into project plans etc...

6) Do you have an up-to-date schedule?
7) Do you have a spec?             

Tho the specs tend to be written from the perspective of someone who has worked on a previous implementation of the project, no use to someone who hasn't ...

8) Do programmers have quiet working conditions?
No. Its bloody noisy.

9) Do you use the best tools money can buy?     

I'd rephrase this: "Do you use the most appropriate tool for the work (regardless of cost)?"

10) Do you have testers?             
Yes. See 8. ;)

11) Do new candidates write code during their interview?

12) Do you do hallway usability testing?     

Wednesday, April 23, 2003

For anyone who's curious, CAMEL gets a 3 (source safe, clearquest for bugs, and we have dedicated QA types)


Wednesday, April 23, 2003

Regarding backups:

I understand ZIP drives can be unreliable. I have never had any problems with them, and most important, I never inteded them for long-term back-up. One zip for quick incremental saves (20 times a day), one for daily saves. One CD-rom to rule them all, once a month.

However, now I use two harddisks and I seldom use the ZIPs. The probability that both HDDs will go down at the same time is small. 

Interesting thing, for laptops: I use a compact-flash memory in a PCMCIA slot for backups. I find it quite a nifty sollution since you can easily pop it out and store it somewhere else, so if the laptop is stolen...

And again, cd-rom for frequent incremental backups is not a workable sollution, at least I don't stand it.

Regarding source control: I found it very difficult for the way I use it. I use several computers to program the same code, so I "sychronize" them (for example, synchronize the laptop to the desktop before leaving and so on). Doing this with a CVS in place was much more difficult. But it definitely depends on the kind of software you are writing.

Wednesday, April 23, 2003

When Joel says "Do you use the best tools money can buy?", I think what he's really trying to say is:  Are you saving (easily-measurable) dollars at the cost of (not-easily-measurable) productivity?

Even at a "start-up", the biggest cost is paying for time.  If you are passing up a $500 compiler which would save you an hour a day because you're trying to control costs, you are probably killing yourself.  If a developer costs $50/hr to employ, then in 6 months the $500 compiler saves the company $6000 in developer time.  If the compiler only saves 10 minutes a day, that's still saves $1000.

Does having a second monitor help?  How often do you spend clicking open and closed windows where with another monitor a simple mouse move would work.  Do this 200 times a day at 2 seconds per time, and that's more than an hour of productivity gone.

If you say "my time is free so this doesn't apply", that would imply that you would be equally happy releasing a revenue-generating product tomorrow as 20 years from now.  Is that really true?

Foolish Jordan
Wednesday, April 23, 2003

Synchronizing different places is harder with CVS?  I would think just the opposite.  CVS and other source control systems are designed to make syncrhonization very easy.  All you have to do is check in your changes, and then anywhere you update will have the same version of the files.  Compare this to manually seeing which files are different and copying them over.  Or trying to merge changes by hand if you change the same file on two different computers.  Why do things manually when you can get a free and easy to use tool that automates the process?

A few people touched on the "tools" question.  I think you have a point that a startup is a special case.  The main point is that you have to remember that any time spent using sub-optimal tools is a developer's time you are wasting, and thus a waste of money.  Most tools cost a fraction of the salary of a developer, so minor time savings can be worth quite a lot of money.  To justify a faster computer for builds, you really only need to save a few minutes a day.  Of course, this doesn't apply in quite the same way if you are a startup and aren't actually paying your developer.

Mike McNertney
Wednesday, April 23, 2003

Just a quick moment to gripe: a "documented, easy to follow, relatively quick" build procedure is not equivalent to a "one step" build procedure.  Why on earth would you think that any intermediate steps by a human actor are equivalent to none?

The definition of daily builds could be improved to include builds that happen more than once per day or to distinguish the haphazard build times from a regular build schedule

[In my case, I build the software more than twice per work day, but not at any fixed time]

Wednesday, April 23, 2003


Just a tip on the JoS Forum formatting -- if you want a site (e.g. to be linked, you need the HTTP part.

Compare:  (not linked) (automatically linked)

Joe Grossberg
Wednesday, April 23, 2003

Thanks for the comments! In particular:

Dimitri - yes with startups there is a real temptation to spend lots of money at the start on nice tools etc, in the niave belief that revenue will quickly follow. I've done this myself - now I really really wish I could have back some of the cash I spent inappropriately when starting this business.

Also I do 'version control' and backups in a similar way to you. Basically I save source and docs (unzipped) onto a zip disk, and have a group of disks which rotate off-site so there are always several copies off site. It is almost irrelevant whether Zip disks are 100% or 50% or 90% reliable because there are multiple copies off site. Also I backup particular versions (source and binary) onto their own disks, which are then labeled v1.2.3 or whatever and are kept at the bank and not reused. This is the version control element.

Thanks for your comments on Lingo (I realize the name may be questionable etc etc). I didn't think of writing my build script in it, as the script sort of evolved. The script uses the rundll32 interface for some tasks though, and I haven't put DLL calling facilities into Lingo (it's supposed to be a VHLL)

Simon Lucy - thanks for your comment which sums it up exactly! I use a basic system which combines version control with backups, and allows the backups to be kept off site. Your comments about noise, version control and backups are 100% to the point. They really are.

Everyone else - I agree SCCS is essential for any development team of reasonable size. If:
- more than one developer worked here
- or I needed a better version control system
- or I needed to compare a file to an earlier version of itself
- or someone was paying me to put together a work environment
- or multiple developers needed to access the same file
- or I kept the same files on different computers
- or I had problems tracking down how bugs got into the code
then I would use it. But at the moment none of these apply. I've spent more time over the last 2 days discussing SCCS than I've lost by not using one.

Anyway - does anyone know a nice single user SCCS that runs under Windows ME, has a GUI interface, and does not require command prompts to use it? And that is usable by someone with an IQ of 80 (me after reading the CVS site!)

Thanks everyone!

Bill Rayer
Wednesday, April 23, 2003


Thanks Joe for the comment on linking. I wondered why my original link didn't work. So my link should have been: (surrounded by spaces).

I also felt (slightly) guilty about linking to my site from Joel's software metropolis...

Finally (to stir up the SCCS debate some more) I've found an interesting FAQ at: which I will download and read off-line this evening. In principle I'm 100% with SCCS, but the whole point of this discussion was about using Joel's rules in a money- and time- constrained environment. Stuff has to give, and the question is what.

Bill Rayer
Wednesday, April 23, 2003


Today is St George's day (patron saint of England). Just thought you might like to know that. Also I promise not to follow up any more of my own posts...

Bill Rayer
Wednesday, April 23, 2003

"Just a quick moment to gripe: a "documented, easy to follow, relatively quick" build procedure is not equivalent to a "one step" build procedure.  Why on earth would you think that any intermediate steps by a human actor are equivalent to none?"

Don't think I expressed myself correctly there.

A one step build is obviously better than a multistep build, but if it's not possible (and I don't believe it always is) then it's important to document the procedure (including the prerequisites; operating system, tools, etc, the source build; i.e C++, Java then VB projects, the postbuild steps; i.e. move to test server, run some basic confidence tests, label sourcesafe, move to release area. etc...)

(This also means that *anyone* should be able to take the build
document and produce a release right from using a bare machine.)

The reason I don't believe its possible to do a one step build is that at a very minimum you need to build the software (one step if you're lucky), test it and label sourcesafe (cvs etc.). Thats at least 3 steps. It's possible to automate these 3 steps using a build script, automatic testing etc but then you have a large amount of complexity in your build scripts that they need to have a dev team all to themselves ... ;)

Pete Robinson
Wednesday, April 23, 2003

Bill, the point people were trying to make is source control is not really a reasonable thing to give up.  It doesn't take long to set up and can be gotten for free.  And in the end you spend less time with it than doing the backup solution you currently use, plus you get a number of distinct benefits. 

Based on my experience, you've either been extremely lucky to have not needed it, are misjudging how it could help you, or have had to make yourself be overly careful because of the lack of source control (thus costing you time and effort).  A simple example of the type of thing source control does for me on a pretty regular basis:

1) I fix some bug or add a new feature  in a file and check it in
2) I start working on another bug in the same file and change some parts of the code
3) I realize that the changes I am making won't work out for some reason
4) Revert to repository and get back to step 2 instantly.

Under your method, you'd either have to make backups every time you make a change (which would be stupid, since then you are just implementing your own manual source control instead of using something automated).  Or, you'd have to re-implement your change from step (1).  Or, you'd have to manually undo the changes you attempted to fix the new bug.  I think you can see that none of these options are preferable to being able to do a simple revert operation.

Mike McNertney
Wednesday, April 23, 2003

Bill, you can try Code Co-op from Reliable Software at . It's not expensive and works very well.

Frederik Slijkerman
Wednesday, April 23, 2003


Having built a one-step build process that: labels the source tree, builds the code, and builds the installer, I can safely say that yes, this is possible. It does take SOME effort, but it's completely worth it. You can get away without it on a one man project, but in anything larger, you need one-step builds.

The one step build solves the problem of communicating the build process. Everyone knows it's just "run this batch file/perl script/makefile/whatever." You increase your project's bus number[1]. And you don't have to write lots of docs, because the build system IS the documentation.


[1] The bus number is the number of people who can get hit by a bus before your project is in trouble. If it's 1, your project has trouble already.

Chris Tavares
Wednesday, April 23, 2003

Bill, you really seem determined to not use some sort of SCCS tool.  I can only guess, and I'm not trying to be rude here, that you have never used one for any length of time or you would be sold on the benefits.

I think a SCCS tool will open up new horizons for the way you work.  Its all about having information and power at your finger tips.

You list several things that you don't need, one being 'or I needed to compare a file to an earlier version of itself' which I found really surprising.  Perhaps the reason you think you don't need this is that its currently a non-trivial thing for you to do, i.e. it takes more than about 10 seconds.  Therefore your brain puts a subconscious 'block' up which says "don't bother doing that, its too much of a hassle".

The key is being able to do things like file compares *without* losing your current train of thought.  So you don't lose your 'flow'.

Once you can do things like this with practically *zero* effort then you start finding all sorts of situations where you can use the SCCS tool to give you extra information when solving a problem.  This of course leads to better overall productivity.

There is a wealth of information in your source tree, if you don't have easy access to it you are working with only one eye open.  Its kind of like using the web without Google :-)


Peter McKenzie
Wednesday, April 23, 2003


Love the bus number terminology ...

I'm kind of playing devils advocate here. I do believe a one step build is better than multistep, it's just that I've never seen it! ...

Out of interest, how do you determine the label to use on the source tree? Do you use sourcesafe? (I'm 'refactoring' our build tool and want to add that kind of functionality, ideally the label should read something like xxx release yyy.zzz.www where I update the version using the current value+1 thats used on the source tree, however, sometimes the format may need to change so I may just end up with an input text box..)

Pete Robinson
Wednesday, April 23, 2003

On labelling the build:

Do the simplest thing that could possibly work.

Product version numbers and build numbers are really independent things. Version numbers are pretty much invented by the marketing department.

We used a program called Elphin Stampver to put the build numbers into our exes and dlls. Stampver uses a simple response file with a line in it of the form:

Version a.b.c.d

(Or something like that, it's been a while).

This file was under source control. The a.b.c part was fixed, and didn't change except at the whims of marketing. These were our "major.minor.really minor" version numbers.

The "d" part was our build number. When we did a build, our build script would check out the stampver file (which is just text), run a little jscript program to read and increment the build number. Then we labeled the SourceSafe build as "build number XXX" where XXX was the number from the stampver file.

From there, it's just a script to do a get-by-label and compile.

Internally, we always referred to build numbers; version numbers were for the customers. We had a document somewhere that said "version 1.0 = build 343, version 1.5 = build 654".

Chris Tavares
Wednesday, April 23, 2003

There are very few things that I hold against people. But not using source code control is only them. There is just no excuse.

In my current project, I select our SCC first (before even the language and database engine were selected).

Thursday, April 24, 2003

I disagree with number 9 as well, but probably more in a wording sense than anything.

If it was "Use the best tools for the job that the budget will buy" I couldn't argue with it. I would bet that very few of us actually run a Rolls Royce, which is of course the best car that money can buy. They're not exactly cheap, and not ideal for just popping to the shops either.

Thursday, April 24, 2003


Paul Graham said "The only programmers in a position to see all the differences in power between the various languages are those who understand the most powerful one." This applies to tools and methodologies too.

Many people here are arguing that a single programmer will benefit from source code control. What do they all have in common? Experience on projects where source code control was used.

I would encourage you to climb the learning curve and use SCC for at least one major release. Go the whole way from analysis to development to bug fixing.

If you get back to us and say "I tried it, it didn't help," well, I would buy that you are one of the few exceptions to this ironclad rule.

But I suspect you will be writing a message just like this to someone else who comes along and says "I don't need source control."

I know... I can remember when I was telling someone else that source control was overkill on a project with two programmers... (wistful smile as Reg remembers the good old days when he had more hair and a 16Mhz souped up Macintosh was state of the art)

Reginald Braithwaite-Lee
Thursday, April 24, 2003

Thanks for the feedback everyone. I will take a look at the code coop SCCS. Also one of the PC magazines I saw in the newsagent had a SCCS called Seapine (?) on the cover disk. Has anyone heard of this?

Also I'm not anti SCCS and I agree it's necessary in most situations. In my last proper (ie paid) job, I used CMVC extensively at IBM and wrote rexx scripts to check stuff in/out and to automate builds. There is no way we could have done without it, and I liked CMVC and welcomed its use. I'm familiar with the use and purpose of SCCS.

But now I'm self employed, I know what has saved me time and cost me time. One-step builds saved me a lot of time. I don't see any payoff from installing anything even 1/10 as complex as CMVC. But before we get bogged down I promise:

(i) Reg - as soon as there is more than one developer here I'll argue in favour!

(ii) If anyone knows an easy to use GUI based SCCS that runs OK under Windows (preferably ME) I will try it.

Finally it's interesting Joel's question (1) got the most feedback. No-one picked up on (12) which surprised me.

Bill Rayer
Thursday, April 24, 2003

TortoiseCVS is a nice simple gui interface to CVS
it adds the cvs options to the right mouse click in explorer.
Using CVS has the advantage that as you grow and hire more people you can use more of the features.

For simple projects without branches I still use RCS
In fact I even use it for system admin, I like to do "ci -l" before editing any /etc file.

Martin Beckett
Monday, April 28, 2003

I don't need to do branching and I only need a single installation of the source code control system since I'm the only developer here and that's unlikely to change (except downwards!?). Also I looked at and like the icon :)

Toroitse needs CVSNT (I think) so it won't work under Windows ME. Really I want something about as complicated as winzip to use, that I can install as a single user arrangement, but the SCCS everyone mentioned look pretty complex to me. I don't need levels, releases etc like in CMVC.

Bill Rayer
Monday, April 28, 2003

*  Recent Topics

*  Fog Creek Home