No Silver Bullet

Software development is a design process i.e. it can have multiple solutions and the quality and usability of each solution depends upon its use case and implementation. Hence there is no right and wrong solution. Rather there is tradeoff between different solutions and the developer is given with the choice to select the right component for the right job. Right and wrong in software development is a vague concept. There is no silver lining between right and wrong solution. There is no silver bullet solution to software engineering solution.

A developer is given to choose from available solutions at every turn. Deciding to choose float over double, double over integer does not seem like a big decision at all. It all depends on our tradeoff. Do we want to optimize for performance or memory? Do we want to optimize for latency or throughput? Do we want performant or cheap solution? The decision is not so easy especially considering the fact that a wrong turn on any of the never ending flood of decisions makes developers backtrack their decision until they get a better result going through all hassle of benchmarking and unit testing to see only single digit improvement. Well that is software development.

Software are often compared with werewolves that are unstable and transform into an animal unexpectedly. However when you look into the nature of software, the behaviour itself is not that complicated given the complexity of the design of the software itself. Hardware is being cheaper with time since the manufactoring process is being pipelined and automated. Same can not be said about software, mainly because pipelining is not so easy, automation is difficult and we never know the best solution.

Unreliability can arise due to:


Most of the problems worth solving have complex solutions. Most of the time, it is developers job to simplify the solution by deriving some components and modules out of it. Still there is some complexity that emerges due to the interaction between the components. Despite the components being so small and simple, resultant systems becomes too large to handle and comprehend fully.


Software written once should be reproducible that it should work the same way in the future. However, due to the environmental changes, the software does not behave the same way as it was written. The new environmental changes could be hardware, software components, infrastructure, operating systems and users. Change in problem also creates some problems relating to confirmity.


Problem changes with time. Some problems grow larger whereas other problems change their nature altogether. To accommodate those possible problems, it is necessary to design software to be flexible so that we do not need to rewrite the whole software stack each time the problem changes.


The solutions for problems are by nature invisible and we can not for sure say whether a solution is better than other until we try out. As a result, there is no solution that we can say is 100% perfect.

Software development is a evolutionary model, it always grows and progresses incrementally except for some sudden bugs and rewrite of old software.

Types of Problems

Solved accidental problems

High level languages

Language should never had been a barrier in solving a problem. An english speaking and Nepali speaking person both should be able to solve everyproblem despite their language difference. But this is rarely seen in programming. One need to be proficient in implementation, design, syntax and semantics of a program to be able to code properly. This is one of the accidental problems in Software Engineering. This problem is being addressed recently and entry into programming and more precisely problem solving is going to be much easier and less prone than ever.


Sharing of code, knowledge, ideas is a common thing in research community and academics. However, that is not always possible due to language barriers. There are tools to ease the problem but the solution itself is not seamless. Much is being done on implementing common infrastructures like JVM(Java Virtual Machine), CIL(Common Language Infrastructure) and the Web, however it will be sometimes before we can be sure that sharing is at optimum level. At the end, what has been saved and shared is the time, the time which would have been spent in coming up with the same problem independently.

Hopes for the Silver Bullet


Buy vs Build

Brooks offers the solution of buying the solution instead of building it since it will be more efficient in terms of time and money.

Requirement Refinement and Rapid Prototyping

It is better to perform thorough requirement analysis than to wait for the problem dictate itself time and again. Also it is better to work in iterations of prototypes so that small incremental changes does not deviate the project way off from the target solution.

Incremental development:

Software should be grown instead of build. It principle is to build small working models and then grow it by increasing the features in the working model. This increases the moral of the workers as well enables easy backtracking in this top down model.


The goal of programming is to develop oneself into designers from problem solvers so that we can find out common patterns and design new solutions that are much better than existing systems, and sometimes, even creating new paradigms to look at the problems.