Random Thoughts

Breezed past 37 Signals earlier, and stumbled across The top 5 red flags of software development. The flags are:

1. "Wouldn't it be easy to..." (the hidden cost of change)
2. "This shouldn't take long" (artificial time frame)
3. "Can you make this small change real quick?" ("small" and "quick")
4. "Before you finish x, could you do y?" (the mental costs of interruption)
5. "Let's push this today" (artificial scope)

I seem to face 4 of these red flags on a daily basis... The list is so short and succinct, just like a lot of the stuff these guys are producing. Good on 'em! Another post from these guys is Getting Real, Step 1: No Functional Spec, which raises the interesting point that functional specifications are all too often "appeasement documents... about making people feel involved". But when writing software, we don't want everybody too involved, especially those people that talk the loudest and code the least. At a certain level, after clarifying the goals of a project, it's necessary to Just do it! (aka the Nike software development process).

What started these ponderings was reading the latest Paul Graham essay on The Venture Capital Squeeze. Graham comments that there is "too much money chasing too few deals", and in any case, the cost of creating a new webservice business is getting incredibly cheap with commodity hardware and open-source software. But the big change noted by Graham is the use of dynamically typed languages (e.g. Python or Ruby) instead of C++, and the resultant reduction in programming effort. I think this last point is the most important - programming in Python can be extremely productive, and the customers certainly don't care about the implementation language. For a webservice, where the code remains directly under the control of the organisation, it is possible to keep working on the system after it has been deployed, and to make improvements as they are needed. This is not possible with the traditional model of delivering shrink wrapped software, where the costs of software changes are far more significant.

Similar ideas to those of Graham are also discussed in less as a competitive advantage, which is well worth reading. In a nutshell, build a system that people want before architecting a system that all people can use.

Paul Graham also discusses the impact of Sarbanes-Oxley on venture capitalists, and raises some interesting points. Phil Armour has also written about Sarbanes-Oxley, and the impact that the legislation could have on the software development process and the management of risk.