Thursday, January 27, 2005

Software process costs and savings

I want you to think about a development project and consider two scenarios. Imagine each of these scenarios represent a different set of practices you use to develop the solution.

In the first scenario you develop a solution for your customer and it takes time t to produce the solution. The solution you deliver has x bugs and y security issues. This solution costs you $m.

In the second scenario you develop the same solution for your customer and it takes time t+s. This solution has x-a bugs and y-b security features. This solution costs you $m+n.

The values of s, a, b and n are critical for you to decide which scenario you use.
The question in your mind should be; is the extra cost and time of fixing x-a bugs and y-b security issues worth more or less than $n in s time.

Now here is an interesting thing to consider. How do you budget for your software development project? Is it:
i) from the beginning of the project until you ship the code (bugs and all), or
ii) from the beginning of the project till that code is decommissioned and never is run again?

Think about what you are doing when you budget for software using the first option. You are actively encouraging poor quality. If the cost of fixing issues is not taken into account in the development budget then why spend time and money worrying about it?
The only sensible answer is to use the second option to budget for software development. So why don’t companies do that? Maybe you should suggest your company does!

Now what would happen if I told you that I could show you some practices that help you obtain the following values in your variables for the second scenario.
s tends towards 0 (or even a negative number)
a tends towards x
b tends towards y
n tends towards 0

How much will you pay for those practices? Write a check to Dr. Neil and send it to me now!

Now which scenario do you chose?

What if I give you a list of practices to choose from and tell you that with each of these practices you implement you will get:
s closer to 0 (or even into the negative)
a closer to x
b closer to y
n closer towards 0

You want to see the list?
Ok here it is (in no particular order):
Test driven Development
Pair Programming
Automating the build-test-deploy process
Breaking the solution down to tasks that each take less than 4 hours to complete
Small iterations – ship early – ship often

Does this list look familiar?
Good – so you know where to get started.
Of course if you are developing in .NET the best resource to learn the practices in the list is eXtreme .NET.

Thursday, January 20, 2005

PayPal introduces AUD payments

Now that PayPal supports the Aussie dollar I have changed my site so that you can buy a copy of eXtreme .NET in Australia and pay for it using the local currency.
Last August (2004) I presented MapPoint WebServices at the conference for the Geospatial Information & Technology Association (GITA). They must of liked the presentation because I received this award today!

Thursday, January 13, 2005

I just bought myself this new monitor and as I have long suspected screens are the wrong way around. It is so much easier working in portrait than landscape. Does anyone know why screens are usually in landscape?

Tuesday, January 11, 2005

eXtreme .NET Tech Breakfast

At the end of this month I will be hosting an SSW Tech Breakfast. The topic will of course be eXtreme .NET: introducing eXtreme Programming practices to .NET Developers.
It is on 28th January 2005 - 8.00am - 11.00am in Neutral Bay. Sydney.
If you are based in Sydney come along, it will be fun and there will be plenty of coding examples. Plus I'm sure I can find a copy of the book (or two) to give away.

Monday, January 10, 2005

Recommended Reading List

I have just posted the list of recommended books from the appendix of my eXtreme .NET book on to my web site.
Are there any books you think should go here?

Thursday, January 06, 2005 raves about SMSUtils

Gears at has put together a great piece on my SMSUtils.
Thanks Gears.

Tuesday, January 04, 2005

Dr. Neil's Smartphone Toolkit

All these public holidays do have an upside. I get to work on my own fun projects :)
At the end of the day yesterday I released new versions of
Dr. Neil's SMS Utils and the SmartSMS Dev Kit.
These are projects that have slipped back due to 'real work' pressures. I am pleased to get them out there.

Monday, January 03, 2005

Developers Dilemma – Rewrite vs. rework part 3

If you were following this post then you might be wondering whatever happened. I started blogging about this issue and then went quiet. Well the main thing that happened was that blogging didn’t seem important. Funny how that happens when you get stuck into a project ;)
So on the second day I wrote a bunch of tests and fixed a load of issues with the device driver. That allowed me to move forward on the third day with starting to add new features to the device driver. In fact by the end of that day (it was a long day) I had driven (through tests) the development of all the new features required at the device driver level.
It became clear the following day that a couple of the other components presented different ways of communicating with the device driver. I am sure there is a Pattern for this. These components were easy to add tests to and most of the code called simply performs some data translation and then calls the device driver. The way these components worked drove the creation of some extra tests back in the device driver. It is always good to see how a component is being used :)
Finally the rest of the components presented the UI for controlling the device (the one that the driver talks to). These UI components communicate with the components that communicate with the device driver. On Friday I got to add the new features to the UI components and the project is pretty much finished. The UI has very little logic to it (which is great and as it should be!)
The answer in this case seems to be very much biased in favour of reworking and driving the work through the tests. I was surprised how quickly progress accelerated once a number of core tests were in place. Once again the process of driving development through tests proves its worth and makes me realize how powerful this technique is.