( Zulfikar Deen  on “Expectations of owners and users”. The video is at the end of this blog)

Let’s start from an end user. For end-users the solution makes their job easier, more productive and efficient. Any solution which gets delivered to them, they expect them to work hundred percent, there is no full thought process of DevOps and my side of the view here. I can’t have half-baked or DevOps. I got something working for you , let me know how it works, then I will build it better for you, these half -baked  doesn’t work for me. When the solution goes to my end user, it has to be working hundred percent. If there are 10 features that have been planned and if three of them are working, then all the three features must work hundred percent. That’s an expectation.

Secondly, the end users are expecting  and treating the whole solution as a black box, they don’t differentiate whether it’s an application, it’s a front end, it is a network or  it is a backup. If it doesn’t work, it’s of no use. We need to ensure that the whole solution looks at everything and one can’t have a siloed view that it’s my solution.  For example if we are rolling out a partner solution to our end user or to an internal built solution, if it doesn’t work then even if the reason is not related to the application the users would still say this application did not work.  It’s the responsibility of the whole system to ensure that this whole thing is tested properly and taken a holistic view. 

As an IT organizationor or  as a CIO organization when the  partners are dealing with us, they cannot treat IT organization as their customer because we are not their customers. We and the partner together are servicing our business so they need to co-ordinate and work very well with us to meet the expectations of my business users. Often they make a mistake treating IT organization as a customer. We are not their customers. We are  working on behalf of them taking their solution to the end users. Hence, partners need to support us and empathize with our team.

From the business any system that  is rolled out, it has to have value in some form. Whether its improvement in clinical quality or reduction in my operation cost or make my people more productive, There has to be some associated business benefit. 

The problem before and after is , before we take up solution to business, I should be able to prove or I should be able to at least articulate along with the partners how this will help the business in those parameters whether it is clinical quality or compliance.If  it is compliance, It is critical.GST it has to be there, there’s no other choice. It could be compliance or clinical quality or operation efficiency or revenue.I need to be able to prove it is helpful to the business and the system should have the mechanism to show matrix around this.Many times, that’s a key piece we miss in many software.The matrix of the system, whether it is in terms of adoption, in terms of usage, in terms of usability in terms of business metrics. All the matrix should be bid to the system. 

When putting the system in place, when my business asks the questions such as how are we doing? what is our ROI in the last one year? Here, I shouldn’t be scrambling that I got the system in place and people are using but what’s happening is not known . If I can’t figure out or produce some reports to figure out how the system is being used. It’s of no use.  Such aspects need to be baked in the system. What’s my adoption level? What’s my business metrics? they need to be part of the system. So for the end users it is about the solution. For the business users it’s about the adoption and the business metrics out of it.

Summary

Corners are interesting as they are subtle, invisible really. They could be complex with many things that intersect and therefore display an unique behaviour. They may not necessarily be symmetrical at ends, nor be similar to behaviour in the middle.

As a developer focused on solving a problem for typical or generic cases one may not see the interesting extremities. For example we do everything right for a system in normal state, but miss out what happens when it is brought up the first time. This article outlines eight heuristics I discovered when testing a product that we were building, a SaaS platform. The heuristics outlined are based these aspects : Time, Lifecycle, Transformation, Position,Space, Size, Linkages and Limit.

#1 Heuristic based on TIME

The first time when something is used. Thinking from the perspective of time. Doing something on an absolutely fresh system. Creating the first project, registering the first user.Doing the final action, removing an user. First time when a transaction is done on a empty system. Purging a system of content, signifying removal, the end.

#2 Heuristic based on LIFECYCLE

Repetition of system states in terms of cycling through. Starting off, then doing activities and coming to an end. Then restarting and continuing. A workflow that is half done, suspended and then continued to finish. Finish by abandoning it  or ending with to a logical closure.

#3 Heuristic based on TRANSFORMATION

Changing something like say formats, views an act of transformation. In the case of UI, this could be relate to responsiveness like reaching the extremities of views? In case of content transformation, reaching the extremities of too large or too small or null content being transformed.

#4 Heuristic based on POSITION

Looking for interesting behavior in case of the elements that are right at start or end. What happens when elements in the middle move to either ends?

#5 Heuristic based on SPACE

The nation of space as when contents close are far, shrunk or expanded, especially when at extremities of too close or distant, too small or large. An example of  responsive UI, when screen is shrunk or expanded.

#6 Heuristic based on SIZE

The notion of volume, size when some is really small or extraordinary huge. Say uploading super large files, or really nothing or rally small ones. In case of display, showing tiny/large content/diagram, maybe via zoom?

#7 Heuristic based on LINKAGES

Using notion of  linkages like  1-1, 1-N, N-N or thinking in terms of increasing chain length like 1-1-1, N-1-N.   Could linkage integrity be violated when N=0 or when chain is long? The notion of propagation especially in longer chains with differential N.

#8 Heuristic based on LIMIT

The most commonly understood that of min/max, the typical extremities of value given an definitive range.

T Ashok, @ash_thiru on Twitter

Summary

When you are building large systems that transform other’s business, stay defensive. Don’t assume that every action will be done, be it by a human or by another systems. Some of these can break the chain and the business.

Last Friday the SmartQA site went into a blink, inaccessible, socially distanced to use the modern terminology! A story of how some simple choices made by software developers while implementing an automated workflow can bring down a business, especially when humans in support decide to become inaccessible.

Let me tell you the story. The site smartqa.org became inaccessible last Friday and after a few minutes, I discovered that the site was not down, but unreachable. That is when my tryst with support started. Telephone, chat, emails were unanswered and after five days of relentless pursuit it was sorted without the help from support. So, what was the issue and what can we learn from this?

Well, the issue seemed to be that the domain expired on Friday
despite it being renewed many weeks ago. The renewal process seems to have been botched up. A process that is completely automated, without any human intervention. What went wrong? After five days of being at it, I was given to understand that current domain registrar has possibly shifted his business partnership of buying domains to a different bulk domain provider. This required the new bulk domain provider to authenticate every domain owner with the current registrar. So an email was sent by them to each domain owner (I guess, as I got one) which was supposed to be responded to by a certain date. In my case, the email seemed to have found its way into the ‘read’ folder somehow and therefore I did not respond by the given date. So, on the date of domain expiry, the site went blink. All because of ONE email that I did not respond to! The email that somehow did not show up in my inbox. This email was never resent when response was not received. So, I as a customer never knew about this and my business stopped. 

All because of ONE EMAIL THAT BROKE THE WORKFLOW of automated renewal! Know what is the cost of renewal? About Rs 1000 ($12)!
Just imagine if this has been an online business. $12 shuts down the business! All because of a developer making a choice, of assuming that a critical action in an automated workflow is done. Never contemplating what if it is not done, how can I ensure that it is indeed done? In these times with businesses becoming fully digital, these kind of simple choices can break a business. In my case, I pursued the problem relentlessly, by analysing, by talking to a lot of people and finally a good samaritan helped me nail the problem and then poof, the solution happened. We all know that a problem is a problem, until the solution happens. And in most cases, the solution is simple!
On a lighter note with support going into quarantine, the site socially distanced, I went into the ICU 🙂 A happy Covid19 story this turned out to be at the end.

“A typical accident takes seven consecutive errors” quoted Malcolm Gladwell in his book “The Outliers”. In the chapter on “The theory of plane crashes”, he analyses airplane disasters where he says that it is a series of small errors that results in a catastrophe. The other example he quotes is the famous accident – “Three Mile Island” (nuclear station disaster in 1979). You may want to read a nice article that I wrote on this <Seven consecutive errors = A Catastrophe>.

When you are building large systems that transform other’s business, stay defensive. Don’t assume that every action will be done, be it by a human or by another systems. Some of these can break the chain and the business.
Have a great day. 

( In this SmartBits,  Srinivasan Desikan outlines “The evolution of test“.  The video is at the end of this blog)

Earlier days we used to have three different teams – configuration management team to build the product, development that develops and hacks in software and test team that tests the system. The configuration management team will make the build, do whatever checks that are necessary, build it and then give only the binary version to the testing team. This was called as the build ball, they roll with it, then test it and report problems.

Earlier days 30% of the problems were mainly because of the configuration management itself. It was not the developers who were introducing the defects. It was the configuration management team, which was introducing defects by wrong builds. The build was not validated properly, build validation evolution started from the testing team. Configuration management team asked the test team to test whether the build was correct or wrong? The testing team gave them a suite which was called a sanity suite or build verification test and the build team used it, validated the build and gave it to the testing team which resulted in quality improvement.

Whenever there are boundaries there will be more problems lurking around the boundaries. Always the problems occur because of the intersection between the development and configuration management, configuration management and testing and also the boundary between development and testing.

These problems brought a thought process about a new evolution which is called DevOps. Which means starting from the development all the way to the operations, everything should be automated so that there are no boundaries left. If one has to automate something it has to start with test automation, again the evolution started with the test engineers. The build got automated scripts, the binary ball they got automated, the testing that ensures the build is done properly was automated and the functional testing as well as the build of the developers also got automated. Good amount of code that is coming nowadays are auto-created code. Here they check the return values and add more exceptions code to it. Eventually that also got automated.

We are entering the DevOps model where good amount of that is automated and people are really needed only when it breaks and only when more value needs to be added to the automation. We do not deliver any more to code or we do not deliver any more to build. We don’t deliver any more to testing but we really deliver to the purpose of the whole thing, which is the end result. That’s where DevOps is taking us to.

( In this SmartBits,  Arun Krishnan outlines “Challenges in testing big-data applications“.  The video is at the end of this blog)

“I understand that big data is characterized by three V’s volume, velocity and variety with the data formats classified into different categories of structured, semi-structured data and unstructured data, and these are acquired from a variety of sources. What are some of the challenges or issues that these pose to validation?”  Dr Krishnan’s answer to this question is below.

The Three V’s Volume, Velocity and Variety actually depends on who you are. There are 4V’s and 5V’s as well. Some of the definitions around Big Data are  volume, variety, velocity but in a true sense all these are relative. 

There are people who say 1TB of data and above is Big Data. The best definition as of today is one bit more data than your system can handle. If there is a system with 8 GB of memory and there are 8 GB and 1 bit of data if this can’t be loaded into memory that is the Big data and then it needs to be  broken into chunks.

When we talk about Big Data, we need to understand that it is relative. What Big Data is to a retail chain where there is a point of sale data coming in every second or every minute need not be the same for a company which tests the software where the focus is on looking at test results coming in every few minutes or every hour.

HR data from a retail chain perspective is not big data, but from an HR perspective, yes they do, they have a variety of  data sets coming in and they got to pull it all together The trick is in bringing all the data together and then get deeper into it. It’s not about the data quantity. 

Data are in different forms like structured, semi-structured or unstructured. How we tie it all together and how we gain insights from them, is analytics. Another example is one of my students had been to an internship at an Indian public sector unit, and there he was asked which are the best colleges to hire from. This is a huge amount of data that one could gather. This student did something really simple and straightforward. He took the average scores for every College on performance and he took the average scores on that amount of time that college folks have spent in that organization. Plot the data with  Y-axis as performance and X-axis the amount of time spent. Then arbitrarily, take two values one parallel to the x-axis one parallel to the y-axis. It suddenly has four quadrants and interestingly enough all the IIT’s came in the bottom quadrant, which is low retention and low performance. Very simple things can be done in analytics but the idea here is tying these two pieces of data together.

Even for testing it is important to figure out how we can tie real-time data coming in from devices, what we are getting in from server logs, as well as what Developers might be putting as comment,  and then use that to infer what would be the issue and then build the test cases.

( In this SmartBits,  Arun Krishnan outlines “What is big data/analytics?“.  The video is at the end of this blog)

Analytics is a buzzword these days. But quite honestly,  we have been doing analytics for a long time. If you think about it, the animals flight or fight response is analytics. It uses its past experience, like if the grass in Savannah is moving, is it because of the lion or wind?

The reason it has become so buzzwordy is primarily because of digitisation and the explosion in terms of compute power that we now have at our fingertips, and also the ease with which the data gets processed. Twenty years ago grid computing concept was quite prevalent which then slowly morphed into Big Data and now the buzzword is AI. Everybody wants to use that term and so it is essentially a way to look at patterns within data and take meaningful decisions. This is how analytics can be looked at in the current scenario.

We all think and assume that businesses have the best systems, but that’s not the truth. Even the biggest organizations are still very spreadsheet oriented, though there may be specific departments like Sales or Finance that make use of analytics to a larger extent. Again specific Industries like Banking and Finance sector have been using mathematical models and tools to forecast.

There is a lot of talk but it is more than what’s on the ground. Personally I am a big believer that the more we crunch data, the more we can identify patterns and the better outcomes we get, and some companies do it really well.  Classic examples would be Amazon, Google or Facebook. They are good at it. But there are industry segments where there is a lot of scope to use analytics for betterment.