For today’s post, an article on software engineering techniques. And if you don’t have a background in technology, this first article is background which should make it accessible to you as well 1.
Often dependent on other mathematical calculations (eg. how many times does X or Y occur in this set of data), these structures must cover ALLÂ possible cases2. A bug, for simplicity sake, is when a situation that is not handled causes, either because the developer didn’t think of it or didn’t think it was possible to happen. When this occurs, the software can, hopefully, minimize the impact by, let’s say, opening a dialogue box and telling you something wrong happened. If it can’t, worse things happen depending how significant the missing case(s) were; software crashes, corrupted files and even computer shutdowns completely3. While operating systems have gotten much better at preventing the latter, there is not a day that goes by that one of us runs into these problems. What are we to do then?
As with many things, there is no one solution and certainly very few that are even easy. Â And as with any improvement techniques, one runs into the law of diminishing returns4. As my first job out of college was as a verification engineer (( quality assurance for hardware )), this is a topic that I often think about. Over the next few posts, will share you my thoughts on various techniques, their usefulness and hopefully share some new ideas in approaching product development.
- always good for leaders and managers to know what those pesky engineers are brewing up in the lab ↩
- Boolean logic (George Boole)(http://plato.stanford.edu/entries/boole/),Â (1815â€“1864) calculations are at the heart of all hardware and software. If some conditions is true, do this, otherwise do that. Or do this over and over until that value is reached. Or combine two signals and only turn on if and only if one is on. ↩
- eg. the MS Windows blue screen of death ↩
- Economic principle that can be applied to many other disciplines. ↩