The four major practices of SoftOptions

These are the 4 main, customer visible, things that make SoftOptions different.

1. The Planning Game.

We deliver in cycles. A cycle typically lasts two weeks, and starts with the "Planning Game".

The Planning Game is a meeting (possibly virtual) where the content of the next cycle is agreed. We will prepare by reviewing all stories (user requirements) to confirm its price. You will prepare by ensuring every story is up to date and reflects current thinking.

During the meeting we select enough work to fill the available resources for the next two weeks. We also ask that you indicate which delivery or phase (group of cycles) you may want each story built in. This is for planning purposes only and you are free to change your mind.

2. "Continuous" delivery

SoftOptions requires that every change is integrated and tested within the full system as soon as possible. And I do mean within hours not weeks. This means that we have to be able to repeat all tests on your system in a few minutes. I will come to how we do that in a minute.

By insisting on this early integration and full regression testing, we ensure that almost no bugs are introduced into the code. The few that slip past the programmer tests are are soon spotted and removed by the integration testing. The current integration build is delivered to the customer every two weeks.

Although we cannot require the client to use it every two weeks, doing so has some advantages for him.

A minor upgrade is easy to handle from the training point of view - just send a memo.

Using code is the only way to discover where design choices are weak. Using it immediately is a great way to find out how to make it better while the programmers are still about and know the code.

Using the code early helps to start the pay back period early, which improves ROI.

3. Automated testing

We create tests that can be run by program (and thus very fast), to test all parts of the software. These tests are repeated after every change. Even where the tests take longer - say 30 minutes - these are repeated every day.

We write the tests before the code, so we actually are using test driven development! We create an automatic test that will show if part of a user requirement is not met, then run the tests to prove it fails, showing us not only is the requirement not met, the test does actually get run, and probably tests the right thing. Then we alter the code to add the feature, and re-run all the tests. If all passes then we know we have built the feature and not upset anything else.

By creating a test before every alteration to the code, we ensure very high test coverage.

By repeating the tests after every change, we catch problems in their infancy, and never allow a bug to live.

We can also simplify the code without changing behaviour and prove we have not broken anything!

As you can see, the client does not have to provide any tests. However, if a requirement is expressed as tests - and they often are - then we will use those tests to ensure we have built what is required correctly.

4. User requirements as Stories.

All user requirements are expressed as stories of the "right size". A good story is small enough for one person to comprehend and program in under a week, not worth splitting over two deliveries, yet large enough to be worth the overhead of costing and pricing it up separately.

The client will say how important a story is (vital, important, minor), and the developer who is costing it will say how confident they are in their price. This confidence can be guess, estimate or quote. Unless it is a quote he will also add questions, the answers to which would enable him to firm up on the cost. These answers can be provided at any time, but note that a story cannot normally be selected for inclusion in a cycle until it has been quoted fixed price.

The client can change any story at any time, until it is selected for inclusion in the next cycle. It will be completed and delivered within two weeks, so there is seldom need to change it later than this. Any change may alter the price, but we make no charges for these revisions. Indeed, I feel that building the right software is so important I encourage revisions.

Development of software is often a process where the client and supplier explore the solution space with each other. With traditional methods this is difficult because any change immediately asks the question "who made the mistake?" in order to determine who pays. We can simply get the software right without such a question arising. We avoid any temptation to "account so we can blame" which saves a lot of effort (cost) and makes the work more pleasant.

The 8 minor practices of SoftOptions

These 8 practises support the first 4, patch up some of their weaknesses, and build on their strengths. It is the whole package that is so strong.

5. The Metaphor.

I have mentioned that we accept changes to requirements, free of charge, right up to the last moment - the planning meeting where it is selected for the next delivery. Clearly this helps us build the right things first. This is fine, but it leaves a gap. There is nothing to say if a given idea is part of this development, or outside its scope.

Another difficulty is keeping a common style for the user interface. It can be hard to coordinate the different parts of the design and ensure things are of a common style. The traditional approach has been a big design document that tries to answer every question in advance - dot all the "i"s and cross all the "t"s.

This freezes the design before the requirements are fully understood, makes change hard and costly. Such design documents are often wrong, boring to read, of little help to the programmer. They cost a lot to maintain. If not maintained they cause errors, which is even more costly. What a massive waste of resources!

In its place we have a simple 2 or 3 page scoping document we call the metaphor document. This is written in the client's language, in general enough terms that it is easy to maintain. This gives the general thrust, and scope of the project. It contains just enough style detail to to coordinate everyone's ideas.

We do not need more. Indeed any more reduces our flexibility in the face of the inevitable changes.

6. Collective code ownership.

We avoid the situation where some area of code is "owned" by one person. Any programming pair (see later) can and should change any code anywhere at any time.

This has two obvious effects, and one less obvious one - we are never held up waiting for Jim to come back off holiday, and knowledge of the code spreads through all staff very quickly. Less obvious is that the author will know that others will be looking at and changing his code very soon. So if it is not well written and clear he will get complaints very quickly. This keeps people on their toes.

7. Customer on the team.

It sounds like great marketing hype to say the customer is a part of the team, doesn't it? We mean that the client must nominate a representative, who will attend daily (virtual) team meetings, will answer email quickly. He is able to make decisions for the client without always referring back to the organisation and the organisation trusts his judgement enough to accept the decisions made. He must know how to take other decisions back to the organisation and get a decision made fast. Finally he must know which actions to take for most issues.

This is a demanding role, not an easy one, and it can be hard to fill.

The customer representative, as we call him, needs to be committed to getting good value for money and delivering something of value each cycle.

So, far from being great marketing hype, this is actually a challenge to any client. Can he find the right person to fulfill this role? Without the input a client representative provides, the project will stumble and stall. Getting the right person is vital to the project's success.

8. 40 hour week

Programming is hard. It needs fresh minds. This practice is not that we never work any overtime, but rather that we view the need to work overtime as a signal that something is wrong. Before I will authorise overtime for a second week I want to know why it is happening and what is being done to make it unnecessary in future.

9. Coding standards.

The basic standard of coding is that code should be clear to the human reader. Re-factoring (see below) is important in this. So is writing it clearly in the first place.

We can adopt any site standards that you already have, or use our internal ones. Whichever is chosen, the over-riding aim is clarity and therefore correctness. A secondary gain is making code more easily read by the maintenance programmer.

10. Simple Design.

This is important but subtle. We build only what you need for the selected stories.

We do not build flexibility in "just in case". We do not try to guess what you will ask for later. This has some fabulous results by removing unwanted complexity.

If we have not built the complex, the costs are lower. Maintaining the simple is easier, faster and cheaper. Clearly, if you never need the complexity, we have saved you a lot of money.

What may not be so clear is that we have saved you a lot of money if you DO need the complexity. Remember the automatic test cases? They will ensure that, when we build the complexity in, the simple cases all still work. It gives us an immediate certainty that we put the complex code in correctly for the simple cases. Then we can start testing the complex ones.

If we had guessed the complex was needed when building the simple cases, then we would have overcharged on the simple case, and probably made mistakes in our guessing. Now we do not have to spend any time correcting those mistakes. Nothing we have done since will have distortions in for those mistakes, so they do not have to be removed.

11. Re-factoring.

This is a really powerful technique. Re-factoring means to alter the code without altering what it does - it still passes all the tests. We use re-factoring after adding funtionality in order to make the code as clear and free of duplication as if it had been written especially for the current purpose. We sometimes re-factor to make it easier to add some proposed change.

Re-factoring is necessary when it could make the code simpler or clearer, it would remove duplication, or moves functionality to a more suitable class.

The best time to re-factor is when the new code is fresh in you mind, so we always keep on top of it.

The big payoff of re-factoring is that is makes all future maintenance cheaper and easier. Remember, with SoftOptions we are into a maintenance mode after we have completed the first task of the first story. We must keep the future cost of maintenance down or we will simply drown in the complexity, our costs would rocket and the client would stop the project. With re-factoring, we deliver when promised for the cost quoted and the client is delighted to continue his project. Win/win all round.

12. Pair Programming.

This is perhaps the most controversial of the practices. What it means is that we have two programmers on the job when production code is being written. We find that they spark each other, find better solutions, and do better work than either would alone and yet they get through about as much work in a day as the pair would do if working separately.

As one pair programmer put it...

"My partner does more than just improve the quality of my code. He points out my bad ideas and suggests better ones. He keeps me focused, so that I don't go off at a tangent and forget what I was doing. He stops me before I write code we already wrote last week. He reminds me to stick to the practices when I forget. And when we are done, he understands the code as well as I do so I'm not a bottleneck."

He failed to mention that a pair programmer will work harder than when programming alone, because he does not want to let his partner down. There is also the fact that, when you are tired or stuck, your partner can often see a way forward.

One criticism of pair programming is that it "should" cost "about twice" as much as programming alone, and the undoubted benefits would not be worth the extra cost.

Reliable measurements have proved hard to make. However our best estimates are that it although it does cost more to pair program than to program alone it is only between 0 and 7% more and the benefits are real enough. A price we find well worth paying. Remember, you are selecting stories from a fixed price menu, so any cost over-run is our problem not yours.