Shine Technologies Blog

Some people love it, others hate it - many people just don’t get it. So what is Test Driven Development ?

Wikipedia has a page on it, there are heaps of blogs talking about it and our own Ben Teese has put together a great presentation on how to get started.

Jason Gorman has got a great analogy that helps to make it a bit more real - Test Driven Kitchen Design.

He didn’t invent the phrase “TDD is specification by example”, but it sums things up well.

So what’s in a name … ? Does it matter what you call your chunks of work ?

In many ways it doesn’t - different people use the terms inter-changeably. Sprint is specifically a Scrum term, XP tends to use Iteration, each different Agile approach has different ways of defining and using the terms. However the common ground is that they are regular, repeated timeboxes used to manage the work to be done so that there are regular checkpoints and feedback as part of the project process.

However there are some important differences between the processes of iterating versus incrementing.

Jeff Paton has posted a nice summary of the difference, along with some pictures that help to make it clear:

Iterating: Starting with an idea of what is wanted and refining that idea to get the desired result

Incrementing: Starting with a much more definite understanding and building piece by piece

Both still have the benefit of regular feedback and both can still deliver usable software at the end of the timebox. Incrementing is probably more useful when requirements are more stable or better understood, whilst iterating allows a more agile response to changing or unclear requirements. There’s no reason why a project can’t use both, at different times and for different features - in fact most projects probably should.

So - whatever you call your timebox periods, make sure you understand whether you want to iterate or increment.

If you think you are doing Scrum, how do you know ?

There are lots of good books around, but - whilst Scrum is deliberately quite simple - it can sometimes be easy to lose sight of the principles. Over on the Agile and Business blog Joe Little has posted the test used by Nokia to determine whether a team is using Scrum or not.

I’m happy to say that some of the recent work I have been involved in does quite well on the test, other work not so much …

First came light-weight containers such as Spring which provide some of the useful features of application servers, but with less constraints over both design and deployment. Now we have Web Beans:

1. A Web Bean does not have to be an EJB
2. Web Beans should be executable outside the EE environment

This is further support for the move away from the over-engineered and invasive approach in the original J2EE specification to a simpler POJO based model. However the Web Beans proposal attempts to stay within the formal J2EE fold by choosing to delegate some services to the application server:

” … not every component needs the services that EJB provides (transaction demarcation, authorization, etc). However, Web Beans will not duplicate this functionality, so when these services are needed, the Web Bean should be written as a session bean.”

In contrast, Spring implements some services (such as transaction management) and supports integration with other components to support others - for example Hibernate for persistence, Terracota for clustering - and does not rely on an application server (although it can be deployed within one).

It will be interesting to see where this ends up, and whether Web Beans ends up moving closer to or further away from the model adopted by Spring.

But what about the application server ? Certainly not dead, but perhaps leaner.

Hopefully these POJO based approaches will make design decisions less about the deployment architecture and specification constraints and more about implementing the business logic.

One of the common criticisms levelled at Agile development - particularly by those who haven’t experience it for themselves - is that it is little better than hacking. In particular, that the reduced focus on documentation is evidence that the processes aren’t managed or controlled.

So, for a corporation that has invested significant time and money in process improvement and has reached CMMI level 3 or above surely Agile development is not an option ?

Not according to Mark Paulk who looked at Extreme Programming in the context of CMM(I):

“XP has disciplined processes, and the XP process itself is clearly well defined. We can thus consider CMM and XP complementary.”

So who is Mark Paulk ? He worked at the Software Engineering Institute as leader of development of the CMM for software.

Recently Ben posted an entry and presentation on test driven development. An amusing take on this can be found in The Way of Testivus which provides the wisdom of ancient masters on testing. My personal favourite is:

The pupil asked the master programmer:
“When can I stop writing tests?”
The master answered:
“When you stop writing code.”
The pupil asked:
“When do I stop writing code?”
The master answered:
“When you become a manager.”
The pupil trembled and asked:
“When do I become a manager?”
The master answered:
“When you stop writing tests.”
The pupil rushed to write some tests. He left skid marks.

Mark raised some very good points in his comment against my recent post on welcoming change in projects:

“One main barrier to these approaches being adopted in the past was the engagement/contract models that our clients dictated. If the project needs a fixed cost, you usually need a fixed set of requirements.”

So what to do ? Does this mean that an Agile approach can’t be used ?

Much of what makes up Agile development is simply sound development practices, but what specifically could we take from the Agile philosophy for use in a fixed price contract ?

Let’s look at a typical situation we encounter - responding to an RFP or other tender. The client has provided some overview of the goals, objectives and requirements, a target completion date and wants a fixed price quote.

1) Respond to the RFP in the best way that you can
You need to make (and document) assumptions, try and fill in the gaps, use your experience - anything you can do to improve your information. And you need to estimate the work. There are no silver bullets here, with Agile or anything else, you just have to do the best that you can. However, if you’re used to working Agile you’ll be used to identifying requirements and putting together good estimates fairly quickly - treat is just like a normal planning session (someone will have to pretend to be the customer !).

2) Plan to deliver business benefit early
This is core to an Agile approach in any case - “early and continuous delivery of valuable software” - but it also means that if something surfaces during the project that significantly affects your original estimates you’re in a better bargaining position. A client is much less likely to be concerned about a suggestion to drop some of the minor functionality if they can see a working solution that already implements their most important requirements.

3) Promote your Agile approach as a benefit as part of the proposal (and put your money where your mouth is)
The use of Agile processes is now widespread, almost mainstream, so is something that can add value to your proposal. Even if your client isn’t really aware of what Agile processes are all about tell them what you are offering - choice. The ability for them - the client - to have control over the process and end it at the end of the next iteration if they’re not happy. Or maybe even if they are - because they might by that stage have what they need to achieve the business benefits they are after.

4) Do the job better
In the worst case - even if the client is not interested in Agile processes or iterative development - you can still benefit from those processes as an external vendor / supplier. If your development processes are more efficient and more effective then you are going to be more competitive at proposal time, as well as more likely to deliver on time, on budget and to meet (or exceed) your client’s expectations.

As Mark also points out in his comment - things work better when you have “trusted partnering relationships where both parties are working for mutual benefit”. Or - as the Agile Manifesto puts it -”Customer collaboration over contract negotiation”.

The more you can demonstrate delivery of business value, the more you can develop trust. On the other hand, if you need to rely on the wording of a contract to protect your position then the project is already in trouble.

My last post on Agile software development ended on one of the Agile Manifesto key principles - “Welcome changing requirements, even late in development.”

But surely that leads to chaos - how can we possibly build something if we’ve got a moving target ? It must make more sense to gather all the requirements from all the stakeholders, lock them down and then make sure we deliver …

Let’s explore that thought for a moment. It is conventional wisdom that defects are more expensive to fix the later thay are discovered. Requirements are gathered at the start so changing them down stream will be expensive - the further down stream the more expensive.

But what are the costs of not allowing requirements to change ? Even if the solution is delivered on time, on budget and meeting all requirements, research has shown that more than 60% of the functionality is rarely if ever used and only about 20% is used often. Why is this …

1. The requirements change: Business moves on, and the longer the project the more things change
2. People’s understanding of the requirements change: People aren’t very good at predicting what they want
3. People make up requirements: “This is my only chance so I’d better ask for everything I could possibly want”

But what if there was a way to change things ? What if a change to requirements could be made without the expense, or maybe even to save costs or increase benefits ?

The full principle from the manifesto is “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

Change happens. Projects are about making change. We can treat changes within our projects as an impediment that needs to be constrained or removed, or we can harness it.

For those techno-geeks who are interested in encryption - I mean in how it actually works, not just how we can use it - take a look at some interesting work being done in the States on using thermal noise for key exchange. It has many of the expected benefits of Quantum cryptography, including protection from man in the middle attacks - but is based on much simpler technology and appears to be getting better results.

(You might have some trouble getting to the site - it appears to have been slashdotted …)

The Software Patent Arms Race has been building slowly over the past decade, as more and more organisations build their patent portfolios in reaction to the broken software patent process, threats from patent trolls and as a defence against other organisations with patent portfolios. The threat of mutually assured destruction - “if you sue me I’ll sue you back” - has thus far largely resulted in compromise cross-licensing deals where organisations agree to license each other’s patents.

However there have been moves more recently by Microsoft to un-settle the balance, largely it would seem in response to the growth of Linux and the threat that has to Microsoft’s Windows operating system.

It started when Microsoft claimed that Linux included code which violated over 200 of Microsoft’s own patents, along with strong suggestion that customers running Linux could well be liable for those violations. This threat was intended to force Linux distributors to pay licence fees to Microsoft or risk losing their customers - who would leave Linux to avoid being sued. Apart from one deal with Novell this approach did not get many results for Microsoft and they appear to have now upped the ante.

Could Microsoft be seriously considering suing Fortune 500 companies for patent violations in Linux ? Given that most of those companies are also major Microsoft clients ?

Linus doesn’t seem to think so …