From Months to Minutes

I found another presentation on InfoQ, this time by Dan North. In it, he puts many Agile practices through the wringer, and turns them inside out and on their head. Dan questions why we do them, what they do for us, and offers pointers on how to intelligently apply them to become a high performing team.

It's a great and very fast-paced discussion, and it got me thinking a lot about what I do and what I recommend to my teams.

My favorite parts, which are also the most important steps to effectively delivering software, is about the need for one team. In his case, he talks of developers working side by side with traders. He talks about how the developers know as much about trading as the traders do, having learned this by spending time talking with the traders while they work making trades. There is no difference between the business and the engineers. It's one team, consisting of both engineers and traders.

He also talks about minimizing boundaries and hand-offs, particularly within the team. The team does not have members who are analysts, QA's, DBA's, etc. Those roles exist, and are filled by the team members as needed. Particularly, the developers are the ones talking to the traders about features. There is no handoff from customer to analyst to designer to developer. The developers talk directly with the traders, and then implement the features. There is no loss of fidelity; the message does not have a chance to be misunderstood. This is helped by the fact that the traders and developers work together.

Craft and Software Engineering

Glenn Vanderburg has a great presentation available on InfoQ titled Craft and Software Engineering. In it, he describes where Software Engineering came from, some of the fallacies, and a direction to make it more like other Engineering disciplines. It's a great talk and moves quite well through the content. I'd recommend it to anyone involved in software development.

One of the things he talks about is feedback, and how the different XP provide feedback at different levels of granularity, and at different timescales. He also discusses this in his 2005 paper XP Annealed. Here's what this looks like in a table:

XP Practice	Feedback	Timeframe
short releases	solutions	months
planning game	priorities	weeks
acceptance testing	features
collective ownership	architecture	days
on-site customer
continuous integration	design	hours
system metaphor	classes and interfaces	minutes
unit testing	statements and methods	seconds
pair programming

In his paper, he goes on to describe how the nested levels of feedback are effective and efficient because the practices support each other, and cover for each other. Each practice, at each level of granularity and timeframe, covers and is covered by nearby practices.

Observation: The feedback can be broadly classified as technical at the lower levels, and business at the higher levels. Taken broadly, there are only two types of roles needed to implement the project. Technical (developers) to work out the design and testing, and business (non-technical) to provide the vision, the priorities and acceptance criteria.

Taking it one step further, putting these people together, as one collocated team, would be the most effective way to facilitate this communication. Nothing original here, but it seems to be a natural progression. It minimizes the number of hops that need to happen for any communication.

That's not to say there is no room for specialists, for things such as the environment, deployment, acceptance testing, UI design, and so on. However, they should all be part of the same collocated team.

Learning Apache and Linux

A co-worker asked me if I knew any good books where he could read up on using Apache and Linux. I thought for a second, and quickly answered “Nope, not a one.”

“Oh!”, he said, looking somewhat dejected. Well, neither of us were looking for that response.

Then I had an idea. “Why a book? Just get a slice and just practice. It’ll probably be cheaper than a book, and you’ll learn more.”

After planting that idea, I went looking at what it would really take. I was close.

Get a slice

I checkout out what Slicehost was offering. For $20/month, you can get a linux instance with 256MB of memory, 10GB of disk. Not bad, but that seemed a little pricey to me. I kept looking.

I didn’t have to go far. Slicehost is owned by Rackspace, which offers the same instance for about $10.95/month. You’re only charged for the time your server is running, so you could bring it offline to save some dough.

Not very original

The idea of learning as you go on your own virtual instance wasn’t very original — Slicehost was promoting the same idea right on their faq:

I’m kind of new to this, will it be too hard?

Maybe. Our Slices are full distros with root access. Many people coming from shared hosting are used to a cPanel type control system and limited shell access. We’re geared for people who want to start from scratch and tune a system for their purposes. However, everyone has to start somewhere. A 256slice is a great place to cut your teeth on building production boxes from scratch. Tweak, explore, learn. If you screw up, login to SliceManager and restart the box. If you really screw up, login and reinstall ;). You’ll be a Linux guru in no time.

Now what?

So you got a slice. How do you start? This is where the options (and opportunities) are endless. The key point would be to start playing and see how far you can get. And maybe O’Reilly’s Lamp could help as an initial resource.

Some ideas:

• Install Apache and get a static website deployed.
• Install PHP, Perl or Python and get a dynamic website going.
• Install a database, maybe Postgres or MySQL. Develop an deploy a small application.
• Install Ruby and deploy a Sinatra or Rails application.
• For the advanced — install and use another datastore, like redis or mongoDB.
• For extra credit — deploy several applications together on the same host.