A little less conversation a little more action please...

I’ve been quiet for a while. Here’s a few thoughts about agile software development:

Doing things is far more important than talking or writing about them.

The only defence against the rising tide of bullshit in the software business is looking at real, working software.

Although I was interested by Dave Snowden’s talk at XPDay last year, what I didn’t see was any kind of demo. As a former boss of mine would have said, “show me the money!!”. Nice ideas, but that just doesn’t cut it with me any more.

These days, I have a hard time reading most of the stuff on the c2 wiki. I used to read it avidly, ask questions and file away little clever things I found in case they’d be useful. Nowadays it looks like a “who can make the smartest comment” competition. Not many people there seem to be talking about things they’ve done. I just seen chains of comments about comments laced with conjecture and opinion. C2 contributors, this is not the way.

Agile is more like Ju Jitsu than Aikido. It’s a set of techniques used to get results. Listen to what works, change or drop what doesn’t work and then go home. I just don’t have time for theory or philosophy. I’ve spent too much time on stuff like that in the past. Some things just are what they are.

Is there any point having protracted technical discussions with parachutist “technical architects” and non-technical software development managers?. Spike solutions are a great way to run rings around corporate technology pundits that are involved but not committed.

They don’t say “working code over comprehensive documentation” in the agile manifesto for nothing.

Dynamic languages kick ass

Agile methods come from the Smalltalk community. If you’re a developer that’s serious about agile methods you have the time to look at Smalltalk. Developers that don’t “get” Smalltalk probably don’t “get” agile either. The C++ community didn’t invent extreme programming. Ever wondered why?

It took me about seven years to overcome my prejudice against dynamic languages. If you disagree, tough - you’re free to disadvantage yourself. I’m sure lots of people who have no time to look at Smalltalk have plenty of time to argue about things in principle.

Until recently I had no idea that there were so-called agile methods people around who didn’t understand this. It’s just like finding a Japanese martial arts sword “expert” that has never picked up a sword.

Agile is about keeping things lightweight.

People love the easy stuff in XP. Downloading tools like JUnit and Cruise Control. People also love getting really anal about mocks and testing. What they don’t like is refactoring. Organisations that take refactoring seriously are more likely to “get” XP, because refactoring is a skill, not something to consume and it has no up front benefit. It’s the unglamorous, skilled bit that makes the rest sustainable.

Here’s a new word: De-Enterprise - to remove the Industrial Strength, Carrier Grade, 99.999% huge, over-complex, expensive, enterprise looserism stuff you’ve been frightened into buying and replacing it with something that’s fit for purpose and maintainable.

The most pressing technical problem in the software development business is understanding and changing existing systems.

Some people who just want to tear up what’s there and replace it with some half-baked idea they’ve got, or force-fit their sole idea to everything. Real, working code has a habit of becoming complicated. Abstract ideas in the head look a lot nicer. On the journey towards being real, working code, those ideas will accumulate complexity when the rub up against all the things you didn’t see up front in your head. It’s easy to sacrifice complicated working code for what turns out to be complicated broken code.

Learning to read and change existing code is a real skill, and there’s a whole bunch of research challenges in code comprehension and refactoring that are needed to keep real, working code alive.

I work with some people who are rather good at this. If you’re not that lucky there’s a few books that can help: “Code Reading” by Diomidis Spinellis and “Working with Legacy Code” by Michael Feathers. It’s a matter of developing “gumption”.

Paul Graham is right about technology choices.

Commodity programming languages are made to be sold to average programmers. Use them and you become a commodity. The “Better, Faster Ligher Java” book was written by somebody who used to sell “enterprise” solutions for a living. He makes it clear that they’ve been made to extract lots of money from executives rather than to be the best tools they can be.

However freaky you might think Paul Graham’s technology choices were, he had the strength of his convictions. He followed through and it worked.

Some people say that he just sold out to yahoo!. I doubt his critics have done any better. He’s probably sitting on a beach somewhere laughing at them.

Technical courage goes a long way.

Most Java and C# programmers have no idea how to do object-oriented programming.

They’re really doing entity-relationship-oriented programming. Trouble is, they’re in the majority so they form a self-reinforcing group that take for granted knowledge and skills that they don’t even realise that they don’t have.

Here are some questions. How many real classes are hidden behind:

What next?

Most people don’t get what we’ve learned about extreme programming, dynamic languages and responsibility-driven design. So given that those things already exist and work well, where do we go next?