One thing right about agile development

So, normally I'm fully in the camp of planning out your work and then reviewing the plans for flaws, iterating on the plans until satisfied, and only then starting to cut the final code. But just this week I ran into an interesting situation.

The situation was this, we needed a way to get rough schedules for when multiple projects would be delivered and good estimate of month-by-month capacity to take on new work for a development organization of about 400 people. No problem, right? Just go out and buy one of the inumerable tools that vendors are more than willing to sell you, right?

Yeah, right. But we needed it by next week.

So I suggested we build a CAT (Cheap Ass Tool).

Would we ever ship this tool (like to customers)? No.

Would we be keeping this tool around and iterating on it until it is perfect? No.

Did we need to cover every use case and edge condition? Oh, hell no.

And that's how I found myself doing XP (well, really just pair programming kind of... read on).

Now, I didn't realize that it was XP at first. I mean, I was just sitting in my office with the project manager responsible for handing the final reports to the VPs and a director who would have to use the tool. They sat there and said things like, "We need to capture the project's priority." And I would nod and add priority to the database and add the "right thing" to the UI so you could edit it and report on it, etc.

We never bit off more than we could do right there and then. If something big like that came up, the project manager added it to a "parking lot" list that we'd address later. I should say up front that we spent a couple of days before this meeting to compare the spreadsheets that directors were using to do their own scheduling independently. So we had agreement in principle on what we were building.

Anyway, I'd add something and the director (looking over my shoulder) would say things like, "Didn't you want that to be an integer?" Or, "I think you're off by one in that loop." And that's the way we muddled along building a tool that about 20 or so people would end up using.

I find myself in situations like this one fairly often. I wouldn't want to build an OS this way. But for a "Cheap Ass Tool" it is really fast and effective. I suspect that it could have been made even more fast and effective if I knew a bit more about the formalism of XP.

A quick aside about the formalism of XP. I find it really ironic that agile methods (and XP in particular) tend to be really light on documentation, yet there are probably more books written on how to do it right than any other method. Yup. "Stay light, don't get bogged down with formalism and process. And here's a couple of books that will give you the formula to follow."

I mean, when exactly did you last see a book on the waterfall method? Try it. Go to Amazon and search books for "software extreme" and "software waterfall".

Anyway, back to my point...

To efficiently build any good CAT the end user and the person writing the tool must be partnered. They must be in the same room. That's because (obviously) there's no other way for the requirements of the user to get to the developer.

Hmm... maybe there really is a nice place for XP. I imagine that thousands of developers can't all be wrong (insert snide comment about any obsolete language or method here). I think that like Joel Spolsky points out, you've just got to realize upfront what kind of project you're working on.

I guess that for me, agile methods are alright for this kind of project.

My Principles

I've had a couple of requests for a listing of principles that I try to keep in mind whenever I'm dealing with software development. Now understand, I don't write code for a living (although I do write code). I manage people who write code for a living. So your list of principles might be quite different depending on what role you play.

I have been adding to this list since 1998 when I started it. Actually, principle #1 has been with me for many years before that.

Bruce's Principles of Software Development

0. Until software is delivered, act as if it will always be vaporware. (This applies to hiring new employees, hiring new executives, and re-orgs as well as the release of software.)
1. When referring to computer systems, the phrase “We’ll never need more _____ than _____” is always wrong. It is wrong no matter what goes in the blanks.
2. Always design your containers to contain containers. For example, if you are building a feature to group users, make sure that groups can contain other groups as well as users. This is true unless you know that you’ll never need more layers of nesting than one (see principle #1).
3. The projected delivery date for a project is the one date on which it is guaranteed that the project will not be delivered. (Lubetkin’s Law)
4. Delete things while you know why you don’t need them. (O’Neil’s Rule)
5. It should “just work”. (Fajen’s Dictum)
6. There should only be a SINGLE source of truth. (The DRY principle)
   

While what your principles are is important (they guide your decision making), it is really important that you share your principles with those you work with. You can read my post about shared principles in software development here.


"Those are my principles. If you don't like them I have others."
- Groucho Marx

Why Principles Matter in Software Development

Principles? We don't need no stinkin' Principles!
Over the years that I have been working with software I have noticed a couple of things about principles. One of the first things that I noticed is that when you mention principles, people tend to get either confused or up-tight. I think this is mostly because they think that principles are things that are quite personal. I don't want to talk about my principles. I want to talk a bit about using principles when creating software.

Principles are not Rules
First off, principles are not rules. Principles are also not policies. Principles are the thing that we use for creating useful, sensible policies and rules. Rules without a principle behind them are just senseless bureaucracy. In a way, principles are rules about how to make decisions (and rules). Joel Spolsky talks about principles quite a bit. For example:

When you design user interfaces, it's a good idea to keep two principles in mind:

1. Users don't have the manual, and if they did, they wouldn't read it.
2. In fact, users can't read anything, and if they could, they wouldn't want to.

These are not, strictly speaking, facts, but you should act as if they are facts, for it will make your program easier and friendlier.
—Joel on Software, User Interface Design for Programmers

Joel is saying something really smart here. You can take these principles and apply them to any user interface you are designing. You don't have to think about the gritty little details of every special case of users and software working in combination. And the kicker? If you're working with other people (like project managers or testers) and you all agree that these principles are ones you will pay heed to, then you will be more efficient.

Did you bring enough to share?
Principles are incredibly powerful when they are shared. If you share a principle with someone (like whether or not recursion is a good idea) then each of you can make important decisions without having to talk to each other about everything. The more people that share the principle, the more powerful the principle gets. Just think, if ten people share a set of principles and one of them needs to make a decision then, rather than calling a meeting and hashing out the details and all possible outcomes, that person just consults the principles and makes a decision based on them. A principled decision.

That's one reason why start-ups (good ones anyway) tend to be so amazingly productive; all the members share the same principles. Each individual can make independent decisions that are the same in principle as the decisions that the group would make as a whole.

This is also a reason why long established and large companies tend to be so amazingly bureaucratic (bad ones anyway). The principles behind many of their rules and processes have either changed or never been explained to the people who have to follow them. So the rules have lived on, orphaned from the principles that spawned them.

Dave Thomas (of Pragmatic Programmers and Rails fame) wrote:

Andy Hunt and I once wrote a debit card transaction switch. A major requirement was that the user of a debit card shouldn't have the same transaction applied to their account twice. In other words, no matter what sort of failure mode might happen, the error should be on the side of not processing a transaction rather than processing a duplicate transaction.

So, we wrote it on our shared whiteboard in big letters: Err in favor of users.

It joined about half-a-dozen other maxims. Jointly, these guided all those tricky decisions you make while building something complex. Together, these laws gave our application strong internal coherence and great external consistency.

—Dave Thomas, The Pragmatic Programmers

He's talking about shared principles here. These "maxims" were the principles that drove their development philosophy. A foudation that they built their software upon. And if the users agreed with the principles, then they were that much more likely to love the software.

You will certainly want to share your principles with newly hired employees too. A large part of getting new employees onboard and productive is infecting them with the principles of your company. This is critical if you want them to make decisions on their own. If you want to see this in action then look at companies like Nordstrom. In Good to Great, author Jim Collins lays out how Nordstrom goes about this. It is a very interesting read.

So, what about software?
I've been involved in a couple of major re-writes of code. Why am I bringing up re-writes? Well, the thing about a re-write is that the intended function of the code is often very similar. The reason that the code is being re-written is often that it did not perform as intended in some way. In fact, the functional specification may not have changed one bit.

Now this is interesting because if the spec didn't change, and the principles of the members of the development team didn't change, then the decisions they make will not change significantly. One person will decide that things work better if you follow design principle x (all "Next" buttons go on the bottom of the page). Another decides to follow conflicting design principle y (all "Next" buttons go on the toolbar in the footer). In the end the project suffers from the same overall "badness" that probably caused the re-write in the first place.

Every major re-write that I've ever been a part of has failed to produce a good outcome when the same people worked on the new version and did not have a "Come to Jesus" meeting (or meetings) where they reach agreement in principle on how they would make decisions.

Every time there has been agreement in principle, the outcome has been better and reach much more quickly.

I've covered some of the principles that I use in making software development decisions here.