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, 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.

With PHP, there’s tools out there, 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

Statistics are fascinating. Some are a little bit scary.

If you send me an email or leave a comment on this site, I know your IP address. I can look at my logs and see every page you clicked, every file you accessed. In fact, I can even see, from the referrals, how you got to this page — by typing it in, searching Google, or linking from another page. Every webmaster has this ability.

If you’ve ever used Google, you have the Google Cookie on your machine — a unique number that they associate with your settings and preferences on their site. And also, it’s well established, with their search logs. They can create extraordinarly detailed personality maps for each computer just based on all the searches you’ve performed since last clearing your cookies.

And that’s fine. They provide me a service: fast, free, and accurate web searches. If my search habit data is entering a larger corpus of information that powers Sergey Brin’s science projects, great. However, the advent of GMail introduces a whole new variable into this equation. Now all those searches can suddenly be connected to a corpus of email, and also the name that was provided on signup.

Even this is fine. Google is a company that I trust. They’re a selfless organization that’s taken advertising online from ludicrous flashing banners to useful, relevant text links.

What’s worrying is what will happen when governments and lawyers suddenly realise that all this personal information may be available, just waiting for a subpoena. The recent attempts of ISPs to protect their customers from the MPAA prove that when it’s the Law versus Privacy, the law wins.

Which, generally, is good. I’d rather be safe. But it’s a slippery slope. Google may just be a privacy disaster waiting to happen. Yes, 99% of the drivel at Google-Watch is complete garbage. But this one point deserves attention. Being the custodian of anything takes responsibility, but perhaps the most when it’s information, which is so easy to share.

Anyone really worried about privacy shouldn’t be online at all. For all the security in email, you might as well have written your private information on the back of a postcard.

Mike