Archive for January, 2008|Monthly archive page

600 Line Design

Jeff Atwood recently posted the question What Can You Build in 600 Lines of Code? He points to the fact 37signals went live with Ta-da Lists which had only 579 lines of source. In actual fact this is not quite as magical as it seems, as Jeff goes on to say:

“They actually built the entire Rails framework first to support building small apps like Ta-da Lists. None of the required Rails framework code, nor any of the necessary stylesheets, JavaScript, HTML, and so forth, are included in that number.”

This got me thinking “Isn’t that a great way to design your software architecture?” If you can’t write your app in less than 600 lines of code then build separate supporting modules with clean and loosely-coupled interfaces so that you can. And if any of those modules require more than 600 lines repeat the process as necessary.

Of course for this to be a meaningful approach you can’t just cut code out of one source file and paste it into an include file. You have to design your modules so that they have minimal dependencies and provide functionality that is as generic as possible. Kind of like writing a mini-framework just for your application.

With this thought in mind I re-read Derek Sivers post 7 Reasons I Switched Back to PHP After 2 Years on Rails (which I first linked to in my 2007 September Web Roundup). Suddenly it seems clear that he applied the Rails model of a re-usable framework to his PHP coding and shaved 90,000 lines down to 12,000 (including all HTML templates).

Who Needs Final Decisions Anyway?

Raven Young recently listed 11 personal qualities in her blog post What Makes a Project Leader Successful? The list is taken from an interesting article at Slow Leadership entitled What Every Manager Ought to Know About Communication.

The quality that especially caught my eye was:

“They [good leaders] never make a final decision until they must. Until then, they keep their minds, ears, and eyes open and alert to possible changes that would require a different choice.”

“What a load of rubbish!” I thought. Everyone knows good project leaders need to be decisive. As I wrote in A Bad Strategy is Better Than None indecision wastes time and money, reduces project momentum and de-motivates your team.

Then I read the words again and realised that I had misinterpreted them. The crucial point being made is not that you should put off all decisions but that you should leave final decisions to the very last moment. In other words, make decisions quickly and keep your project going but, as more information comes to light, feel free to change your mind.

Having now thought about it I would be inclined to suggest that very few decisions indeed should ever be final. In my experience those who stick to past decisions even when they turn out to be wrong rarely reap any rewards for doing so.

Terse is Worse?

A while ago I had to write a C++ routine that checked whether all the characters in a string were hexadecimal. I quickly seized the moment as an opportunity to flex my C++ muscles and write the most trite routine I could:

bool IsHexString(char *sz)
{
	while ( isxdigit(*sz) && *++sz != NULL ) {}
	return *sz == NULL;
}

Once I had written it and basked for a few hours in the beauty of my code I started to feel quite proud of the fact that it would probably take anyone else at least five minutes to figure out how it worked. Then I realised that maybe, just maybe, that wasn’t actually a good thing. So I re-wrote it. This time I would create a vision of clarity: code that would literally document itself… Continue reading