(In this SmartBits, Zulfikar Deen outlines “Operationalising is key “. The video is at the end of this blog)

You need to understand industry like Healthcare where the primary job is not  use a system. For example, if in Healthcare or Finance or if it is a Finance or Back office operations where you got an army of people sitting. They are  actually doing everything in the system approving doing all that stuff. In Healthcare a clinician or a doctor or a nurse their job is not to work on a system,their job is to attend to patients. Whatever system I put in here for them to use it should be  non-intrusive. It should help them but it should be non-intrusive. 

That is the first understanding , whatever system when a partner is developing, you need to understand that this is not a primary tool for them to do that job. Now what is missing piece when I work with multiple partners is, you got a piece of the solution, that is great, it works, fantastic, but that is probably in my view no matter whatever technology architecture you put into the system. It is probably 20% of the effort. 80% of the effort goes in, how do I operationalize .

What do you mean by operationalize? The same example of a doctor, you made a small change, or you delivered some small incremental benefit. How do I let the doctors know? I cannot bring the doctors to the training room. I can not get all of them in one single place, it is not possible , whether they are nurses. So the change we propagated, how do I first of all make it reach them? That is the number one most important difficulty. 

Number two is in terms of support. let us say if they have a problem, now how do the entire chain of support system works in to the place , because when a doctor sees a problem in the application, hopefully it’s not clinically problematic application, if it is a clinically problematic it is going to be very very challenging. But even otherwise if it is raised, then it goes to a local support team, then they need to understand whether it is a problem of networks or application or system or server hardware, diagnose it rightly, then take it to the team internally and understand if it was a network problem, it was a infra problem, or it was actually application problem. Even if it was an application problem, there are ten applications interacting with each other, which part of the application actually created the issue, then finally trying to figure out it may be because of this part of solution then  forward the issue to them, then they need to understand.

For them the challenges of partner is in what sitting, in what situation this real problem occurred. In any clinical situation I cannot recreate this inpatient. I cannot give the patient data to my partner. so it is challenging for them to understand that also. 

Now not only understanding, making sure that support makes the fix or they give a solution it propagates through all through the chain and goes back to that particular end user is extremely challenging. So training is a big challenge, support is a challenge and adoption is a challenge . 

You may roll out n number of systems, how do I ensure, say we have twelve thousand people using a system. How do we ensure it reaches to them? and people have the inertia, so you bring a new what takes them to change. it’s going to be very difficult until it is driven. how we ensure that is we need to drive through the line of business leadership, they need to identify the value for it, they need to tell yes it is important  so by then one small change done by a partner in an application by the time I ensure this is the way for all 12,000 people, it is an enormous task, so that’s why that needs to be understood.

I being on the other side  I would say these are fantastic too, I got a nice little capability on the record,put some button up there, I got some good old report coming up. Why can’t the users use it. This is a challenge, it is extremely difficult to take one and propagate to 12,000 and do it continuously, so that is a critical piece of operationalizing versus developing a solution, 

It may not be about the only change in the software. it is about a process change. For example,we delivered a solution where a patient can do a payment by themselves lets say for  a consultation. Now earlier my internal process are lined in such a way that patient will come they will come to the front desk and then go to the cash counter they paid everything.  They’re all trained very well as a process point of view. Now, I suddenly introduce a system. From my partner point of view it’s easy, I got a payment solution for you, just go pay for it credit card integration, it’s easy, but now how do we train all my staff to know that somebody actually already paid that means they should have the knowledge, how do we change the workflow within the hospital, don’t have to hit the front desk. you don’t have to go to the cashier counter, you can go to the nursing station. How do I change that process? When going to the nursing station, the nurse should know that earlier they will have printed sheet, that they paid for it from the cashier counter, nursing should know, now it may not be the case, they could have been paid online. So they should be able to know how to look up into system that this person has already paid. Now how do I identify this is a person, so there are quite a bit of process challenge.

---

In this smartbits, Girish Elchuri outlines about Design for testability.

Another practice that I follow is, during the testing times, the code is made to behave differently, though I am not altering the functionality. For example, in a particular workflow, I add a mobile number or an email id and I validate them later. There may be certain functionalities that would be possible only when you verify the mobile number and email id. These are the mundane things for which you cannot do the test automation. 

So what we do internally is when we are in the test mode and as soon as the mobile number is added or the email is added, we treat them as verified, we put that flag, so that we can do further testing in a much more efficient manner. That is just an example of how you can make the product behave differently for testability which is a much more efficient way of doing it, this is the first aspect.

Secondly, in a workflow-based product, you do certain things and for the third step of the workflow, you might need some information that is generated in the first and second steps. Normally, this will be visible to the user on the GUI but then on GUI-less test automation, it becomes difficult. So what we do is, in the testing mode, we actually generate this data as a file and then using the data which is generated as a file, we do the next steps in the workflow. This is another way that we make the code behave differently in a testing mode.

Thirdly, in a small percentage of cases, when the test is being run for subsequent steps, the code itself generates the test automation scripts. So what I do is instead of just outputting the data, I output a callable script call into the file and in the end, I just execute that file.

Since all these behaviors occur during testing, we can have a flag there saying “I am testing” and then what we can do additionally is make sure that these things are not run in production mode. These are some additional checks that we are doing. Again, that is where I see a developer helping the testing folks by putting this additional code to facilitate the testing.

In this smartbits, Raja Nagendra Kumar outlines as to what it takes to innovate.

Innovation can be classified as fresh Innovation, which does not exist or you have to make it better than what it is now.  In the context of clean code and technical debt, most of the Innovation can come from trying to make things better than what it is. A product can do billions of dollars of business. And if you are not innovating, we say few billions are actually hidden if you know how to innovate within what is existing, there are few more billions can get added because it could be that you may find new features, new way of doing it or you are able to run faster than the competition and acquiring more customers faster. 

Any product,  makes money by people adopting it and if you can reduce the customization time and improve adding more features, there are hundreds of features can come in and one of the techniques, I follow for this kind of innovation is to keep the code clean. Most of the time, because people are living with technical debt, patchwork,  being inefficient, they are not able to see what can be done better. Most of the time, there is so much of code so much pressure. They are not able to see what can be innovated and if you start simplifying this baggage, automatically you will see tons of innovative patents that can come in from the same product.

Sun Microsystems had one of the best products to be sold as a hardware company. They tried to be like a software company, but most of the time, because they got lost on the fire the solution itself got lost somewhere. There could have been a better way of solving it. We could have improved adaptability and reduced support ticket. Later we refactored unit testing and eliminated technical debt. We were able to find a better solution and that was patented and it is a patent now. 

That way most of the time, people living in a product world, if they know how to simplify or remove the technical debt and automatically it starts becoming simpler and then they will start questioning the solution. And this solution can give a lot more innovative ideas. 

In this smartbits, Anuradha Biswas outlines as to what it takes to make an software application accessible.

This is what she says:

“There are two parts legacy solutions and new apps and nowadays everything is about mobile apps. There are clear guidelines given out by different companies and some of it is universal like section 508 W3C WCAG and companies like Microsoft and Apple have something more specific to themselves.  All these can be used depending on your stack of technology and we need good designers who focus on user experience well to design it up. 

But again we have a lot of legacy applications we talked about and that requires a lot of re-engineering effort which means you have to go around hunting how to make it accessible and based on how much level of accessibility do you want to build in based on who your audience is? That kind of analysis is the main thing. 

The key thing is that if you design right upfront, social messaging is good and you get it out faster and your user community increases upfront and because it is catering to people with disabilities there is  a lot more awareness built about the product upfront and in the context of legacy applications it’s just more clean up to make your existing environment worthy of living .

You may also be aware that certain percentage of people have to be hired by a lot of organizations, government or people who work for government. People with disabilities have to be hired in their environment. How do you make it work for them? You have to go through that clean-up and there are tools mapped to technologies you have to use. 

If they are using off-the-shelf products for instance in the banking space, most of the core banking products have gone through the journey of revamping the solutions. Similarly, in retail take it segment by segment, they have re-architected it for accessibility .If you have to map it to your internal systems and at a system integration level software have to be made accessible.”

Shivaji Raju Expert Architect, Allstate Solutions in a conversation with T Ashok

Summary

Shivaji Raju outlines four key aspects of “What is Digital Testing” as testing on multiple browsers/mobile devices/IOT devices, testing services and non-functional attributes of cloud deployed applications.

---

#1 One of the aspects of digital testing is obviously testing on browsers and mobile devices. It’s not just about testing on one browser type or maybe few devices. The need has changed significantly now as products need to work on a plethora of devices. So you need to ensure that the product is validated against all browser types and all device types.

#2 The second aspect is in testing services, given the micro-services coming and service based architecture. It is therefore needed to ensure that services are validated, so you need to have an approach to test these services.

#3 In the digital world where you have various connected devices that may be on vehicle, home, or security devices. These need to tested with the endpoints, which could be services or backend components.

#4 The other aspect is cloud, with applications that are deployed on the cloud. So functionality testing might not vary significantly when compared to traditional on premise vs cloud, but non-functional attributes have to be validated. Attributes like your load, performance and security maybe compatibility need to be specially considered when it comes to the cloud deployed apps.

click to video

---

Raja Nagendra Kumar in discussion with T Ashok (@ash_thiru on Twitter)

Summary

Raja Nagendra Kumar outlines the role of refactoring, unit testing in producing clean code. He states this very interestingly as “Technical debt is fat, clean code is liposuction” and crisply explains the act of producing clean code.

The video of this “nano learning” smartbits video is available here.

---

Question: In our conversations you said  “Technical Debt is Like Fat, Clean Code is Liposuction ”.  A very interesting phrase it is, could you please elaborate?

This phrase has come out with the intention of producing world-class products from India, where every developer as he gets married to the profession, his duty is to produce products of world-class.

In that context, every day whatever code he writes, he is trying to produce a product baby and as more and more code gets added like the way the baby learns each day.  The large code also will start accumulating a lot of fat. If the future of the baby has to be better, you should know how to grow the baby or constrain the baby in a way and that’s where the clean code practices starts coming. 

As more and more large code starts coming into the product, on one side  product growth happens and on the other side, the clean code  practices should know which is relevant now, then start cutting the fat. The beauty of this approach is that it is not like  doctor operating on somebody, here the professional himself is doing to yesterday’s code whatever he has written is able to remove that code which is not relevant or modify the code to make it scale better. 

So, when anything is growing there is also a fat and that fat has to be transformed in a way where it is taking advantage of that and is leaping forward much faster. Otherwise, then the two options are : living with fat and not being able to run or becoming better professional by identifying the fat on time and trying to run faster. 

What do mean by clean code?

When we are trying to achieve something there are a lot of abstractions coming on the way, which actually no code is communicating to you. For example, you want to write a feature X and you have done it in X way and feature Y comes in, now to position this feature “Y, you need to have a creative thinking rather than fitting that along with X.

Now the product will have both X and Y. Instead of fitting them you need to make sure  what is affecting Y to be there in concurrence with X, the   engineer must listen to these clashes and see how to refactor it so that Y can go smoother. Unless we try to be a listener to our own challenges, what code is speaking, clean code will not come.

Most of the time people try to fit x y z as silos, they may work independently, but not coherently. My meaning of clean code is “ listen to the last code while adding new code” and that’s where people will start talking about what is the need or purpose of refactoring, what the purpose of unit testing is. They’ are not compliance. They are the ways for you to bring out a world-class product from your own daily experiences. 

click to video

---

Summary

Tathagat Varma in discussion with T Ashok (@ash_thiru on Twitter)

Tathagat Varma beautifully expounds as to what is Agility is. He says agility is actually the ability of an organization, in some sense taking a biological definition, somebody or a unit which has an ability to respond to the external stimuli and ensure that their own survival is assured.

The video of this “nano learning” smartbits video is available here.

---

Question: During my discussions with companies who say they practice Agile development, they quickly add as to what they practice is ‘my Agile’. Now I am lost. Are we abusing this term and using Agile as a fashion statement?

Agility to me, is an organization’s innate capability to survive and thrive in the long run. If we take a very biological definition of that, every organism is at different stage of its evolution. As a human being, if I am a toddler, I am in a crawl-walk-run stage. My agility when I’m crawling on the floor will be very different than my agility when I am running or walking or even flying for that matter. So, I think we have to really take the ‘horses for courses’ strategy. 

Some people might abuse it and that’s why they say, this is ‘my’ agile. If I take a very holistic perspective on that,  if there are five people or five teams with different capabilities, but they all follow the same process and say this is ‘our’ agile process, I would say something is wrong with that. What is being agile to one may not be of a similar or comparable perspective to another one. 

So to me, in a very simple sense, agility is actually the ability of an organization, in some sense taking a biological definition, somebody or a unit which has an ability to respond to the external stimuli and ensure that their own survival is assured. So agility is actually an ability of a body to respond commensurate to the external stimuli and make sure they remain alive, they are able to deal with the issues, they are able to grow. 

Now in the context of a company, we have heard of so many stories, for example, Kodak story is very popular. Where at one point it was the world leader and I believe had 1,500 patents and so on. Then the external changes started happening. Though they were actually the ones who invented digital photography, they were not able to leverage it. They had the capability to lead the technology in the next wave, but they did not have the inner capacity to take decisions and deal with the changes inside the organization. The same thing happened to Blockbuster. 

Organizations face the same kind of challenges, and ‘agility’ is simply their ability to understand and make a meaningful interpretation out of those external stimuli, and decide how they are going to respond back. For a large part that kind of works for me. In some cases, a visionary kind of a company which actually are not responding to it, but are initiating the change. They are the ones who are saying “we will set the pace there”. For example, I would say Tesla. Nobody is asking for a Tesla. When Tesla started making the cars, no government legislation is mandating it, no customers are asking for it, but they are setting the pace for it. iPhone changed the whole pinch and zoom and other kinds of features, it changed the definition of what the smartphones is all about. They were not following the trend. They were not responding to external changes. They were setting the change. 

To me, the highest form of agility would actually be the companies that have so good understanding of the market, very strong grip on the technology and are actually setting the pace for rest of the herd to follow. So agility, I would take is that kind of thing. 

Now, some companies might say “Hey, our definition of agility is so and so”. The way I look at it is if you are improving quarter on quarter, or year on year, you are agile by definition. One doesn’t have to be apologetic about not using the standard vocabulary. 

To that extent, I would agree that it is not a fashion statement but ‘horses for courses’. Yes, there is a lot of abuse we see in the industry where people don’t have a very systematic or intentional approach, and in order to not be very forthright about it, they just say ‘this is our blend of agile’, which doesn’t really mean anything because they, in all honesty, are not doing service to themselves. 

click to video

---

Summary

What it takes to “Build with quality” ? Girish Elchuri outlines that it takes a good modern micro-services architecture, a robust design that is modular, adopting a zero trust programming mentality and documenting specifications & design to enabling good test cases.

The video of this “nano learning” smartbits video is available here.

---

When we are developing a product, we all know that apart from the functional requirements, the quality requirements are also equally important. It is important that the product works as per the functions and also as per the quality, and that must start from architecture. You should have an architecture which is as per the current trends going with the micro-services so that it becomes much easier to test it out for each service independently.

Then we look at the design. You need to have a robust design, preferably in a modular way which will simplify the process of testing because it is always easy to test a small portion than a big monotonous thing. That is the second thing you need to look at; having a design which is very modular so that you can do a plug and play much easily including testing.

The third thing that you would look at is what I call a zero-trust programming. When you are developing or programming, you don’t trust anything. For example, even if you are getting parameters from your own functions, you don’t trust them, you just verify them once again. Basically, the way to do programming is to do a lot of validation of the parameters, validation of the context and whole lot of other things and when you know everything is right, then go into the functionality. This way, you are catching a lot of errors that are possible, upfront rather than in the logic and kind of having the runtime issues.

After that, you have to also make sure that you put enough effort to write the functional specs and design documents, because that is one aspect that people always ignore. Primarily, if you have a good functional specs and design documents, it becomes that much easy for the testing/quality team to design the test cases. So, I would say that you should have a holistic approach to quality rather than a very narrow focus of testing it post product development and then suffer a lot.

click to video

---