Frank Carver's Punch Barrel

… if they involve pancakes and beer!

AGILE IN ACTION: A whole lotta fun to be had.

We are currently trying to come to some conclusions about the “shape” of a new software product, and facing a whole lot of problems. Stakeholders are happy to argue for hours about relative priorities of individual features, but so far these exist in a vacuum without an overall vision of a product.

With that in mind we are casting around for any hints on how to map out what we build and in what order. Chris Sims has some suggestions which may be useful, but I’m not sure they address our underlying problem.

InfoQ: Story Mapping Gives Context to User Stories.

Good, thought-provoking stuff. If agile is all about doing what’s necessary when it’s necessary, and not doing what’s not necessary, why should we wait for a retrospective to fix any problems?

Are retrospectives an antipattern? | Steven “Doc” List’s Random Musings.

An excellent point from Andy Palmer. Code which starts out too neat and ordered can make refactoring too difficult. Throw it all in and let the organization emerge from the functionality.

Andy Palmer » Code should start out messy.

Do you want to get certified in agile software development?

Fastest Agile Certification On The Web!.

I like to read books, and have learned a lot from reading technical books in the past. These days I somehow always feel too busy to go back and re-read anything I have already read.

Mark Needham and his commenters offer come compelling arguments that it might actually be re-reading which brings the greatest value.

Re-reading books at Mark Needham.

This afternoon, or team had an interesting discussion about our bug tracking system. For some time we have not been happy with the existing bugzilla installation, and the task of finding a replacement has floated on the to-do list. We started to discuss replacements again today, but this time it was different. For about a month, we have had no more than two or three bugs in existence at any one time, and these have been fixed very quickly. Perhaps we don’t have so much need for a bug-tracking system after all?

I was very interested to read that Elisabeth Hendrickson takes a strong stance in this direction too:
InfoQ: Throw Away Your Bug Tracking System?

I think its fair to say that a lot of attempts to “manage” software projects and software teams simply do not work. This is not a new problem, and a lot of smart people have had a go at it.

Recently, software and business pundit Joel Spolsky has waded in, with his take on the importance of  a “program manager”.

How to be a program manager – Joel on Software.

The team at Energized Work are very upbeat about their process, and in particular how it helps generate real company income every week.

Much of their recipe will be familiar to most agile practitioners, but there are some good extra suggestions, too.

AGILE IN ACTION: ‘No excuses’ done done.

On the one hand this looks like a neat technology. On the other hand it could be more “extreme”.

Cuberick: Pair programming with multiple mouse pointers and keyboard foci

Sure. It removes the bottleneck of fighting for control of a single keyboard and mouse, but there is still only a single screen. So why not use a version of this where each user also gets their own screen. It’s easy, familiar and cheap and works with any operating system – it’s called a separate computer.

While this may seem sarcastic, my point is really that one of the key reasons pair programming works is that it allows each partner to take different a role. While one is “driving” and concerned with the details of keyboard and mouse the other is free to consider larger issues.

I may be wrong, but it seems that allowing both to drive loses that benefit, and plunges both partners into the fiddly world of move, click and type.

Wow, is Test-Driven Developement (TDD) really 10 tears old? Gojko Adzic is blogging the QCon London conference, and has a summary of the TDD lessons-learned session.

Gojko Adzic » QCon London 2009: What have we learned from 10 Years of TDD?.

I’m currently spending a fair amount of time on evaluating distributed version control systems (DVCS) such as git, bazaar and mercurial. Some things which were easy using a centralized version control system such as subversion or cvs seem more complicated, but I am now starting to find ways of using DVCS to do things which the old systems simply could not manage.

It took me a whole evening of fiddling, but I have now set up git to allow me to make chanches to a local version of one of my web sites and commit changes as I feel like it, then when I am happy, send the changes to the live web site with a single git push. This has been working well for a few days, so I plan to roll out a similar structure to the rest of my web sites soon.

Another interesting use for DVCS was pointed out by Francisco Trindade. Distributed version control can help to enable “set based design“. This is a technique where a team samples a wide range of possibilities to converge on a “sweet spot” where market need, business value and manufacturing efficiency are balanced.

Agile development relies for its speed and productivity on making only that which is really needed. Sometimes it can be easy to forget that performance and scalability can be needed too.

Alex Verkhovsky has an incisive post about how to deal with the notion of “premature optimization”.

Thread.current.to_s: The keyword in “premature optimization is evil” is “premature”

How minimal can an agile process really go? Brad Cross has described his lightweight process and it does seem pretty lightweight

On the Gnarl Side: Lightweight Lean Agile.

Like many teams, I’m sure, we are trying to squeeze every drop of effectiveness out of our time. Manual build and deployment not only takes up valuable time, but also acts as a drag on the development process. Anything which pulls developers out of “the zone” is a bad thing for productivity.

We usually use the familiar “ant” build tool for building deployable artefacts, but have found it increasingly fiddly as our expectations have grown. And ant is hardly useful at all for real-world deployment tasks.

It may be the time to re-consider other build and deployment options.

Thread.current.to_s: Let’s use real languages for builds

I love this kind of analogy. Thinking and learning about one area by considering another is a very powerful technique for boosting overall understanding and wisdom. In this case, Steve Freeman has scraped off the climbing terminology from a snippet of an article and replaced it with jargon from software development.

Thought-provoking.

Tips on Test-Driven Development | Steve Freeman

An interesting question from Simon Brown, and some interesting responses.

Why aren’t software architects held accountable? – Coding the Architecture.

Personally I don’t believe in the idea of an architect contributing during only part of a project. If architecture is important (and on some work it is obviously not) then whoever is responsible for architecture needs to be involved throughout the project, and just as accountable for the outcome as any other team member.

Several projects I have been woreking on have moved away from standard relational models to a more fluid, attribute-based, approach.

One of my biggest worries in all thee cases is scalability and efficiency. It would be tough to find out that a working installation becomes unusable as data sizes and/or loads grow.

Bret Taylor has some really interesting suggestions on how to address this sort of issue using MySQL as a “schema-less” database.

How FriendFeed uses MySQL to store schema-less data – Bret Taylor’s blog.