Monday, February 28, 2005

Software Development Priorities

This was my response to a conversation we were having in the TDAG group. Someone was looking for tips to reduce the size of their executable and then we got into a discussion of the merits of doing so. I proposed a list of priorities in developing a software project. Someone responded that none of those priorities should be sacrificed as they are all important.

Your priorities on a development project should be ranked as follows:

  1. Security
  2. Features
  3. Usability
  4. Performance
  5. Distributable Size
I am not saying to sacrifice any of those features, but it is a fact that there is a finite amount of time and an infinite amount of improvements that could be done for any application. You have to choose which to implement or you will never release.

Most software projects fail. In fact, the Standish group reports that over 80% of projects are unsuccessful either because they are over budget, late, missing function, or a combination. Moreover, 30% of software projects are so poorly executed that they are canceled before completion.

So it is realistic to realize you cannot implement every possible feature in a software project. Trying to implement every feature means your will over run your budget and your time, and if you spend too much time up front reducing the size of the distributable and squeezing extra performance out of it then you won't have time to implement your features.

If you must choose then I recommend you choose in that order:

  1. Make sure your program is secure (which is a bigger issue depending on the type of project)
  2. Add additional features (and make the features usable)
  3. Improve the performance
  4. Reduce the size of the executable (if you like)
That is a rough guideline. It never makes sense to try to optimize the performance of your application too early on. Additionally you should start with a secure application before adding more features. Trying to secure an application that has already gotten out of hand is a problem waiting to happen (Microsoft's security mandate being a case in point), and the last of your worries should be the size of your executable.

Now if your application only has 2 features, and there is no possible way for it to cause a security exploit (trying to think of an example, but I am having no luck), it is imperative that it fits on a 20K embedded memory chip and run in real time, then you might invert this order.

But in that situation the size and speed are actually requirements, and if you evaluated it to be sure it cannot cause a security exploit then you did in fact follow the priorities in order.

In the end, you can write your software however you want. It worked for Microsoft and Bill Gates got rich for putting flashy features (bells and whistles that most people don't find useful) first and security last. In fact it would look like that is their business model for IE (you need to upgrade your OS to have a secure browser). Oh, and did we mention the browser is free?

No comments: