PM#, Project Management

PM#7 – High workload means lower productivity…

1 Comment

My friends and colleagues over on the SellingAgile group were discussing productivity recently. Tony and Clarke were at the heart of the discussion, it went a little like this:

Tony made an excellent post, too long to quote here, but I particularly liked this:

In the age of interaction-centric systems, it’s all about speed. Forgo the false god of utilization. Concentrate on speed and concentrate capacity, so that those valuable software products and the mountain of moola that each of them can bring might arrive today rather than tomorrow.

To which Clarke asked:

Are you saying that if everyone is busy all the time then they will actually be a slower at doing things?

To which Tony responded:

Yes, Clarke, if we ensure that we have active projects enough to guarantee that every developer has project work available, then we _CAUSE_ the whole system of resources to work at approximately half its sustainable speed. Management teams worldwide are wasting approximately half of the capacity of their development teams and, consequently, half of their development payrolls.

It became clear that some folks believed productivity is low because we’re overloaded with work.

Basically, this boils down to the fact that software developers (amongst others) rely on creativity in order to do their jobs well. Without suitable periods of “down-time”, work simply moves from one task to the next with little regard for “can this be done any better?”

Tony then went on to make this remarkable statement:

Think of multiple marathon relay races. We have one team and many marathon relay races for the team to run. If we schedule the races so that one race must end before the next race can start, then our team doesn’t get to finish very many races per day or per week or per year. So we surely want the races to overlap. But for each of our runners we absolutely do not want his/her segments across races to overlap. That would force the runner to jump from track to track and race to race without handing any baton to a downstream teammate. So, we overlap the races, but we don’t overlap any one runner’s segments across races.

Today, due to our unfortunate and grossly inadequate understanding of interaction-centric systems, we schedule the STARTS of our races far too closely to each other. This guarantees that every one of our runners is always on some one track or another, running at least one race and usually several races simultaneously. Then we require our runners to make progress simultaneously on all their active races, by failing to prioritize the races. This forces each runner to hop from track to track and from race to race repeatedly, before the baton of any one race is transferred to the next teammate. This is multitasking in all its ugliness.

Clearly multitasking is absurd in the context of relay races. But it is no less absurd in the context of product development. Yet this absurd behavior is precisely what we cause when we strive to maximize utilization. The resulting lack of performance is a tragedy of our own making.

Whilst folks think that having a steady stream of work is good, it seems that we worry about a number of things:

  • that we won’t have time to complete the current task (and do it well)
  • that we won’t have time to complete the next task
  • this appears to be a recursive worry

So, my take on this discussion resulted in this:

  1. Start something.
  2. Focus on it using decent chunks of time.
  3. Do it well.
  4. Finish it.
  5. Don’t allow yourself to be distracted by “what’s coming next”. Don’t flutter from one task to the next and back again.

Leaving an activity in an unfinished state will cause further distraction as your mind will play tricks with you, you’ll be worried about the unfinished tasks whilst you are working on current tasks. Break your tasks down into manageable chunks (task time average = 30 minutes), proceed to start each task and finish it, allow yourself some downtime (if you refer to it as slack, it’ll be consumed by the project, avoid using the word slack). Doing less work should will actually make you more productive.

Related to this:
How much pressure is required to make somebody more productive?

In this series:
PM#11 – Management By Shouting Loudest (MSBL)
PM#10 – The truth is best…admit it…
PM#9 – Avoid duplication of effort
PM#8 – Multi-tasking is evil
PM#7 – High workload means lower productivity…
PM#6 – You were right and I was wrong
PM#5 – Whose schedule is it anyway?
PM#4 – Start it…finish it
PM#3 – Use e-mail properly
PM#2 – Focus on the project
PM#1 – decision making

PM#, Project Management

PM#6 – You were right and I was wrong

2 Comments

If you make a mistake, I’d like to think you would be man enough to admit it.

The trouble is, and I’ve seen this in so many places, there are a lot of folks out there who seem to be unable to admit that they made a mistake. I’m sure that we’re all guilty of covering up a the odd faux pas here and there, but there are folks out there who take the cover up to new [stellar] levels. These stellar levels include such things as poor decisions or incorrect decisions (more here) and choices that have led to projects going off on a tangent for months on end all because of parochial approaches that prevent acceptance of the bigger picture (i.e. focusing on one small part of the project without understanding the project as a whole).

Saving face is not all that important, doing the right thing is. In a project-based environment, saving face for long periods is detrimental [to the project]. When driving, if you accidentally take a left instead of a right, you will endeavour to correct the mistake as soon as possible…you shrug your shoulders and get on with the course correction. Please take this analogy to your current and future projects: if you make a mistake, your cheeks go red, you blush, whatever, please raise your hand and announce your mistake. Team members will thank you for it, the project will run smoother and will stand “one more” chance of coming in on time and/or on budget.

Whatever you do, don’t try to ignore the mistake, cover it up or keep running with the mistake as if it were normality. And accept that team members might point out the mistake and ask you to do something about it: don’t fob them off with pithy excuses whilst you insist that you are right and they are wrong. Project rarely have “get out of jail free” cards, if you think you’ve got one please be aware that the card expires very very quickly after use: expect to be found out. Long running cover ups or long running changes in direction are catastrophic for the project and the team member morale. Do not think of yourself, think of the project and the team members (learn from what Derek Laud had to say about a lack of selfishness) – it’s not your project, it belongs to the team and the end users.

Don’t ever be afraid to say: “you were right and I was wrong”, it’s the best thing for you, the project and the team members. And say it as early as possible (mistakes and oversights are typically cheaper to fix earlier in a project).

In this series:
PM#11 – Management By Shouting Loudest (MSBL)
PM#10 – The truth is best…admit it…
PM#9 – Avoid duplication of effort
PM#8 – Multi-tasking is evil
PM#7 – High workload means lower productivity…
PM#6 – You were right and I was wrong
PM#5 – Whose schedule is it anyway?
PM#4 – Start it…finish it
PM#3 – Use e-mail properly
PM#2 – Focus on the project
PM#1 – decision making

Project Management, TDD

David Anderson interviewed by Robert Scoble

Channel 9 do a good job of getting life inside Microsoft presented to the outside world…here’s another fine example.

David Anderson, who has previously spoken at Agile Scotland meetings, was quizzed by Robert Scoble about “Agile Management and what we are doing with MSF for CMMI Process Improvement”.

Download and watch the video here.

The interview was littered with good advice, but I homed in on a couple:

developers don’t like two things

  1. interfering management, i.e. micro-management
  2. management not doing something when something abnormal happens

“Incremental development (Ed.with regard to TDD) only works when refactoring is part of the equation”, Ron Jefferies

It’s well worth the download, do take the time to watch it. Clarke sums David’s style up rather well: “David has a nice way of simplifying complex things”

Rants

Shopping for an MP3 player…

I’ve been introducing the in-laws to “Internet shopping”.

I struggled to explain this one to them:

mp3 players

“£29.99, you say, nice price, fully featured, state-of-the-art, tell me more.”

Clicking on the first link took us here:

mp3 player

And the second link took us here:

mp3 player

Two totally different prices, nothing like “Our price: £29.99” at all.

Granted, these prices are a little more realistic…

General, Project Management

Derek leaves the Big Brother house…

Derek Laud, was evicted from Channel 4’s Big Brother reality TV programme on Friday. What he had to say once he left the house was somewhat inspiring, and he said it with considerable eloquence, grace and civility.

First and foremost:

…team effort is absolutely everything..and that’s fundamentally what works

Unfortunately, I’m not sure his housemates really grasped that concept on the whole (irony accepted). Team effort is everything: in a group of 10 or more people, it’s not worth being the only person, or the only two people trying to do all the work. Delegation is part of the game, but so it responsibility – it’s no use just sitting watching one or two people trying to do all the work, chip in a help them (especially if they ask you to!)

“team effort” == community.

Followed closely by:

it’s a lack of selfishness that’s very very important in life

The World doesn’t revolve around you. If you didn’t do your job, it wouldn’t be the end of the World. It’s not about “me me me” [cf].

I found this quote interesting and somewhat close to home:

other people are much better about making their problems seem more important than anybody else’s

Me me me. My problems are more important than yours ,listen to me, let me talk your ears off. Yes, a lack of selfishness is important, but so is taking your turn. Everybody has their problems, we just have to prioritise the solutions by importance and need.

And to finish:

listen more, talk less

Feedback is important, there’s little point soliciting feedback if you don’t listen to it and act upon it. Similarly, there’s little point in a one-sided conversation (which by its very nature is at least a two-way thing). And if team members bring problems to your attention, they’re doing it for a good reason, be sure you listen to them and act upon them.

Politics aside, a combination of Derek and Boris Johnson would revive the Tory party, perhaps? Just a thought.

Rants

National Lottery…

I don’t know what’s more annoying, the National Lottery site going down just after I click submit whilst buying the office syndicate’s tickets or the fact that they’ve got a happy smiley face highlighting a little anticipation of it coming back up…

…I certainly won’t have a happy smiley face if the tickets weren’t bought: I’ll probably be lynched.

But anyway, rant, rant, etc. Can you believe that they’ve actually put a Trademark on the “site down” message?

lottery down

General

Hillwalk – Ben Lawers

Last month saw a few of us climb Ben Lawers, amongst other associated peaks.

Apart from the fun element, this was Scottish Developers way of showing appreciation for the sterling presentation Dr.Neil gave the group the day before.

Here’s the Google Earth image, tilted to show terrain:

Ben Lawers via Google Earth
Google Earth shows off the terrain rather well

hillwalk
Craig admires the view. CodeZone caps get everywhere!

hillwalk
That loch in the background is Loch a’Chait

hillwalk
Dr.Neil, myself, Dave, and James

hillwalk
Dave, James and Barry – posing for the camera just before Craig decides to “leg it” with Barry’s camera…3000 feet up and in the middle of nowhere!

hillwalk
Dr.Neil, Dave and myself at the top of An Stuc

hillwalk
A triumphant Barry reaches the top of Meall Greigh

Thanks to James and Barry for the photographs!

General, Rants

Security hype “stifling new technologies”

2 Comments

It seems that security concerns are preventing us making progress. Robert Jaques has an interesting piece in the September 2005 issue of PCW (UK). Yes, I know August has just descended upon us, however PCW does seem to be published some two months ahead of the actual month it represents!

Whilst the rest of the world are making progress with IP telephony/VOIP and wireless networking and wireless hotspots, etc. it would appear that there are some folks who are thwarting progress by following the maxim “if it ain’t broke, don’t fix it”. Well, in this situation, that maxim doesn’t hold true. For example, I’ve just returned from Microsoft TechEd in Amsterdam, where Microsoft was kind enough to provide [potentially] 6,500 of us with wireless access to the Internet. It was a remarkably liberating experience. I was able to check my e-mail whilst attending sessions, blog “live”, provide session feedback within minutes of the session finishing, etc. It was truly amazing.

How did we ever live without wireless? I can’t imagine the Internet without it now, never mind the connectivity gains that I’ve acquired after pushing the wired LAN into the dark and distant past (OK, so I’ve a wireless ‘bridge converting the wireless into wired for use in the study…it still means that I don’t have wires running all over the house, much to my wife’s delight!)

Life without wireless/VOIP might not be secure according to the hype mongers; however, can we believe them? True, wireless networks do open themselves up to a wider range of potential attacker – the attack surface extends itself to the far reaches of the wireless broadcast. And yes, early wireless kit was delivered (out of the box) with all the security options turned off or disabled…but I seem to recall that some operating systems were delivered in a similar fashion. Nowadays of course, virtually all wireless kit (and the aforementioned operating systems too) arrive with all the security bells and whistles enabled so much so it’s sometimes difficult to miss. With a little care, it is possible to secure a wireless network and/or VOIP such that there is considerable business benefit.

Life without wireless/VOIP means a mess of cables. It means a laptop, a rucksack and a bag full of various network cables and adaptors – I carry five RJ45 cables of various lengths and an RJ45-to-RJ45 extender that allows me to daisy-chain two RJ45 cables together if required. I didn’t carry such excess baggage to Microsoft TechEd…the only wires I saw there were those leading to from laptops to power sockets and from the VOIP handsets to the controlling PC.

Life without wireless/VOIP means having to find landlines or worse, mobile ‘phones. It means having to stretch a fixed line ‘phone across tables/desks to get it close to your laptop which is plugged in to the network and the mains – and because neither the network provider or the electrician spoke to each other, they both kept their infrastructure as far apart as possible. If you’re lucky enough to have a network provider and an electrician who speak the same language, the floor sockets that house their respective outlets/sockets, and this is especially true of electrical outlets, are sunk into the floor, hidden underneath a tightly fitting lid that soon comes away in your hand the minute you lift it open. And if that wasn’t bad enough, you try to plug your laptop’s power adaptor in, oh, the huge transformer prevents you from plugging it in…or, worse, you have a regular-sized plug fitted with a less than flexible cable…the power outlet’s live/neutral plugs so close to the edge of the housing that you can’t even bend the cable to fit.

And just think of the triangulation involved in plugging a laptop into the mains at point A, the telephone at point B and the network at point C. The resulting mesh is a potential safety hazard.

Just in case you had forgotten what life without wireless looks like, here’s a very tame reminder:

not wireless

PM#, Project Management

PM#5 – Whose schedule is it anyway?

6 Comments

There was an interesting discussion entitled “is it just me?” over here at Scottish Developers. My reply is here. Anyway, it preempted this posting in some respects, but I’m going to carry on with this post regardless!

Customers and management never seem to believe the estimates developers give them…time and time again, developers provide an estimate of how long a project (or task) might take, e.g. 12 weeks, only to be told (by the customer/management) that it will take 6 weeks. There are many reasons for this sudden shortening of the schedule…many of which revolve around the fact that the customer/management have promised their upstream customer/management something (a software solution) by a given date. An unrealistic date at that.

Who is more qualified to make schedule decisions that relate to software development? Is it the person whose job it is to actually “cut the code” (the most important part of any software project, no code, no project), is it the person who actually does the job or is it the person who has promised a piece of software to their upper management by a certain date?

Despite any potential previous bad experiences, customers and management should learn to trust developers more, they are the most experienced resource management tool a software project will ever see. They have excellent gut reactions, they know when something is “do-able” or not. They can reliably tell you whether something requires 4 hours or 4 weeks to complete. They know their business, inside out.

So why is there such disrespect for developers and the work they do? Why do I hear lots of sob stories revolving around late delivery, “he said it would take 4 days, it took 12 days, his estimates are rubbish”?

The simple answer is this: unless the part of the schedule that a developer is working toward actually belongs to him, realistically speaking, the developer knows he’ll not be able to meet the schedule but will carry on regardless. He has nothing vested in an arbitrary schedule that does not give him enough time to to his job properly. True, the developers will probably bust-a-gut trying to bring the project in on time, however as we know, invariably they’ll fail. But it’s not their fault. It’s the fault of the person who gave them the wildly inaccurate schedule in the first place.

Even if the schedule was remotely accurate and did have input from the developers, other folks exhibit a disturbing lack of respect for the developer and the schedule. A schedule can often be agreed provided that all or some tasks are distraction-free: this is easy to agree at the outset, but rarely happens during the project execution. Similarly, a fully-committed developer has no “resource gap” or free-time, there is no “contingency” in most projects. Therefore, you cannot duly expect to either e-mail or walk up to a developer and ask them to take on other tasks (for other projects) that aren’t part of the schedule…and since developers (and a lot of other good folks) find saying “no” difficult, they can often be [bullied] into saying “yes” to more work that will invariably knock the previously agreed schedule out. The trick here is not to offer developers other work – no matter how important it is to you (your top priority work isn’t going to be the developers top priority, he’s busy focusing on the project.)

Getting schedule buy-in from the developers is key – give developers the chance to form and shape their own schedule, let them break tasks up into smaller more manageable chunks that can be delivered over shorter periods of time, e.g. every 30 days or less. Don’t force them to buy-in to a [rolling] project plan that spans 6+ months – the speed at which the software business moves at, 6 months is far to far away: focus on what can be achieved now rather than later. Developers also need an endorphin hit every so often (cited as being every 2 weeks) – they get endorphin hits by starting and finishing a task, by seeing a piece of their code [go into production] in front of a user/customer or by visibly moving the project forward in some respect.

Analogy
When you last had you car serviced, you probably gave it to the garage for a whole day. I don’t hear about folks telling the folks who work in garages: “You need my car all day? No, you can have it for 3 hours. Can you get everything that needs doing done in 3 hours?” I’d like to see the state of your car once you get it back…may be not today, but in a few weeks time when you thought all that work had been done…

Example
I have a standalone application – a single .exe that runs on a per-machine basis. A client has requested that we “get it to work over the network”. For us, this is a big job, it requires changes to the backend database to allow the introduction of a user column (at least), transaction support, improved backup/restore, etc. To the client, networking an application is the simple matter of adding a login box at the start of the application. Since that’s all the client ultimately gets to see…”how can that possibly take N weeks to write?!” Perception and explanation are key. As developers we must learn to stand up for ourselves and learn to say “no” to unrealistic schedules: whoever is asking you to commit to such a schedule doesn’t understand how their car works, yet you won’t find them telling the garage to cut their schedule in half…unless they are themselves a mechanical engineer (versus a fitter), in which case they would need to be experienced software engineers in order to discuss schedules with you!

Need to cut the schedule? Well, why not cut the feature set?
If you have a pressing need to cut the schedule, at least negotiate with the developers over the feature-set that your hoping they’ll implement in the shorter time-frame. We know that “80% of a product’s value comes from 20% of its features” (originally from here), surely you can afford to cut the number of features in order to cut the schedule? Of course, now we’re in the realms of controlling the four success variables (cost, time, scope, and quality).

four variables

In the first instance the customer is allowed to select values for any three of these variables. The development team will then choose the value for the remaining forth variable. Ultimately, between the customer and development team there will be a series of compromises and trade-offs resulting in an adjusted set of values, or even trading of variables!

There are interactions between the variables. For example, increasing the time can allow for an increase in quality and/or an increase in scope. Another example might be a reduction in scope: it is possible to deliver earlier (less time) or cheaper (less cost) or possibly with more quality.

It is worth noting that the relationship between the four variables is a complicated one – it is not possible to reduce the time variable simply by increasing the cost variable. Nor is it possible to increase the cost expecting an increase in quality.

Crazy Schedules
Schedule pressure often sees shortcuts (or what are perceived as shortcuts) being taken. Instead of well-structured, reliable object-oriented code, being cut produced, prototypes are built as proof of concept…a little cut’n’paste then follows, prototype code suddenly becomes production code but only after crazy amounts of testing and re-work. It’s a spiral that requires a step back and a re-write to get out of, and may be more than one re-write at that. Crazy schedules will cost you considerable amounts of time and money downstream, they’ll also cost you the respect of your developers too.

Scott Berkun wrote an excellent book, The Art of Project Management, reviewed here, where he cites an example: your client in on the operating theatre table, the brain surgeon tells him that the operation he requires will take 12 hours…you won’t find your client turning to the surgeon and saying “no, you have 6 hours”…This just wouldn’t happen, I rest my case: if programmers or developers tell you something will take 12 hours, give them 12 hours (or more if you’re generous), it’ll protect your reputation, they’ll respect you for it and it’ll give your project more chance of success.

In this series:
PM#11 – Management By Shouting Loudest (MSBL)
PM#10 – The truth is best…admit it…
PM#9 – Avoid duplication of effort
PM#8 – Multi-tasking is evil
PM#7 – High workload means lower productivity…
PM#6 – You were right and I was wrong
PM#5 – Whose schedule is it anyway?
PM#4 – Start it…finish it
PM#3 – Use e-mail properly
PM#2 – Focus on the project
PM#1 – decision making

PM#, Project Management

PM#4 – Start it…finish it

8 Comments

As Dr.Neil Roodyn says, keep your task duration/time down to a 30 minute average (which means your tasks can be anything from 5 minutes to 120 minutes in length, it’s the average we’re interested in).

Just as important as the task duration, is the need to ensure that a task can be both started and finished. Long-running tasks do nothing for a person’s (read: developer) motivation and desire to focus on the project in hand. There’s little point asking a person to do any more if their in-basket/work-basket is already overloaded with tasks that have been started, but not finished.

I call this role Starter-Finisher, Dr. Meredith Belbin calls it Completer-Finisher. Either way, the job needs doing; starting can be easy, which is perhaps why Belbin believes the role should focus towards the end of the task, i.e. the finish or completion.

Completed/Finished tasks elicit feedback, feedback drives quality, quality drives customer satisfaction and customer satisfaction drives profit.

So, the simple statement that this post is trying to make: if you start something, finish it. Don’t let anybody distract you whilst you are completing (working on) the task, try and set aside a suitable chunk of time that is free from interruptions. Remember, the shorter the duration [of the task] the more accurate your estimate of time to complete it going to be. If you have to, break longer tasks, e.g. longer than 2 hours, into smaller more manageable tasks. Of course, you may need to remind folks that it is your schedule, not theirs, and that contrary to common belief you won’t drop everything to work on their problem.

In this series:
PM#11 – Management By Shouting Loudest (MSBL)
PM#10 – The truth is best…admit it…
PM#9 – Avoid duplication of effort
PM#8 – Multi-tasking is evil
PM#7 – High workload means lower productivity…
PM#6 – You were right and I was wrong
PM#5 – Whose schedule is it anyway?
PM#4 – Start it…finish it
PM#3 – Use e-mail properly
PM#2 – Focus on the project
PM#1 – decision making

Developer Events

Scottish Developers – eXtreme.NET

4 Comments

Dr.Neil Roodyn came to a sunny Edinburgh to talk to Scottish Developers about eXtreme.NET. Dr.Neil was presenting at a half-day mini-conference; the other session was by Christian Weyer whose slides are available here.

curse
Christian curses that Java compiler!

As the other speaker noted, Dr. Neil spent some 2 hours and 15 minutes talking about writing code…without actually writing any code at all. But that was the intention, and it made for a thoroughly excellent presentation. And it was nearly a full-house, there were only a handful of empty seats.

crowd shot
Nearly a full house!

Dr.Neil kicked off the session with a look at XP’s four values: Communication, Simplicity, Feedback and Courage. He went on to note that respect starts at the top [of the management tree] and goes all the way down to the developers/workers and the customer. Respect is lost when the project manager/client asks developers to do something in an unreasonable time-frame.

The first of many quotes:

Anybody, including a lone developer, is part of a team if they are working on software for a client.

When comparing the traditional cost of change curve for a software project, Dr.Neil makes a potentially emotive statement:

As a system grows, it should not be exponentially costly to make changes.

In other words, the cost of change curve shouldn’t be a curve at all, it should be a straight line that very gradually rises over the course of the project (image to follow)

Audience Poll
Dr.Neil’s quick poll of the audience revealed an interesting statistic. Two questions were asked: 1) who knows .net? and 2) who uses .net? More hands went up for question 2 than did for question 1. I suppose nobody wants to be seen as “knowing .net”, “in its entirety?” Perhaps for fear that Dr.Neil was going to pick on whoever claimed to “know all of .net”…fear not, this would not have been the case, it was merely a poll.

.net, call it what you want, a technology, a platform, a framework, Dr.Neil simply describes it as “cool”, and rightly so. He is using it to help him and his customers deliver high quality business-focused systems within a short delivery time-frame. Dr.Neil knows of a customer with some 85,000 [NUnit] tests, with a 5-day bug fix period and no bug-tracking database (more about this in a moment). The said customer operates on the premise that [the XP] values come first, they throw away anything that degrades those values.

Thinking out of focus
When a new project comes along, the thought process often looks like this:

  • Choose the Technology and the toys (e.g. .net, web services)
  • Choose the Process, Practices and Methodologies
  • Choose the People

This is, in fact, the wrong way around. We should choose the people first, then the process, then the technology. We should drop the heavy focus on writing masses of project documentations (consider the value it adds). Dr.Neil made good use of a car dealer analogy to get this point over: when buying a new car, the deal says to you “the car’s not ready yet, but here’s the manual.” You’d far rather he said: “the car is ready, but the manual needs some work…it’ll be ready next week.” Instead, the focus should be on “better product, better code”. It should be easy to install (this is the first point at which the user experiences your software, make it an easy and memorable one!), it should have features and functions the users wants and needs, it should ship with the most business value , it should have high quality (i.e. repeatedly works) and it should be upgradeable (i.e. we can add features after the fact, at low cost and with ease).

Bugs reproduce – throw away your bug-tracking database
Bugs that live in a bug-tracking database simply attract more bugs – if you have a database/place to put bugs, every developer will start populating the database with bugs they have found; even the customer will get involved. Bug-tracking databases are simply repositories where folks will “submit’n’forget”, i.e. once a bug’s in the database, it is unlikely to see much resolution activity…

Typically our bug databases see bugs being prioritised in some way. Unfortunately, most developers (myself included at times) procrastinate – as such, we find ourselves taking the easy lower priority items out of the bug-tracking database and we fix those. Lower priority items tend to be lower in business value…even if you take a handful of them together, their value isn’t a much as a single high priority item. Hence Dr.Neil suggests that we dispense with a bug-tracking database and simply fix bugs as they are found, i.e. we have no known bugs in our software.

Mentioned of “broken window syndrome” was made – one broken window attracts another: the only solution is to not have broken windows, i.e. keep things in good condition. Replace “broken window” with bug, and “keep things in good condition” with “fix bugs as they are found” and you’ll see where this is going!

Why do software projects fail?
65-85% of software projects fail. Granted, fail is perhaps extreme, but take it to mean any number of things including: fail, crash, bug-ridden, under-used, fully-featured where 80% of the features aren’t used, and so on… In contrast to the aircraft industry, where failures do exist but are trapped and handled much better, the software industry seems to accept that it produces stuff that fails. Why is this?

A quick audience poll and subsequent discussion resulted in the following answers:

  • politics
  • pitch/price low just to get the job (the value comes via requests for change…expensive changes too)
  • someone else’s budget (not my problem)
  • choice of language
  • choice of technology
  • the decision to use complex patterns (that we don’t actually need)
  • the decision to use specific practices (that are outdated or are not suitable for this project)
  • we make our software more complex that it needs to be (to make “us” look smart and/or to justify high salaries). We do make our software more complex than it need be, citing excuses like “it’ll save us time later if we do…”. Project complexity is seen as a get out clause, a get out of jail card: “it was a tough project, no wonder it failed”. I have refrained from using such language on this blog so far, but get out of jail cards are another form of arse covering – such things should not be tolerated on a project. Although, quite where the high salaries are…I might need to do some more research…

Kent Beck: “Comments in code means you’re not finished.”

Principles
Dr.Neil went on to explain some principles that help create great software (and bring projects in on time!):

  • rapid feedback.
  • assume simplicity. Aim for a “task time” of about 30 minutes (avg), this may mean some items that are 5 minutes, others that are 30 minutes. Note that estimate accuracy increases as task time reduces. Try and achieve a project with >90% of it being small tasks and <10% large tasks that require more effort. The small tasks will provide the sense of achievement and the endorphins that developers long for.
  • incremental changes. Big changes don’t work, there is too much disruption and they are typically too hard to understand (even by those so-called high-salaried folkes!)
  • quality. There are only two choices: excellent and outstanding.
  • teach learning. Learnt something new? Spend 20 minutes teaching it to your co-workers via a “nugget”, a webcast or a blogcast.
  • small initial investment. Put a little bit in, get a lot out. Don’t work long hours, don’t work harder rather than smarter.
  • play to win. Build yourself a track record of winning, ship software frequently.
  • experiment. Use XP’s spikes for what they are good at: if you can’t estimate a task, perform a spike. Limit your spikes to 4 hours.
  • honesty & openness.
  • go with instincts. We should learn from this – developers who have been on many projects in the past bring with them a lot of good experience – typically they’ll be the first to say “that’ll never work” or “we need 12 weeks, not 6 weeks”. Listen to them. They know their stuff, don’t insult them by offering them 6 weeks, you’ll just lose any respect that you had from them if you do.
  • shared responsibilities.
  • adaptability.
  • leave baggage behind.
  • realistic measurements.

The Team(s) must be aligned, it’s the only way to move the project through to completion. Dr. Neil Roodyn, Edinburgh, July 21st 2005

Another quote that just makes perfect sense:

a piece of functionality is not complete unless it is being used by a customer

Four key stages
We noted that there were four stages involved in delivering a great piece of software:

  1. Coding. Without code, there is no program
  2. Testing. Without test results, you know nothing “trust nothing until it is proven”
  3. Listening. Developers are dumb, most of the time they don’t understand “the business” and they write code that other developers don’t understand.
  4. Designing. Organise and plan for enough flexibility, keep it simple, logical modules, organise code, prepare to re-design

Dr.Neil noted that his studies show that most bugs are “created” by programmers after 6pm. Tired programmers create bugs. Don’t be too surprised, if you are lucky enough to be working with Dr.Neil, to find that he’ll kick you out at 6pm…go home, have a life.

Test-Driven Development (TDD)
On the subject of Test-Driven Development (TDD), Dr.Neil reminded us:

  • that TDD is a design exercise
  • that it makes us write the least code and the most simple code
  • that it makes us consider interfaces and design
  • it puts quality first, not functionality (this is most important)
  • writing tests for third party components is a good thing
  • a green “screen” or bar means you can potentially ship your product, you have something shippable

tdd - the red screen
Dr.Neil ponders over the red screen, indicating test failure (luckily, he forced the test failure for demo purposes!)

…And Finally…
This was a throughly excellent session, if you weren’t there you missed something special. If you get the chance to be present at one of Dr.Neil’s presentations, pull out all the stops to be there.

Links
Dr.Neil’s tools, links and presentation relating to this posting can be found here.

Colin provides a similar write-up here. And there’s more over here.

Craig Murphy: author, blogger, community evangelist, developer, speaker, runner