Fog Creek Software
Discussion Board




The Joel Test The missing item

Went through the Joel test recently.

IMHO Felt it missed one important point - Configuration management using a tool like Ghost.

Important that all your programmers and testers can go onto to a identical platform easily.

If one of the libraries or tools you are using comes out with a new version easy to roll out a new configuration which is identical for all your programmers.

If an older version of your software has a bug, if you archive the configuration images you can roll back to try to replicate it.

As important if not more important that one click build

Govindkrishna
Monday, March 03, 2003

You have a point, but isn't it already covered by the 2 items as described in http://www.joelonsoftware.com/articles/fog0000000043.html ?
1) source control
2) daily one-step build

If you can do 2) from 1) on a clean machine, that should mean the necessary configuration is versioned in your SCM tools.

What exactly is missing in your view concerning confirguration management?

R Chevallier
Monday, March 03, 2003

Because neither of those points actually cover a development workstation, just a build workstation.

Tis actually a good point. Setting up a developer workstation sucks.

flamebait sr.
Monday, March 03, 2003

As Ged Byrne reminded me on some other topic, increased indentation doesn't help for clarity of reading, neither does threading.

Threading would just encourage the 'me too!' 'no that's crap' gazillion posts of /..  Sometimes I might get ever so mildly chafed that someone has said something I was thinking of saying but theirs was better but either I think of something different to say (or at least oblique), or I don't bother.

Given the frequency of posts statistics, many may feel I should choose the latter option more often.

There is another way you can comment to a particular statement, if you want to agree with someone or congratulate them or something.  You could email them.

Occasionally that's happened to me and that's always pleasant.

Simon Lucy
Monday, March 03, 2003

That was bizarre, I commented to the wrong topic :-), those with sufficient energy may guess which is the right one.  I'm not going to repost it.

Simon Lucy
Monday, March 03, 2003

flamebait got what i was trying to say.

Suppose a new developer joins your team or an existing developers hard disk crashes or a virus sweeps through your network.

Setting up each developer workstation should not take more than 15 - 30 min each.

Even though the source code may be under source code control, setting up the correct development environment with all tools configured, third party libraries installed etc. typically takes a day or two unless you have a SCM process in place.

Govindkrishna
Monday, March 03, 2003

That is a truly EXCELLANT point, and I myself would very much like to know how to do it properly - just for not quite the same reason.

Mainly from learning how I would do something similar with my own home machines. I'd love to be able to format at the drop of a hat or setup a new computer/hard drive whenever I pleased, but don't even know where to start. I figure I could learn quite a many principles from Workstation Management to apply there.

Then again it may be trivially simple, but it would still make at least a great dedicated article detailing exactly the sort of things Joel does and would reccommend - or wants to do, anyway.

Brian Hall
Monday, March 03, 2003

I think the real challenge in setting up any dev environment is just like creating a Web site--it's one thing to set it up the way you want it the first time, it's a pain in the @ss to maintain it! What happens when you decide to go to a different IDE? Do you have someone in charge of updating your setup scripts? Do they get anything besides the back of your hand when things don't go right?

I worked my butt off at one startup to get our devs setup and configured, wrote dev standards docs, scripts, set up internal Web pages with FAQs and howtos. It was hard work, but (I think) valuable to the team.

doug

P.S. Joel sure can rite goode, eh?

Doug Schwartz
Monday, March 03, 2003

Don't forget to manage the tools used to build your product just like you do the source itself. Otherwise, three years later, you may be left trying to remember which particular compiler patch-level was able to build version 0.9b of your product...

ret4rd
Tuesday, March 04, 2003

I've had my development PC throw up with a hardware failure twice in my time here, both times that have required either a new hard drive or a complete reformat of drive C:

I keep a list of everything I need to install to get my development environment up to speed, and hand it over to the IT team. Then, if they need to do a rebuild, I can be confident I can start coding right away without having to fiddle about with dependencies.

I don't think they use any management tools other than a database with everyone's requirements on it though. Would be interesting to see if it makes a difference if they did, though.

Better than being unemployed...
Tuesday, March 04, 2003

At the last place I worked, every developer workstation had two drives, C: and D:.  C: contained ONLY the operating system and OS-related files.  You kept all your applications and work files on your D: drive.

The techs always kept a few PCs (with Windows and all related patches loaded on the C: drive) handy.  If anything went seriously wrong with a developers' PC, a tech would calmly wheel over a new PC, pull out your D: drive, and slot it into the new PC.  You were back up and running before the end of the day.

You still may have had to re-install a few things, but in general, it was a beautiful way to work.

I can also see tweaking that so that all important and standard developer applications -- IDE, CVS client, etc. -- are pre-installed on C:.  If you want to use your own tools, that's fine, but in case of a crash you at least have crucial tools available.

Brent P. Newhall
Tuesday, March 04, 2003

Brian,

Have a look at Symantec's product called Norton Ghost or a product called winhex (search for it on google). I am sure there are other similar tools. They are known as disk cloning tools. This is what people like Compaq, Dell etc use to shorten the installation process.

We do something similar to what Brent describes but a little more sophisticated.

We have three flavours of partition images (created using Ghost) for simplicity lets call them A (testers), B(programmers), C (documentation team) etc.  these have  the OS, the dev tools, all the required software, third party controls, standard (mostly freeware) utilities preinstalled. (Each image has a different set of programs installed). This is done on a 6GB bootable partition and the OS installed from a dump on this partition itself and all hardware drivers for all possible combinations of machines that are required.  (Why is this important? - if the image is created with hardware x and restored on an hardware y, Windows will autodetect and reconfigure itself - well almost always)

This is the bootable partition. The other partition /second hard drive is where you are supposed to store all your data.

So if your disk goes down or gets virus infested etc. You just tell the system people I want image B (or whatever) installed on my C Drive. This typically takes 15 min.  You are back up and running.

After that you are on your own for installing whatever you want.

Supposing there is a new version of a third party tool released which needs to be updated on image B. Image B is archived and a new image B with the new version of the third party tool is created. You test that this new image is not breaking your build on one machine.
Then everybody with image B gets their C Drive overwritten with the new image.

If at any time you want the old image because you think there are bugs which depend on the old image. Just restore it.

OK creating image A, B and C and keeping them archived is the key and it is not an easy task. You need to keep a lot of intermediate images etc. Needs planning but can be done.

For a home machine it is even better. My brother is a doctor, but he fools around a lot with his computer. I introduced him to Ghost and he loves it.
You keep a good image, install whatever you want - if it breaks your system just rollback to the good image. If you like what you installed - rollback to the image,  reinstall, take a new image. Great when you try to install new hardware on your own etc.

OK once you start doing this the productivity gains are tremendous.

That is why I feel this should be number 13 on the joel test.  It meets the criterial that you can only answer yes or no and here is the text explaining how it is useful.

Wonder if fog creek software would answer Yes or no on this one <g>

Govindkrishna
Tuesday, March 04, 2003

Govind, If it works for you just add it to your list.

Prakash S
Tuesday, March 04, 2003

Prakash,
Well yeah, I do use this. So I get one point for it on the "Krishna Test" <g>.
Though Joel has nicely branded it as The Joel Test I see those twelve points as  "battle tested" "must use" "best practices" for a software product development firm.
I feel that he missed this one and i am sharing this with other people - thats all

Govindkrishna
Wednesday, March 05, 2003

*  Recent Topics

*  Fog Creek Home