TDD is hard. It is also really, really valuable.

My friend Mark Levison provides ideas and advice on overcoming objections and dealing with the technical and organizational challenges associated with TDD.

Understand objections. They exist for a reason. Understand the reasons, and find solutions to those issues. Dismiss the reasons, and you will not gain traction, you’ll gain obstacles.

Jay Flowers has the goods.

This article starts off with an amusing anecdote about over-engineering, and then provides a bunch of insights into the usefulness of Apache Tomcat as a low-cost, lightweight servlet engine for your J2EE apps. Then he talks about something he wrote to help maintain Tomcat servers.

Anyways, if you’re looking to simplify your web stack, consider Tomcat. It rocks, and it’s free.

See here for the start of this series.

Imagine you have a small number of customers, possibly one. And, you have essentially zero competition. That is to say, not only do you not have other organizations offering competitive products, your customers don’t really have effective alternatives other than to work with you.

Even better is if your customer(s) have an incredibly long planning window – years or more.

In that kind of environment, what would agile buy you? There’s no need to respond quickly to changes in the market, because there essentially is no market. There’s no need to move fast, because you have nothing to compare yourself to. There’s no need to risk pissing off the customer with a half-finished project – you’re already at the top, there’s nowhere to go but down.

If I were in charge of such a project, I would potentially find value in pair programming (although I would probably already have a very disciplined review process). But I would absolutely allocate tremendous amounts of time to pre-planning, and getting everything “just so” before writing a single line of code (other than tests and prototypes of new technologies, etc).

Heck, if I worked at a place with essentially no competition, I’d probably look at agile and think ‘what a bunch of reckless speedsters’ I would probably find the whole concept of “keeping up with the competition” both uncomfortable and sub-optimal.

And it would be… if I had no competitors.

Glen Alleman has an interesting post, where he devalues Unit Testing, in favor of testing requirements.

I wonder what he thinks of Behavior Driven Development tools, such as EasyB. Those would seem to be a closer fit to what he’s looking for.

These aren’t earth-shattering insights, but it’s nice to have some reminders of how to make the whole bug tracking process a little easier for everyone involved.

Click here for the whole series

Would you use a Ferrari to haul your big bags of mulch for your garden? Would you use a bulldozer to excavate the fossilized bones of a rare dinosaur? Probably not. Those aren’t the right tools for the jobs.

Agile development techniques were designed as a way to “optimize for the common case” – lots of change requests, new(ish) technologies, lots of budget pressure and poorly elaborated requirements.

But what if your project doesn’t fit the common case?

For example, what if change requests were a fairly rare event? What if the expectation was that a change request was a significant “stop” – that the customers, testers, management and everyone else involved were comfortable with the idea of carefully re-evaluating everything about the project, every time there was a change request.

In those sorts of environments, a methodology optimized for frequent, must-get-done-ASAP change is probably not a good fit.

And, more importantly, people who work in such an environment will probably look at Agile and say ‘what an amateurish approach – we have all these wonderful structures in place to deal with change’.

And for their environments, they’re right. But that doesn’t mean Agile is useless, any more than a bulldozer is useless because an archaeologist doesn’t need one to get his job done.

I’m seeing a lot of people opining on the limitations of Agile. I believe that this is a good thing, because every philosophy/methodology needs to spend some time in self-reflection.

First, the general principles:

1. . Some projects have lots of change requests, some have very few.
2. . Some projects have lots of competitive threats and pressure to innovate, some have very few
3. . Some projects have many customers, some have only one.
4. . Some projects have a need to generate revenue quickly. Others have a longer threshold, including never.
5. . Some projects are working on cutting edge technology, others are working on well-established technologies.
6. . Some projects have deeply engaged ‘owners’, others have only a distracted, part-time ‘owner’
7. . Some projects are life-critical, others are not
8. . Some projects have lots of turnover, some have less

I’m going to explore these variations over the next several blog posts.

*update* – added point 8.

Cleaning out my to-read lists – this is a paper/tutorial from November on agile architecture. I looked through the list, it seems similar to what I would do myself as an agile architect, although the article is more thorough than I would usually be.

I don’t know that it necessarily defines an ‘agile’ architecture – it seems like the general work one does as an architect, regardless of the development methodology. However, I find it useful to review docs like this, to see if there are useful checklists or ideas that I haven’t considered before.