For my current co-op job, I was asked in the interview this question:

Do you find feature-creep or bug-hunting to be the more time-consuming part of software development?

At the time, I said feature-creep. Each added feature exposes numerous other _missing_ features. Then the missing features become _bugs_ until they’re implemented. So the new feature remains unusable until the supporting features are all implemented.

This is true with any software, but I find it more of a problem on the web.

###Listings and Categories

Say that there’s a number of hierarchical categories, and a pile of photographs, each of which belongs to one of the categories. This could be stored as a filesystem, or in two database tables.

Say that you want to add the ability to ‘feature’ a photo inside it’s category… but you may also want to feature it in the parent category also, possibly right up to the root directory.

Adding the ability to feature a photo requires the ability to unfeature it, removing the database record. But you can’t just remove it without a prompt screen. On the prompt screen, there should really be a query that fetches the name of the entry and the name of the category for confirmation. Then on the public side, the featured photos need to show up at the top of the categories that they’re supposed to be featured in, etc.

This is all one big ‘feature’, but unless it’s completely implemented all at once, any missing part is a bug. As soon as it’s half-coded, more things reveal themselves as bugs so long as they’re un-implemented.

###Partial Rollout

One of the beauties of a web-app is the incremental rollout that it allows. If a bug is discovered, it can be corrected without everyone having to go and re-download everything.

The trouble with a web-app is the request-response nature of form-based interaction. There’s folks [working on that](http://www.adaptivepath.com/publications/essays/archives/000385.php), but the primary mechanism is still as it’s always been. This breaks up code. You’ve got a display case, a response case, sanitization, plus some mechanism for grokking errors. Not only that, but chances are, you’re trying to cover add, edit, and error all in the same block so as to not repeat code.

It’s rather overwhelming. And if you miss any piece of it, you’ve got a bug.

This stuff is a whole lot easier in Windows, even if you don’t [cheat](http://msdn.microsoft.com/vbasic/).

With PHP, there’s [tools out there](http://pear.php.net/), but any time something shows up that the abstracted tool can’t account for, you’re back at square one.

###Personal Apps

The time this is the worst is with the programs programmers write for themselves — the throwaway programs. Those often turn into bigger and better things than they were originally meant to be, and suddenly there’s a dozen loose ends that need tying up.

My dad mentioned this about a program he’s been working on for the Church, and I notice it all the time on this site. For example, I have a mechanism for submitting the quick news links on the left side of the homepage, but there’s no way for me to edit them. I could spend an hour adding this feature that no one will see, or I could instead play with something that would show up publicside, such as creating an archive screen for that content so that links other than the top-ten are still available.

It takes only a few additional seconds to log into phpMyAdmin and just edit the records manually when I spell something wrong or mis-form a link. So it will continue to stay unfixed. If it was for a client, I’d fix it. But as a hobby project, I’d rather explore the new areas…

So is it feature-creep or bug-hunting that’s worse? They’re really both the same thing. It’s just that the prospect of feature-creep can sometimes be enough to make new coding a rather intimidating process.

Mike

← Earlier Later → Posted at 11:05 pm to Programming.