May 07

Between Heaven and Earth

Today I stumbled upon another source of developer wisdom, Des Traynor’s Programming Theorems. One of the theorems rings especially true for me after the recent insights into developing a Sudoku solver the TDD way:

For every Architecture Astronaut out there, there is at least one coder who thinks that being “Agile” is a perfect substitute for foresight.

If you wonder what Architecture Astronauts are, its a term coined by Joel Spolsky with regard to people climbing up the abstraction ladder a little too far:

When you go too far up, abstraction-wise, you run out of oxygen. Sometimes smart thinkers just don’t know when to stop, and they create these absurd, all-encompassing, high-level pictures of the universe that are all good and fine, but don’t actually mean anything at all. These are the people I call Architecture Astronauts.

I know that I tend to be an Architecture Astronaut sometimes, probably it’s because thinking meta keeps me from the exhausting work of bothering with all the real-world problems. I wouldn’t be surprised if this was the main reason for developers to become Architecture Astronauts at all.

But Architectural Outer Space isn’t a place where I stay very long usually, because its my experience that the lack of oxygen disrupts any attempts of getting actually something done. And that’s where agility fits in: If I get the whole idea of agility right, it’s all about getting things done (unless you use it as an excuse to shutdown your brain).

Apr 07

How to not solve a Sudoku

I found this at Ravi Mohan’s One Man Hacking:

Ron Jeffries attempts to create a sudoku solver – here, here, here, here and here. (You really ought to read these articles. They are ummm…{cough} …err…. enlightening.)

Peter Norvig creates a Sudoku Solver.

Compare. Learn.

To increase the impact, I suggest you read Norvig’s essay first. It’s a great read and the elegance and concision of his solution gave me this tingly warm feeling of sheer developer entrancement. In contrast, Jeffries’ writings on implementing a Sudoku solver by following a test-driven development approach, are just disconcerting. In the end, he abandons his half-finished work after five postings. If he achieves anything, he impressively demonstrates that he’s not exactly an algorithms expert (which Peter Norvig, of course, is).

But, as Ravi says, there’s an important lesson to learn here: agile approaches are about software development, not about algorithm design. To be more precise: they are mainly about achieving software quality, not correctness. It’s the purpose of tests to help the developer maintain functional correctness – not to guide her towards a correct solution of an algorithmically non-trivial problem, such as Sudoku solving.

I think, this is a good example for the old saying “If your only tool is a hammer, every problem looks like a nail.” And it supports my impression that in these days too many people in the development world focus on the methodological aspects of software development and underestimate the importance of fundamentals such as algorithm design.

UPDATE: Vlad Levin goes into more detail on this issue.

Mar 07

Pavel Mayer on eXtreme Programming

This one is for our german-speaking audience: if you are interested in agile development methods (or eXtreme Programming in particular), but never had the opportunity to try it for real, you should listen to this issue of Chaosradio Express, a german radio show/podcast. It features Pavel Mayer, head of development at art+com.

From the show’s description:

Pavel berichtet aus seinen jahrelangen und mehrheitlich positiven Erfahrungen in der konkreten Anwendung von Extreme Programming im Unternehmen und erläutert, welche Schritte nötig waren, um diese Umstellung zu einem Erfolg zu führen, welche langfristigen Effekte das hatte.

Its a great and very insightful show, now I’d like to try XP myself…