There is a well-known ratio in engineering; 80:20. This ratio crops up in software engineering too and refers to several rules-of-thumb that sound a bit flippant but in my experience are valuable real-world guides when managing software development projects. This is also called the ‘Pareto Principle‘.
The principal rule-of-thumb is that in the messy real world it is very often the case that 80% of users (or ‘stakeholders’ or ‘customers’; take your pick) are satisfied by 20% of the resources (time, effort, sleepless nights, shouting at each other) that are put into a typical software application project. What this means is that most of the time that is spent on developing the functionality of an application is for a minority of demanding users.
This ratio of time and resources can also apply to website security (see my previous posting ‘Spammers and hackers‘). It makes no sense to spend months building bullet-proof web applications if the data you are dealing with is of an esoteric nature and only of any possible interest to a small group of academics globally (as is the case with many of the projects I work on).
Trying to avoid the 80:20 issue leads one onto the POGE rule-of-thumb, which stands for the ‘Principle of good enough‘. Is satisfying 80% of users good enough? Is achieving 80% of the project goals good enough? A lot of the time it is, especially when developing prototypes and demonstrators and a good project manager will be brave enough to deal with the other 20% of users when they inevitably get irate, and to decide whether it is a good idea to spend time trying to achieve the 20% of goals that remain. Resources are always under pressure, and sometimes an all-singing, all-dancing holy grail software application is a bad goal to have, and it is better to stop well short of this and move onto the next thing.
All this sounds like it might be a recipe for disaster, and failed projects, but in my experience the opposite is true. The enemies of success in software engineering are unnecessary complexity, feature-creep and a failure to establish properly the user requirements and specifications of the software system at the start of any project. These enemies can be fought off by observation and knowledge of the very basic rules-of-thumb mentioned above.
Often, I have encountered project managers who have no feeling for these rules, and if I was to give any advice to a software engineer who finds themselves involved in a software project managed by someone who is unaware of these principles, it would be that the manager should be subtly and diplomatically guided towards the light. After all, it’s the coder at the coalface who has to make these things work, and there’s nothing worse than having the responsibility of bringing to life the crackpot vision of someone who wants to rule the world via the internet.
Of course, none of this should be confused with the ‘Scotty’ rule of engineering, which states that any estimation of task time must be tripled, and sometimes quadrupled, before talking to a project manager.