Design software and IT systems in the way we're designed: Organic Software Design

When we are given a problem to solve in IT (software or hardware), we have a few things in our laundry list to align for the the developed system. To name a few: Scalable, Extendable, Reliable, Secure, Fault tolerance, avoid Single Point of Failure (SPoF) etc. They're definitely absolutely required. But I feel that we're narrowing down too much on getting a good system that we most of the time miss the big picture. We try to build system that's unnatural within this natural universe we live in.

For decades, we have accepted the notion that whatever we build in IT are artificial and meant to remain artificial which is true but no one is stopping us to get influenced by nature - in fact - nature is the humungous system that survives through all these millions of years proving that it is reliable, scalable, fault tolerant, very few SPoF, you name it. Actually other science and technology disciplines have always adopted the notion to get influenced by "nature" the but in IT it seems to have very negligible influence.

It's time to think and see with a brand new way when we design a IT system - think to keep the design organic. One very important factors of design that's abandoned in nature is the "Distributed Processing". To be more specific, nature has created this world in the essence of distribution in processing and in risks while keeping a centrally managed control and monitoring system. Apache Hadoop is one of the system that became tremendously successful by keeping the distributed processing and distributed risks at the core of it's design while keeping a centrally managed control point. In Hadoop the Data node (highly distributed in processing and risks) and the Name node (central management) are example of that.

Another design philosophy of natural design is the Multilevel Security. Think about when we eat something or as simple as breathing, the first level securities are always in place at the interfaces thought they're not very strong and definitely don't intended to replace the real antibody system in side.

Below checklist can be run on a software or IT systems to determine if its design is organic:
1. The system doesn't consume or produce more data than it absolutely needs. There should be a quality ratio on how much data a system uses and how much data it absolutely needed to perform that process. Data derivation should be a must.

2. It recycles its own garbage data i.e. the recycling should be part of the design of the systems. When we design a system we mostly design to produce data but rarely design on recycling the information that is used by it. For example, when a program or process is no longer in need of any specific data then there has to be a way to recycle that information.

3. It collaborates to perform to its best i.e. it performs better or can do more when it's able to collaborate with other systems.

4. The multilevel security is in place. Traditional password based security isn't unnatural as when you break it once you're in full control. The natural security would like at the entrance of the system it would have a first pass of security (biometric authentication would be first choice) and within the system, every movement is monitored and an army of security process (just like our anti body, RBC, WBC etc.) would be ready to stop them while any suspicious move is taken. For that pattern recognition, profiling of user's activity etc. would be used to differentiate between good move and bad move.

5. The system should be intelligent in nature. This feature is required to build most of the above mentioned features but it should have more than just security, data recycle etc. The intelligent system may or may not be Artificial Intelligent (AI) systems but it ought to be able to intelligent enough to interact with environment like network quality, data quality, availability of dependent system and based on those it can upgrade or downgrade its features availability.

I've been thinking about this topic for quite some time so thought to start putting it to my blog if it can be taken any further. Also I would like go bit in depth for some of the check list items in future posts.

How much testing is enough for a software?

This is a million dollar question, especially when you're in a release crunch time and you found out that you don't have automated test suites for your, technically speaking , System Under Test (SUT). So, how would you define the testing boundary of a software? Like most other questions in this world, the answer is similar - it depends. It depends on what you're testing, why you're testing and most importantly how you're testing it- manually or in automated fashion. For the remainder of this post let me clarify what I believe is the goal of software testing which is to certify the behaviors of a software by labeling them if they work or they aren't; releasing it to the end user is a whole different ball game.

Let's first take the most important factor i.e. How you're testing. If you happen to have the fully automated test cases and test suits, my immediate response would be - Run 'em all. This is the safest and most cost efficient way to certify the behavior of a software. Like the Microsoft way, for MS Windows they execute the entire test suits and build it every night. If you can afford it do it, why take the chance. In Statistical world, we take sample because getting the entire population of data is unrealistic. Similarly if you don't have that luxury then you pick and choose based on the reality and expectations set for the software. I've explained it later part of this post.

Now the next factor is, when you're testing with the assumption that you don't have automated test coverage (or at least the time frame doesn't allow you to run the full automated test suits) and you have to test the software manually to certify it. If you are under pressure to complete the testing within a specified time frame then my suggestion is - go for targeted test. To determine what and how much to test, follow the Goldilocks' principle - don't over test it nor under test it, test which is JUST RIGHT. You'll always find that you can cover 80% of the software's feature by executing just around 20% of the test cases that you have and you would spend remaining 80% of your resources to cover the rest; check the famous 80-20 rule if you don't take my words - http://en.wikipedia.org/wiki/Pareto_principle. So identify that 20% test cases and run them and if you're asked to release your software before you are able to open the remaining test cases, go ahead and release the software. One important thing to remember, make sure you release it with a confidence factor attached with it - so for instance when you run 80% test cases of it, label it as "QA certified with 80% confidence". I know you can't release it to the external world with that tag but nonetheless you should have that number tagged with it to communicate the risk factor to the management. And most importantly, to cover your back.

The last but definitely not the least factor is- what you're testing. If you're testing the NASA's space flight module, you have no choice but to test it FULL and in that case you're certainly not told to test it by a certain time frame, but the release of it i.e. the mission launch date would be determined by when you're able complete 100% of the testing. Same is true when you're talking about medical equipment software or life supporting systems. But when you're testing a non-mission critical systems and missing a bug in the software won't take the company down (I remember once I logged in to Facebook and I was taken to profile of some one else while I could see certain photo album of mine within that profile; which happened in around 2010 and now in 2013, Facebook turned out as the de-facto platform for social networking - that bug was surely missed out by some test engineer but who did care about that) and you're given a deadline to meet, go ahead boldly with confidence based testing. One more thing about test coverage, there are some cases where you want to test both positive and negative test cases for a feature and there are cases where you're just fine of running only positive test cases (this is applicable for the software that are built to use in house and won't ever go out of the corporate intranet boundary)

The bottom line is, you always want to create every possible test cases for every features and run them all but you need to act based on the reality on the ground and don't hesitate to take calculated risks.