Design Last

Kent Beck turned software development on its head when he popularized test driven development. By now we all know that we should be writing our tests as we write our code. 

I think it was also Beck who encouraged us to listen before we test before we code before we design.

But it's not just the change in the order of doing things that's important. Another key element is to listen, test, code and design iteratively. Not three-week-rup-iteratively but 10-minute-agile-iteratively. 

So if you ever catch yourself tagging "and Design" onto "Analysis",  lie back and think of Kent.

Notepad Revival

I've always been suspicious of programmers who use Notepad. And I'm not alone. As the Pragmatic Programmers  said "it's like using a teaspoon as a shovel". Perhaps I shouldn't be so prejudiced. Recently I've caught myself using this much scorned text editor. More often than I'd like to admit.

So what do I use Notepad for? The clue is in the name. Notepad is extremely good for jotting down notes. And the reasons it's good for this are that it's fast, lightweight and simple.

It's great for creating short todos, keeping a work journal or noting all those things that occur to me during a sprint but which are forgotten when the retrospective comes around.

But why the notepad revival now? The answer is Dropbox. Suddenly I can effortlessly save my jottings on my laptop, update them on my home machine and read them on my work box. 

Which doesn't mean you should even think of using Notepad to code java, create xml or check logs. 

Building Bridges

Anybody who tries to compare software development to building bridges doesn't know what they're talking about. Or so I thought, until I stumbled across some research from the construction industry.

The research in question was a study into the lack of efficiency in the Swedish house building industry. OK, not exactly bridges but houses are close enough for me. The study report's  main conclusion was that building projects are actually very inefficient and savings of up to 50% could be achieved.

I was reminded again of this report while attending a ScrumMaster course which we had arranged in Falun (thanks Henrik for two days of enlightenment).

And the reason I was reminded of it was that most of the recommendations the report made could have come straight from a scrum manual: 

•  focusing on delivering value to the customer
•  eliminating activities that don't deliver customer value
•  creating cross functional teams with customers and suppliers working in partnership
•  empowering and encouraging workers to improve their own processes. 
  

Perhaps it is time to start dreaming of building bridges like we build software!