I have always believed in software functionality being ZERO or ONE. It means that either it will work or it will not, very well..! people argue that software should be like phone - should be able to make calls ‘always’, it should be like your alarm clock - should go off at certain pre-defined time occurence or like car remote, will lock on unlock the car given it has batteries with enough power - it will always function - software is also expected to work like that. Well why not and when you put this question infront of software techie - he will either get frustratred or will be looking around twiddling his thumbs on thinking on how to explain it better.

Well, software engineers always take pride in showcasing the software they wrote and always take pride in improving it over time, wait a minute, we are just talking here about running the software after its written, then why improving it? it does what it’s expected to do, then why improve? Its very different paradigm, while other systems I just outlined up there, are expected to do precisely what they are suppose to do and once they are designed & manufactored, they don’t have any place for improvement, now given that, their new versions are better, but we live with the current one with their limited functionality - eg, car remote will lock and unlock the car, and hopefully, next version comes out with starting AC in your car as well, but if you have old remote then it will do only those two functions, and you are happy with that. Given the flexibility of software we always expect to add more features, and when those features are added, software workflow gets complex. Hardware features are almost always linear in nature, but software features addition makes software workflow branch out into different routes and then end up in same fashion.

Once software goes complex, we abstract out similar functional areas and split the software into smaller separate modules - but there is rarely a pause to relook at software and re-engineer it. A software built for a specific purpose and then with added functionality will not perform at same level. Companies tend to write or re-write parts of software every few months, to make it adapt to new architecture or deliver better performance. The change is unavoidable and managing it is the key - that also involves people understanding NFRs (non-functional requirements) around project life cycle. One of the key qualities of software is that it’s quality seems to detoriate over the period of time, actually its not true, extended functioanality makes its quality seem to detoriate, software becomes obsolete very quickly - it also does not hold good for new requirements - and given the nature of change - it leads to eventual failure.

So how do you cope up with that? how do you make sure that change does not lead to eventual failure? how do you make sure that change is tackled in a same way as you designed the software at first occassion? If we follow one rule of thumb - you need to have pause, if you keep driving your car without re-fuelling it tend to stop, choke and won’t start very quickly, unless you remove air from fuel-lines and make fuel flow again, this takes time! so pausing is always great. I have always believed in this quote - “I am not done, I will never be done, its the pause I cherish”