Now this is so cool - I want one.
Philips unrolls 'paper' display
Thursday, March 03, 2005
Chandu Thota's WebLog - MapPoint Team is hiring
Chandu has asked me to let you know that the MapPoint team is expanding and looking for some talented people. You can find all about the postions by clicking through on Chandu Thota's WebLog
Good luck!
Good luck!
Thursday, February 17, 2005
eXtreme .NET Day
In partnership with the MSDN Connection program and dotNET Solutions I am doing a series of one day events around Australia next month.
The eXtreme .NET Day event should be a lot of fun and I am sure everyone who comes will learn something.
There will PCs so we can do hands-on exercises throughtout the day and build some cool code using the lessons we learn.
If you've not yet booked your place you better hurry up. Places are going fast with Canberra already sold out.
The eXtreme .NET Day event should be a lot of fun and I am sure everyone who comes will learn something.
There will PCs so we can do hands-on exercises throughtout the day and build some cool code using the lessons we learn.
If you've not yet booked your place you better hurry up. Places are going fast with Canberra already sold out.
Thursday, February 03, 2005
See me at the Security Summit?
Lots of people have been emailing and asking if I will be at the Microsoft Security Summit events that are occurring around Australia this month. I am afraid not. I will be presenting at the Microsoft Windows Anywhere event in San Francisco.
I would recommend you go to the security summit even though I won’t be there in person. :) It looks like they have some very interesting material to cover and it’s a great chance to brush up on skills while networking with peers.
I would recommend you go to the security summit even though I won’t be there in person. :) It looks like they have some very interesting material to cover and it’s a great chance to brush up on skills while networking with peers.
Tuesday, February 01, 2005
Carl Franklin praises eXtreme .NET
Listen to what Carl Franklin of Franklins.NET and the .NET Rocks Show has to say on eXtreme .NET.
Download the full show here or the clip of Carl talking about eXtreme .NET here.
Download the full show here or the clip of Carl talking about eXtreme .NET here.
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
Refactoring
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.
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
Refactoring
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.
Thursday, January 13, 2005
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.
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?
Are there any books you think should go here?
Thursday, January 06, 2005
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.
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.
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.
Tuesday, December 28, 2004
Developers Dilemma – Rewrite vs. rework part 2
Today I started working on one of the components. This components is the one that already had some tests. The component is a device driver (written in C!) and it is the component that I mentioned yesterday already having some tests.
Within the first hour of adding some extra tests I found a couple of bugs that had not been reported. I suspect that these bugs have never been seen because the driver is never used the way it is in the tests I have written.
Is there any point in writing these tests then?
I think so. Firstly there is nothing stopping another developer from writing another component that uses this driver that way. That developer will get somewhat annoyed when they find out the driver is misbehaving. Secondly, based on my current understanding of the expected new functionality to be added later in the project, that other developer will quite likely be me.
After fixing the broken tests I continued adding a few more tests, finding bugs and fixing tests. That has been my day. I am happy because the driver (while not finished) is now a lot closer to ‘zero defect’ than it was when the day started.
I have a suspicion that tomorrow might be a similar day, I’ll let you know…
Within the first hour of adding some extra tests I found a couple of bugs that had not been reported. I suspect that these bugs have never been seen because the driver is never used the way it is in the tests I have written.
Is there any point in writing these tests then?
I think so. Firstly there is nothing stopping another developer from writing another component that uses this driver that way. That developer will get somewhat annoyed when they find out the driver is misbehaving. Secondly, based on my current understanding of the expected new functionality to be added later in the project, that other developer will quite likely be me.
After fixing the broken tests I continued adding a few more tests, finding bugs and fixing tests. That has been my day. I am happy because the driver (while not finished) is now a lot closer to ‘zero defect’ than it was when the day started.
I have a suspicion that tomorrow might be a similar day, I’ll let you know…
Monday, December 27, 2004
Developers Dilemma – Rewrite vs. rework
I’m just embarking on a new project today and looking through the existing code base. One of the components has some unit tests, which made me smile. None of the other components (about 8 in total) have any tests :(
This suite of components was written in a short time frame over a year ago and it works perfectly for the job that was required then. In fact it has been in use by (so I am told) several thousand users around the world for the last year. Of course there have been a few issues reported but no show stoppers. In many ways I have to say "good job" to the original development team.
The issue now is that the suite of components needs to extend its functionality further to cater for some technology changes and to open up new opportunities.
So the classic dilemma; do I rewrite the parts that need changing (in a test driven manner of course) OR do I rework the existing components and add tests as I go?
I don’t want to rewrite code that is working and has been field tested. I also don’t feel comfortable adding to code that doesn’t have unit tests. Without unit tests for the existing code I won’t know if I’ve broken any of the current functionality through the changes I am making.
To be continued …
This suite of components was written in a short time frame over a year ago and it works perfectly for the job that was required then. In fact it has been in use by (so I am told) several thousand users around the world for the last year. Of course there have been a few issues reported but no show stoppers. In many ways I have to say "good job" to the original development team.
The issue now is that the suite of components needs to extend its functionality further to cater for some technology changes and to open up new opportunities.
So the classic dilemma; do I rewrite the parts that need changing (in a test driven manner of course) OR do I rework the existing components and add tests as I go?
I don’t want to rewrite code that is working and has been field tested. I also don’t feel comfortable adding to code that doesn’t have unit tests. Without unit tests for the existing code I won’t know if I’ve broken any of the current functionality through the changes I am making.
To be continued …
Friday, December 24, 2004
New MSN Messenger Beta
I have been playing with the new MSN Messenger Beta. I like it a lot. Some neat new features.
Tuesday, December 21, 2004
Monday, December 20, 2004
The Brits are getting worried and rightly so
I saw this report in The Register today:'World's Biggest Luddite' heads for the UK. At least they know what's coming!
Subscribe to:
Posts (Atom)
