Blog entries from November, 2003

For a while now I’ve been thinking that, at work, we are trying to find solutions to our problems without first defining the problem, working out what is needed to solve the problem, and then looking for solutions that do what we need. The need to find the box before you can make something fit the box.

What I have just realised is that the Thomsett training gives ammunition to push us onto the right track, left bubble and right bubble. Thomsett states that you must think about the project management issues (left bubble) such as requirements, scope and objectives before you start thinking about technical solutions (right bubble).

I’m nearing the end of Accidental Empires: How the Boys of Silicon Valley Make Their Millions, Battle Foreign Competition, and Still Can’t Get a Date by Robert X. Cringely. This was one of the books I bought in one of my recent splurges at Amazon, mainly because of what I remember about the tv specials Triumph of the Nerds and Nerds 2.0.1: A Brief History of the Internet.

There is a lot of history about the development of the personal computer that I was previously unaware of and it is interesting to note that it appears that failures were often due to poor management/marketing/timing/etc rather than deficiencies in the technology…

I also got around to watching Pirates of Silicon Valley.

Today was my final day going through the three day Thomsett Project Management: Essential Techniques workshop at work. I’m still digesting it – as a tech I’m not going to be applying Thomsett on a wide scale – but I did have the following thoughts:

• Almost all of the team has done the course so why don’t we appear to be using any of it?
• It brings up some questions reagarding the structure of our team. The client relations team is really anything that isn’t code, ie helpdesk, interfaces, testing, marketing, project management, etc. Doesn’t really fit with Thomsett’s seperation of management (left bubble) and tech issues (right bubble).
• During the course I recalled that Mythical Man Month, Pragmatic Programmer and Peopleware all talk about some of the Thomsett concepts.
• Mostly it just makes common sense. So why don’t we do it?

Earlier this week I finished reading XP Refactored and one of the final comments was about how Kent Beck said that Extreme Programming is about turning all the dials, on various development practices, to 10. The comment in question (I can’t seem to find it now) said something about how anyone who has a sound system at home knows what happens when you turn everything up to full…

The relevant point I am now getting around to making is regarding the Thomsett success sliders; aspects of the project (client satisfaction, objectives, budget, on time, add value, quality, team satisfaction) are assigned a value that indicates how flexible they are. ie if the slider is fully on for time then it must meet whatever deadline, but it the slider for budget is half off then there is a fair amount of flexibility there. The important thing is that no two sliders can be on the same value (regular spacing from off to on) because you can’t have everything fully on. This concept replaces the old theory of you can have any two of quality, time or budget.

The point I’m still trying to make is that XP says everthing should be on. As other people’s experience is telling us, that will not just work…

I’m applying for a full-time position, I’m currently casual, at work and part of the application process is an online pre-interview questionnaire which I have just finished submitting. One of the quetions was Describe any one aspect of Extreme Programming that excites/intrigues you, and why. (hint: google for it)

I wrote up a, what I thought was good, response that talked about how XP takes a subset of the software development practices and combines them into a self referential loop in order to totally ignore other established practices. See the Circle of Snakes in XP Refactored.

However that was not the response I submitted as I didn’t think that an XP critical response would not be taken very well… The response I did submit was regarding coding standards and how they were beneficial, in particular that they are not tied to XP…

I’m a few chapters into Extreme Programming Refactored and it is very interesting. Significantly the breakdown of how XP goes wrong and the background of where XP came from…

Last night I got around to start reading Peopleware, like Mythical Man Month this book is about the management of software engineering projects, in particular the management of productive teams.

So far there has been a fair amount of discussion related to environments that are conducive to the Mental State Called Flow.

Following that was a signifigant discourse on Methodology (capital M), it was interesting to see comments made about how blindly following the Methodology is often a more effective way for workers to get what they want from management as opposed to a strike or stop work action.