go ugly early

I don’t think I had heard the phrase “going ugly” until I read Go Ugly Early by Dwayne Melancon today. To quote Dwayne:

“This concept involves releasing early iterations of your products so you can allow your customers to interact with them and provide feedback. I’m not talking about releasing unstable or buggy products – I’m talking about releasing stable products that have limited functionality, but which telegraph the shapes of things to come.”

Which, of course, is exactly the approach promoted by all of the agile software development methods. Sort of.

In fact, the agile community has amazingly little to say about beta programmes and the like. We talk a great deal about the OnsiteCustomer (aka ProductOwner or ChiefEngineer or ProductDirector) who gives rapid feedback to the developers on a daily basis. But that’s not the same as giving a try-out version to a few key users. If you’re developing something you would use yourself, then trying out your own dog food early is very easy and relatively risk-free. But when the target user is potentially a paying customer, it can be all too easy to perceive the risks as outweighing the advantages. What if they laugh at our half-baked ideas? What if they steal the idea and take it to our leading competitor? Frankly, I don’t believe any of these are real issues. Not compared to the benefits of using early-access free stuff to forge a long-term relationship.

The ProductDirector’s rapid feedback and direction is essential in the microcosm of the development shop itself. But in addition, giving genuine users the chance to genuinely use parts of your new product under genuine conditions can be … genuinely useful – both to you and to them. Your user (or potential user) is being given the opportunity to ensure that your next product fits them like a glove. Most will be prepared to invest a little time to get that. And if they laugh, you’ve learned something about your understanding of the market – and you’ve learned it without investing the whole kaboodle.

Of course, the partial system must be production quality. If it isn’t bug-free and trivial to install you will probably be dismissed out of hand. (Again you’ve learned something – but it was something you already knew and could have avoided.) So this isn’t prototyping, it is real product development, in small chunks. The opportunity only arises because of honest and thorough use of agile practices such as TDD, ContinuousIntegration, DailyBuild etc. (Maybe that’s where the perceived risks come from: this is all new. Waterfalling never gave us the chance to create this kind of relationship with our customers.)

Do you have a story where going ugly early saved your bacon? I’d love to hear it.

use of cruisecontrol shows you have problems

Why I Don’t Like CruiseControl is a very thought-provoking article by James Shore. It finishes with the statement:

“Bottom line? If you’re using CruiseControl, it’s a clear sign that you have opportunities to improve. Try to get to the point where, like me, you don’t like CruiseControl… because you don’t need it.”

Heresy? Well, I certainly like the logic that brought James to that conclusion. And I’ve had experiences that support his view…

paradise mill

Monday was a public holiday in the UK. We had a typical British summer’s day – watery sunshine interspersed with periods of torrential rain. We needed to keep the kids occupied somewhere new and somewhere indoors, so we decided to visit Paradise Mill. Macclesfield used to be a leading centre for the manufacture of silk garments, and Paradise Mill is a fully restored working Victorian silk mill. The exhibits are great, and the tour is terrific – the kids got to try some of the work that their counterparts (they’re aged 8 and 6) would have been doing in the 1820s!

On the wall at one end of the main weaving room was a notice from the mill’s owners, entitled “Don’t pass on faults”. The mill workers were all paid according to the amount of work they did each week – for example the loom operators were paid a penny or two for each inch of completed, perfect silk cloth. The notice pointed out that any worker who did a faulty piece of work should fix it themselves, and not allow it to be found by the next worker in the process. Faulty work, the notice advised, slows down your co-workers (and so reduces their pay), slows you down (and so reduces your pay) and may create a bad impression on customers (resulting in loss of business and therefore less pay for everyone). The impact was stated just like that – baldly in financial terms.

I remembered reading that the same philosophy held in the 1920s in the Toyoda Spinning and Weaving works. But instead of writing a notice, the mill’s owner Toyoda Sakichi implemented a series of failsafe devices that automatically stopped the looms if they detected a fault. In this mill it was near impossible to pass on a fault. And this became one of the pillars of lean production – pursuit of perfect quality makes the whole process faster and more predictable.

As we know, test-driven development and the daily build help to do this for software development. A while back a very senior manager in a large multi-national dismissed my efforts to improve the agility of a group of software projects: “No defects at all? You’re living in a dreamland!” Paradise Mill, anyone?

the daily build

About four years ago, I was leading one of the teams in a 7-team software project. This time it was my turn to be the ‘integration manager’ for the next release. So very early in the release cycle I created a batch job that performed a nightly build of everything in the current codebase. And if anything had automated tests the batch job ran them too. I wanted to de-risk the release by finding most integration problems early, before ‘codefreeze’ at the end of the development phase.

The nightly build was a great success. Most nights the tests all passed, and only rarely did anyone check in code that broke the build itself. But the integration and system testing for this release was still a nightmare of panic fixes and hurried tests.

And a couple of releases later I worked out why: the existence of the nightly build had not changed anyone’s habits for the better. The other teams only ever checked in code on the last day of each release’s development phase, just in time for system testing! In fact I had made things worse than they were before: the fear of breaking the overnight build had actually caused many check-ins to be delayed until everything was “finished”. (And so our ClearCase repository crashed on the last day of every release’s development phase, due to overload.) Instead of providing feedback on development progress, the nightly build had actually reduced feedback and created more integration problems than we had before!

I’ve always advocated the daily build as one of the things that should be implemented first when moving a project towards agility. But I now realise that its success depends on a precondition: the development team (and its managers) must understand that it is possible to develop a system feature by feature. In the agile community we know all about the benefits of doing this, but I suggest that most software managers out there don’t even hold it as possible. Most of my peers on the project above thought it was impractical, or even laughable, to organise their work so that we had a working system at the end of each day. Why go to all the extra effort of finding pieces that could be added without breaking anything, and that were not dependent on something that was scheduled to be done sometime later…?

Update, 9 Sept 04
Mike Clark points out an interesting article in this month’s Better Software magazine on this very topic. There is a real difference between Continuous Integration and Daily Build, and the psychological impact of that difference will drive teams in quite different directions.

patterns for process improvement kick-start

Books about Lean Manufacturing are full of stories of ‘kaikaku’ events – dramatic and theatrical process improvement kick-start episodes, designed to get the workforce shaken and stirred into believing that significant improvement is possible. Julian commented that software is ‘invisible’, so it’s very hard to see the workspace. I agree that the ‘invisibility’ of the code makes it hard to engineer the drama of kaikaku events, but there are a few obvious things one can do immediately when faced with trying to initiate process improvement. Here are some kaikaku activities I’ve been able to do (depending on the maturity – or otherwise – of the shop in question):

  • ‘release’ the current code
  • install the code into a CM repository
  • get the build automated
  • get the build time under an hour
  • get just one test running every hour
  • run a linter to identify unused code, and then remove it all
  • run a dependency checker to identify loops among classes and packages, and then collapse each loop into a single module/package

Do you have any other successful kaizen kick-start tactics?

[Update: creating a daily build isn’t always a benefit just by itself…]

Further update, 13-feb-06:
The original content of this post was lost and corrupted sometime during 2005. But I was able to find it again today, thanks to the wonderful wayback machine