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.
What really matters is working software.
Although I was interested in the “Cynefin” talk at XPDay last year, what I wanted to see was a demo. As a former boss of mine would have said, “show me the money!!”. Nice ideas, but I’d like to see more than that.
These days, I have a hard time reading most of 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.
Agile development is a set of techniques used to get results. Listen to what works, change or drop what doesn’t work and that should be it. It doesn’t pay to make things more complicated than they need to be. Some times things just are what they are.
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. It’s really worth trying it even if only to find out what you’re missing.
Agile is about keeping things lightweight.
People love the easy stuff in XP. Downloading tools like JUnit and Cruise Control. 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 software development is understanding and changing existing systems.
Some people who just want to tear up what’s there and replace it with something new 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 easier. 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 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:
- special constants and conditions based on special constants scattered through the code?
- different types of string formats are used in the app?
- different “ID” types does the app have?
- random fragments of XML that just happen to be used together all the time
- nested switch statements in your project? Hmmm.
Given that extreme programming, dynamic languages and responsibility-driven design work well where do we go next?