Current mood:	optimistic
Current music:	Gravity - Vienna Teng
Entry tags:	geeky

Zoometry and software development
There are many aspects of software design that may be considered when creating a new application, library or communication standard (e.g. API, data storage format, wire protocol): scalability, flexibility, portability, usability, extensibility, localizability, consistency, measurability, interoperability, security, reliability, availability, maintainability, efficiency, etc. In theory it would be wonderful to account for every one of these in the original design but in practice we are constrained by market pressures and resource limitations. This makes it necessary to prioritize certain aspects in the initial design and iteratively focus on others during subsequent refactoring. I think that a good approach would be to focus on a very small number of aspects for each major release, adding functionality in minor releases (e.g. 1.1) and fixing outstanding correctness issues in revisions (e.g. 1.0.1). [My personal inclination is also to prioritize fixing correctness issues over functionality additions and design improvements.]

This leaves open the question of which aspects are best suited to being prioritized for the initial release. The important thing to realize here is that, for software that is not merely a clone of other mature software that already serves the needs of a particular domain, it is very likely that the future usage patterns cannot be accurately predicted. A flexible architecture is therefore of paramount importance. Designing for change should take top priority so that future changes can be made quickly in anticipation of user needs and market direction or in reaction to unexpected events. In keeping with this strategy, it is also a good idea to design the software to be easily upgradeable by its users.

The second most important aspect for nascent software is determined by the need for users. Software that isn't being used is no better than software that was never written. If you want your software to be used then you should take user needs and biases into account when designing it. Naturally, this means identifying your target user base, although you should be open to usage beyond that initial target. When selecting an initial target user base, it is a good idea to focus on a narrow set of users with whom you have some existing familiarity. Once you pick a user base, you should observe how they go about their lives and find a problem they regularly encounter that is worth solving and for which you have an idea for a better solution than they one they currently employ. Make careful notes of the constraints they face, the ease with which their current solution is applied and the utility it provides. This is your competition.