I’ve been trying to figure out a way to synchronize blog software, and I don’t think I like the answers. I’ll probably keep using WordPress although its spam blocking features are not that great.

This is just an idea I had while thinking of software development in general.

For the purpose of simplicity, I chose to name the people who use an application “users”, although in my original idea it was more about customers. Not a big difference I guess.

Imagine that application users live in individual buckets (which would represent the applications they are running). As long as they stay in the bucket (the application runs), they are happy. Bugs in the application are like holes in the bucket, which allow the user to get out of the bucket. The larger the hole, the unhappier the customer. The more users hit a bug, the larger the hole. The more severe the defect is, the larger the hole. You get the picture.

In traditional software development, when users detect an issue with the application, they will report it somehow to the development team (now wouldn’t it be nice if software had things similar to sensors that notice when a leak occurs and starts to produce noise? Well, some software will “call back home” if the user allows it to; other software will just not ship with a “please shut up” button – would you get a fire alarm that you cannot silence if it went off by mistake, maybe from burning popcorn in your microwave?). Usually, one or more persons will try to determine the severity and dispatch some software develpers to fix it (and this is where the analogy became graphical to me: sometimes software developers look like plumbers who try to plug holes with their hands in an attempt to stop the “bleeding”).

Code releases are a mere way to move the contents from one bucket to a new one. Hopefully one with the known holes fixed, but sometimes with more holes as a result. Also, in the process of moving contents from one bucket to another you don’t really want to spill parts of the content on the floor, it gets messy!

In my analogy there’s even place for refactoring. The new bucket may be simply patched (simple bug fixing), or larger portions of it replaced. After all, if the bottom of the bucket is full of holes, one may choose to replace it with a new one.

How about rewriting the application from scratch? That would be a new bucket, hopefull a better and bigger one, allowing the customer to “grow” in it. As with the code release, a successful migration means no mess on the floor.

To push this analogy a bit further, software development is like plumbing. If your sewer line has a 1/32 inch hole in it, it’s no big deal. If found in time, it won’t have the chance to leave crap on your floors. If the hole is 1 inch big, you have a big mess (literally!) on your hands – and guess who gets to fix it…

In case you’ve forgot, I am a software developer after all.