The SquizLogKeith Pitty takes a squiz at the world. |
|
The SquizLogKeith Pitty takes a squiz at the world. |
|
So estimating is sometimes necessary. David Pinn, Frank Carver and "Open source reader" said so in response to my previous post about Tom Looy's suggestion that we should stop estimating.
As Frank pointed out, there are situations where estimates are needed for practical reasons like the need to coordinate other resources. As David pointed out, the challenge is at the sales end: it is the customer who demands to know when the project will be finished and how much it will cost.
Unfortunately, as well-known Australian project management consultant Rob Thomsett describes, what results is often not honest estimating but estimation games. Have a read. You should recognise a few.
Again, credit to Tom, who in an earlier post provided a link to Rob's article.
In my humble opinion, successful software development projects rely on relationships that are based on trust and honesty. That involves being up front, accepting that estimation is not an exact science and being prepared to adapt plans as a project progresses. Playing games is not part of that vision.
Accurately estimating software development projects is hard. Original estimates are notoriously bad.
Tom Looy takes this industry experience, turns it on its head and implores us to stop estimating. That's right. No more requests for estimates of how much effort left for a particular task. No more "90% complete" answers. If we're so bad at estimating why waste our time on it? It's a fair question.
Instead, Tom advises us to measure our progress. And by that he means in terms of completed tasks. Critically, he stresses the need to start measuring progress early in the project. As he says, and as I've seen far too frequently, often no assessment of completed tasks is done until it is too late to adapt the plan. Without stealing all of Tom's thunder, here are his key suggestions:
I agree whole-heartedly with Tom's excellent article. He presents a realistic approach based on experience and common sense.
It is also an approach that I think would significantly reduce stress in the software development workplace. Stress is so often caused by an unwillingness to accept reality. So let's adopt a realistic approach and get on with the business of developing software that benefits people in both the customer and provider organisations!
Reflecting upon Tom's words I find myself pondering the following challenges:
Two or three years ago TheServerSide was the site to monitor if one wanted to stay abreast of developments in the Enterprise Java world. And it's still useful.
But a new site to watch is InfoQ, which markets itself as tracking change and innovation in the enterprise software development community. Floyd Marinescu, the original force behind TheServerSide, is one of the editors at InfoQ.
Java, .NET, SOA and Agile communities are all part of InfoQ. And of particular interest to me is the Ruby community, for which Obie Fernandez is the editor. I recently listened to a podcast in which Obie talked about some very interesting DSL stuff he has been doing with Ruby.
Definitely one to watch.
Eleven work days to go.
After some estimating was done some weeks ago, work has been progressing, albeit somewhat interrupted and uncoordinated, towards a promised delivery date.
Of course I'll do my best to contribute to a successful outcome. But how will I react to the schedule pressure? Time will tell. It will depend on others as well as me.
In the end, to preserve my sanity, I may need to relax and listen.
Today at lunch time I had the opportunity to share my Ruby on Rails experience with my colleagues at work (a J2EE consultancy). The talk seemed to be well received although I could have gone on for much longer.
Anyway, I appreciated the chance to explain what I've been playing with on the train for the last few months and to share some of my enthusiasm for the Rails framework. Hopefully it was thought-provoking too.
The slides are available in HTML and Open Office format.
Jazz in the Sydney CBD? 
Where does one go to find it?
There was a time when I could reliably go to The Basement and know that I would find excellent Australian jazz. Back in the days when the Galapagos Duck was at their peak. The Basement is still where it used to be at 29 Reiby Place but jazz no longer features on their gig guide. A quick look at their list for this month shows only one or two gigs that could be described as jazz.
So where are the good jazz haunts in the Sydney CBD these days? Or at least not too far from the CBD? Google doesn't reveal much.
A friend recommended Wine Banq - their gigs for this month look promising - but I suspect an expensive meal would accompany one's enjoyment of the music.
What I'm looking for is somewhere to have an inexpensive meal, catch up with friends and listen to some good jazz. Something like the Soup Plus used to offer. I know they had problems with their new venue; something like their old haunt would be fine in my humble opinion.
Any suggestions?
I've just spent the best part of today fixing a software bug that shouldn't have seen the light of day.
The fact that it did was due to another developer's decision to do some "refactoring". Notice that I put the term refactoring in inverted commas. Why? It all has to do with the definition of refactoring, which is to improve the design of existing code whilst preserving its behaviour. To put it another way, make the code better internally without altering its external function.
And, as I have asked my students in the past, how do we ensure that the software still functions the same way externally? We test, of course, don't we? Sure. We test before and after to make sure it all still works. All still works? How can we be sure that we test all the scenarios that could be impacted by the code changes we are making? Think about it. Unless we're careful things can rapidly get out of hand.
A couple of things are very important here. One is the ease of testing enough relevant scenarios quickly. Another is the risk of making too many changes before testing all our scenarios again. This is where automated testing really comes into its own. If we are disciplined, we will continuously extend a suite of automated tests that provide reasonable coverage of the scenarios. We will build up suites of automated unit tests, integration tests and functional tests. And we will pay particular attention to automating tests of the user interface or, at the very least, tests of an interface very close to the user interface.
Now, what has the preceding couple of paragraphs got to do with the bug that I fixed today? Notice that I used the word disciplined. I think that is a very important word in the context of developing software. It is so, so easy to develop without the discipline required to ensure that software does not decline into a state of disorder. The discipline required to ensure that when we, with the best of intentions, change the internal design of our software we do not introduce bugs that displease the customer.
I am reminded of a task that I completed in my first job out of university. This was back in the early 1980s when, having learnt Pascal and UNIX at university, my first programming job introduced me to the wonderful world of IBM compatible mainframes - a world of PL/I, CICS, IMS DB and JCL. Even in those distant days the importance of regression testing was recognised by some. One of my tasks was to develop and document a regression test suite for a revenue accounting application. I was very proud of the result and naive enough to think that I had made a worthwhile contribution. What transpired? Nobody used the regression test suite. Nobody! I guess that would have taken too much discipline.
Maybe I'm being unrealistic in expecting software professionals to test professionally. Maybe I'm wrong and it is all too hard and too time consuming. Maybe I should go with the flow more and accept the work practice which says: "Does it compile? Yes? Then let's ship it!"
Or maybe I've just had a bad week. It's Friday evening and time to test a beer or several.