Category: programming

No backlog

The backlog has lots of benefits in the software development process, but is it necessary?  Could there be more to gain by just trusting your crew will do the right thing at the right time?

It occurred to me while tracking Github commits on a project that I didn’t need to maintain a backlog or a burn down chart or any of those kinds of things anymore.

Everyone was watching each other’s commits, commenting on issues, and chatting when they needed to.  I could see what everyone had done the day before.

They were all in synch enough to collaborate on the output when it helped to collaborate or work independently when that was more effective.

What could I add? Remind them of all the things they haven’t done? That’s uninspiring for everyone involved.

How does everyone know what to work on next?

The devs know what’s important, and they know how to do their job efficiently…let them work it out. If they don’t know what’s important it will become obvious in their commits. Then you can just steer when the emphasis is wrong rather than mapping hours to tasks.

They may in fact want to maintain a list that works like a backlog.  But maybe that should be a personal productivity choice, not something that’s imposed by someone else.

What about all those things you want to do that aren’t getting done?

I’ve never had a feature that really mattered to me just fade from memory. In fact, having no backlog forces a sharper focus.

How do you know when things will get done?

Your devs will tell you, and they will be accurate if it’s a personal agreement between you rather than a number on a spreadsheet.  If you have a deadline that really matters, then just be clear about that.  That becomes framework within which to operate, a feature of the code.

What if the developer doesn’t understand the requirements?

Well, do you actually really need to spell out requirements? Aren’t your developers tasked with solving the need? Let them pitch a solution to a problem, agree on it, and then let them run with it.

Of course, I don’t know how well this approach would work in a team larger than maybe 8 people, or a large-scale project with multiple parallel streams to it.  And maybe the chaos does more harm than good over time.

Clearly, I’m exaggerating for effect a little here, but I wonder a lot about how far you could go with this approach and where it really breaks down.

I think a lot of folks want things like backlogs because one can establish a meaningful agreement and reduce tension between people who organize stuff and people who create stuff.  But it’s often used to protect one side from the faults of the other rather than join them up to create a stronger whole.

But all projects and teams are different.  And it can be very tricky working out what should be done, by whom and when.

I think what I’m suggesting is that rather than making decisions around time and resource where success is measured by how effectively activity maps to a plan, maybe the better way to lead a software project instead is to adjust decision making according to the appropriate abstraction level for the project.  That way you can value quality and creativity over precision of delivery.

For example, the resources required to build, say, a global transaction platform vs a web page are very different.  And your teams will not allow you to rank them together.  You have to zoom in or out to understand the impact of those two projects, and that will then affect how you allocate resources to make them each happen.

Once that discussion has been had and everyone has agreed on what they are supposed to be working on, make sure they have enough caffeinated beverages and get out of the way.

Keep an eye on their commits each day.  And drop the backlog.

It’s incredibly liberating.

Scaffolding web sites with Ruby on Rails

I started messing around with Ruby on Rails for the first time on Sunday. This was after spending all day Saturday tearing down kitchen cupboards, tiled sinks and entire walls for a friend who is remodeling his house, so I got my fill of building last weekend whether real or virtual.


Photo: bruce grant

Trying to figure out how Ruby on Rails worked, I felt like I was remodeling my brain. It was as if I walked into Ikea with just a basic idea of what I wanted my new kitchen to look like and then walked out with design schematics and new appliances an hour later. I suddenly had confidence that I could create a really nice web site with a lot of functionality that was basically inaccessible to me before because of my limited programming background.

The “Ah hah!” moment came for me when I added two words to one of the scripts: “scaffold mydatabase”. When I refreshed my web site, I was adding, editing and deleting data in my database via a web interface. It all automatically just worked. Then literally 15 minutes later I had 2 databases talking to eachother.

It’s mindblowing how much power this environment gives to people who aren’t true coders.

I have a feeling I’ll get stuck and frustrated with what I’m trying to build. But I’m very hopeful Ruby on Rails will get me closer than I could with open source PHP tools. If nothing else, I’ll get a sense for this new trend.

Programming seems to have about a 3 year fashion cycle that also intersects with influxes of new ideas for web applications and a full cycle of students coming out of university. Now we’re at the early stages of a creative explosion on the Internet enabled by things like Rails, open APIs, storage solutions like S3, and JSON. And you can also wrap an idea in any number of different business models in even less time than it takes to build the product itself.

Maybe instead of LAMP (Linux, Apache, MySQL, PHP), we now have RASH (Rails, APIs, S3, Hosted).

There must be similar reactions to breakthroughs in the construction industry when things like cross-linked polyethylene (PEX) hit the market. Of course, construction suffers from bad naming as much as any other trade. Not everything can be as cool as a sawzall or funny pipe.