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.

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.

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

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.