There has been a lot of discussion about post-Agile, pliant, ex-Agile, etc. It's kind of interesting to see how quickly people jump off of a bandwagon. I shouldn't bitch; most of these people were probably in fact never quite on the bandwagon. I still think this is a great philosophy... but somehow I never quite managed to consistently sit down and write tests first. But I couldn't put my finger on the reason...

Wow. This one really caught my eye. Fred Brooks of Mythical Man-Month fame, whose wisdom on software is still applicable decades later, wrote an article in 1987 that damn near predicted the Agile movement. This isn't Agile in the name-brand TDD sense, but a more general recognition that the most effective way to develop complex software is to iteratively "grow" it. Build one to throw away becomes a "spike". I can definitely see the evolution of the ideas a bit more clearly now.

Software Engineering Explained, as posted by Andy Hunt.

Robert Martin recently posted an interesting blog entry on Never Being Blocked. The article's more interesting than the comments, except for my comments of course :), and it ties together not just Agile ideas but several other useful practices into a common pattern he calls Not Being Blocked. I think I see what he's saying, but I think it's part of an even larger pattern.

What are the common elements of these common agile practices:
test-driven development?

refactoring?

customer-directed goals?

pair programming?

continuous integration?

frequent small releases?

and these other practices he mentions, which aren't direct corollaries of Agile, and don't require Agile, but often do seem to come up at the same time, from the same people:

why prefer non-blocking source control?

why build it yourself instead of waiting for another team or version?

why build it freeform instead of with a heavy internal architecture?

why build a stub for an incomplete or unavailable system?

Constant. Incremental. Improvements.

I absolutely love Kathy Sierra's blog. In addition to an extraordinary skill at coming up with simple imagery to communicate her ideas, she also has great ideas!

Today's is micromanagement. The first image draws you in and states something we all kind of know and agree with: Micromanagement stifles independent thinking.

The impressive thing to me is her ability to make us realize that we're doing it. She has identified the "good" side of micromanagement to a T, the things people use to justify it.

Are you a micromanager?

Martin Fowler has updated his five year old essay, The New Methodology. It's always been a great article, and it's even better now. Plenty of useful links for those who haven't heard of Agile.

It kind of makes me want to write a slightly different essay, specifically targeted at IT buyers and users rather than IT developers. People who may or may not have heard the buzzwords and just want to know what this means to them. I'll be borrowing heavily from Fowler and others, of course. :)

So, I present my Guide to Buying Custom Business Software.

Someday I suppose I should assemble a set of pages that communicate what I do to prospective clients better than these pseudo-random discussions.

I'd like to think it would look a lot like this. Well done, Jim.

I approve of the way he avoids a bullet point list of skills and buzzwords. I don't do training, but I've always felt that the best description of my own work is "I solve information problems" rather than "I do C++, SQL, C#, OO theory, etc."

I've often wondered this. It's really not a very good format. But I've used it a couple of times, because it's easy and well supported. I didn't need to move data between two different systems that couldn't share a more direct interface, which is XML's unique strength.

Christopher Diggins, in about the tenth comment down on this post, has a very clear explanation for why. The rest of the article is interesting, but I'm focusing on one thing. I think that he's right about the reasons we use XML, but that suggests to me a potential path for change:

Gregg Wonderly has some of the same doubts I do about the Web Services/SOA model.

Here's an interesting article from Tristan Yates. This is the man who in September put up an interesting blog about how his IT bosses went with the safe choice. I believe they spent a quarter of a million dollars a week on IBM "talent" at $325 an hour which was hired from Monster and were being payed about $75.

Anyway, I think I like this article even better.
Why you're smarter than your process

I'll have more to say on it later. No time now.