Well its about time I did my first posting of the year and continue my review of Joel on Software.

I hope one and all have had a good new year and I wish you all the best in 2006.

So Where Have I got to with this book, well last week being a slow week as always getting back to work I took the longest route to work giving me more time to read :-).

So my review of this wonderful book continues.

Chapters 5 -8 Cover much of what I wrote in my posting of November 29th (What's a Functional Spec). So on to the other Chapters:

• Painless Software Schedules
• Daily Builds Are You Friend
• Hard-Assed Bug Fixin'
• Five Worlds
• Paper Prototyping
• Don't Let Architecture Astronauts Scare You
• Fire and Motion
• Craftsmanship
• Three Wrong Ideas from Computer Sciences
• Biculturalism
• Get Crash Reports From Users-Automatically!

So Basically I've finished part one of his books which he calls "Bits and Bytes: The Practice of Programming" The next section which I have started on is for Managing Developers and has some very interesting Ideas which I will follow up on in a blog this week.

As there are eleven chapters to cover here (Most of which I will have forgotten now I will give a brief on each of them and the thoughts I had after reading them. So here goes:

Painless Software Schedules

Joel buts this very simple in deed, he has 13 main areas and it all comes down to Keep it simple, Features have many tasks, only the developers who is going to write the code can schedule the code this basically means that the times it takes one developer to create something is different to the time it takes another, I have first hand knowledge of this where I've made a software schedule to how long it will take me to do it all and then the project has slipped because the time it takes me is different to another developers big mistake. You should fine grain each task, this means a tasks should last hours and not days meaning that you can keep an eye of where you are more accurately. Keep and eye on the original and current estimates, this allows you to judge how far out you where in your estimates and a good way to learn, very much the same as extreme Programming teaches.

One point he does bring up and I know always gets left out of our projects is Holidays (Vacations) and this can impact a project a lot. If you can get your developers to commit when they are taking time out at the start all the better but of course if the project is a year one or 6 / 3 months you could have an average of holidays taken into account. Another point that gets left out of schedules is debugging but with CF you tend to debug as you go but can be useful to have a big debug session. As well as debugging time you need integration time to make sure all parts of the project fit together for example you may have some one working on the XML feed in and other on the XML feed out one on the database procedures, the GUI etc so you need time to make sure all this works together through out the project. You need buffers as well things will always over run so why not just add that time in at the start and one of the big points he makes is Never let a manager tell you to reduce the estimate it just won't work that why. As he says its like putting wooden bricks into a box either you have to put less bricks in or you need a bigger box which can be related to Features and Time. Either reduce features or increase time that is the only trades you have and stick to your guns for a happier life :-p

Daily Builds Are You Friend

We do try to make daily builds to ensure that everything is working together but may not always happen so can be a few days before we do one which can cause issues. As code written a few days ago is not as fresh in the mind as code written this morning if there is an issue. Also daily builds should be easy to write for example a batch file that gets files from Source Safe, Label Source Safe places all the file sin the correct place and then runs all the Unit tests you have. This is one area we do lack on and is something I will be looking into once I've finished this book :-)

Hard-Assed Bug Fixin'

Bug fixin comes down to the fact what type of bug is it, is it a Cosmetic Bug, Trivial or a Show stopper. Of course you will fix show stoppers but is it financially viable to fix the cosmetic bugs? will it bring you a return etc. Of course on in-house projects they don't count, as there is only so much budget available, on externals they may. Not all bugs need to be fixed as the cost to fix them out weight the benefits returned.

Five Worlds

This chapters gives us an overview of each of the 5 types of software that developers create these are:

1. Shrink-wrap
2. Internal
3. Embedded
4. Games
5. Throwaway

Joel goes on to give info on each of these and does give you a lot of food for thought.

Paper Prototyping

I think we all do this, we have a scrap of paper and we write out what we think we need and how we should plan it. One good point he makes that if its on paper the user won't think we are nearly finished i.e. you show a HTML mock up they will say oh your not far from finished then and we all know there is a lot of backend work to do so paper is good.

Don't Let Architecture Astronauts Scare You

This chapters describes people we all know people who take an idea so far it's just never going to happen let them get on with it and not bother you is the bases of this chapter :-)

Fire and Motion

This chapter really does describe me on someday, You just don't get the fire in your belly to get going. It reminds me of a part of a Time Management Course I went on where you have two types of people a Morning person who will get in and get going straight away and burn out during the afternoon or an afternoon person who wastes a morning but gets going in the afternoon. I think most people will see themselves or someone they work with in this chapter.

Craftsmanship

This chapter covers what programming is? Can it be a Craftsmanship? Yes and No is what I go from this chapter but you should decided for your self

Three Wrong Ideas from Computer Sciences

Well not being a person who has done Computer Sciences I can't really comment on this chapter but did give me some good thoughts but again I feel you should make your own up as any comments here will be from someone with no knowledge of the subject.

Biculturalism

This chapters goes in to the details of Windows and Unix programming an of being from a windows only background it gave me a lot of insight into UNIX programming and maybe even the fire I need to go have a look into Linux at least as I can't afford a Unix setup at home lol but here's hoping :-p.

Get Crash Reports From Users-Automatically!