Category: Software Development


Metcalfe’s law

How many web developers aren’t aware of Metcalfe’s law? My guess is that most know it very well, but many never knew it had been formalized.

Digg is my quintessential example of this theory in action. I was one of the first users of digg 2.0, hearing about it on their podcast Diggnation. The traffic was sparse at begin with, but it seemed to explode at a some point. I remember the debates about adding non-technology digg categories. Many of the the old-school guys didn’t want their culture to be tainted by the “normies”. It’s crazy to try and limit your potential, especially once the ball gets rolling.

The utility of a network increases exponentially as the users of the network increases. This applies beautifully to social web sites, but does not apply to utility or productivity sites, we shouldn’t think that by simply creating a web site, we’ll get exponential traffic. Sites like salesforce.com and basecamp.com have no use of Metcalfe’s law, they may try to wedge social features into the site, but it ends up looking out of place. To truly take advantage, you need to create real value from the social aspect of your product.

Advertisements

In software development there exist things called integration points. This is when any point in the process your working on makes contact with an independent system. You must also include the systems that that system depends on, so the count can quickly balloon. If you’re sleeping with X, you’re also sleeping with all the systems X has slept with.

Every time your dependent on a independent system, the risk of success of your project is reduced. Does your project depend upon a web service? A .dll file? A folder/file on the server? Network permissions to the folder? Each of these integration points can cause a failure in your project, none of which are in the scope of the changes to implement the feature set. Most integration points are unavoidable, but if you’re considering a particular architecture and are considering a web service (for example), think again. If you need to access the service from multiple systems, across networks, or on a heterogeneous architecture it may be the best option. But don’t do it without thoughtful consideration to the risk that you’re adding to all the future projects that require that service to be running, and running bug free.

It’s not the only way to identify risk for a project, but should be considered as a factor.

A good tool should…

“A good tool should recede, because life is a firehose”.

Life is a firehose: That’s how it feels sometimes, things come at you fast and you have to jump and dodge, and often times HANDLE IT. It’s tools that help us do those things, but if the tools get in the way of actually helping you then they’re a liability.

A good tool should recede: When you use the steering wheel in your car, do you think about using it? I’ll tell you, you don’t, you just use it. Whatever tools that you’re using to help handle your life should be as invisible as possible, i.e. it’s visibility profile should be minimal.

For software developers in the reading group, be aware that your software should not get in the way of people doing their job. If you’ve designed it well, they shouldn’t even notice it’s there.