Rule #10 should really be rule #1

You might have stumbled across an article from Microsoft Technet titled 10 Immutable Laws of Security. It's a really good piece, and I often point newbie users to it for a quick primers on the do's and don'ts of security—it's well written, relatively concise and authoritative.

I love, in particular, Rule #10 on this list, which reads:

Law #10: Technology is not a panacea

I wish more people would pay attention to this rule—outside of the realm of security. The ready availability of technology, together with the "your safety is someone else's responsibility" attitude that pervades our society, has lulled us into thinking of technology in general, and software in particular, as something that has to be foolproof.

The problem is that software can only be as smart as the person who wrote it. Where more than one person is involved, the software they write is less smart than the sum of the intelligence of its creators. This means that the cost of development is not linear, but becomes exponentially higher with the complexity of the features that are being programmed.

Unfortunately, the complexity of a feature is usually inversely proportional to its simplicity from a user's perspective. The mere act of insert a key in your car's lock these days calls upon many high-precision features, both in software and hardware, that make the key and lock safe and secure, impervious to theft and, well, easy to use. But, to you, the user, it's just a key and lock. If somebody told you that getting the key to fit in the lock and the whole mechanism to work probably took several million dollars worth of development time—and, still, the end product is susceptible to problems like freezing—you'd think that somebody was either crazy or outright lying. If that somebody were an engineer, you'd probably be wrong.

If complexity makes development expensive, in a controlled environment it's relatively easy to do a bit of cost analysis and determine whether building something is worth the time (and money). A feature that saves, say 5 hours a month of customer support time but takes 100 hours of development time to develop must be considered very carefully—but the math is fairly straightforward.

The real—and hidden—threat behind not managing your development process well is, of course, feature creep and bloat. It is sometimes hard for a developer to refuse writing a new feature in a piece of software because of a number of overlapping problems: programmers like to program, and nothing is quite as challenging and rewarding as writing software that solves a problem—regardless of how real the problem is; it is difficult for a developer to make a user understand that because something looks simple to use, it isn't necessarily simple to write. And users (including the developers and their increasingly bloated development tools) are simply jaded by the impossibly complex, and yet affordable technology that surrounds them.

How do you solve bloat? With a firm, but simple and unobtrusive development policy:

• Analyze every addition. Cost analysis doesn't have to be complex, difficult or time-consuming. Simply ask the person who requests a feature to give you an idea of how much time that feature will save, and what benefits it will bring. Refuse to take answers like "it would help me greatly," or "I've had many requests about this." Always, always quantify these things in a way that can be measured.
  
  
• Estimate the cost of development. This is always hard, but it mostly depends on two things: first, have a clear spec from which to start. Have the developers discuss how a feature is supposed to work with the requesters. Second, get in the habit of coming up with reasonable estimates. Write down the steps required to implement the feature; ask your colleagues for opinions.
  
  
• Consider the long-term consequences. Even the simplest of changes can have disastrous effects on the long-term viability of your software. A feature that helps your users perform a task that has the potential for creating inconsistencies in your data, for example, is obviously a bad idea—that's an extreme possibility, but there are usually unintended consequences to writing any piece of software, so be careful.
  
  
• Always explain a refusal. One of my biggest pet peeves with the PHP bug-tracking system is that it is built with more sarcasm than care. Terming a bug "bogus" and providing a canned answer to a bug report are simply stupid ideas for two reasons: first, they don't add anything to the knowledge base built into the system, and second they discourage anyone whose skin isn't thick enough to take it under the chin from ever filing a bug again—what's the point if they're going to make fun of you? Similarly, you should never dismiss a feature request on a project you're working on simply because it's silly. Remember—the whole point of software is to enable users to perform tasks that they wouldn't normally be able to perform in the first place; therefore, the users won't understand how the software works, or why implementing a particular feature is a bad idea, unless you explain why to them. Educating your users also has the side benefit of improving the quality of their relationship with the software they're using—so that feature requests will, with time, become more reasonable and more useful.

On the subject of cost analysis, I think it's important to point out that there is a good way and a bad way of doing it... but that's the topic for a future post.