About Ali Khalid

This author has not yet filled in any details.
So far Ali Khalid has created 268 blog entries.

Mindset change to go Agile

By | April 19th, 2019|daily post|

Universal truths to ‘internalize’ to really go agile:
1 – We cannot estimate effort
Without accepting this, we try to ‘accurately estimate’ the amount of work and run into the same trap

2 – We don’t clearly know the requirements
Again, instead of focusing on getting the product out in the hands of the customer ASAP, we sometimes try to ‘refine’ the product

Off course this is easier said than done. To significantly reduce time to market a lot of enablers would be needed.

However, without the mind set change, all the tools in the world wouldn’t bring about the desired results.

#QsDaily #Agile #estimation #requirements

Testable architecture

By | April 18th, 2019|daily post|

When to ensure testability for your product?

While designing the architecture..

While mkst of us know this, very few actually see it through.

We build a piece of software and then decide how to test it,

Instead while designing it make sure you have ‘test probes’ in there.

When I worked for safety critical applications, we left test points on the PCB to check the circuit

Those points were not used for any feature of the product, but were there just to help test it.

So, testers get involved when the architecture is being designed,

Or the architects trained to ensure the system is testable themselves.

Testing monolith vs micro-service?

By | April 2nd, 2019|daily post|

What is the difference between testing micro service and monolithic applications?

First off, the definitions:

Micro-services: Software is developed as several small ‘services’ which can operate autonomously

Monolith application: One giant software with all services within the same software package

The fundamental difference for testing these is scalability and integration.

Micro-services are designed to scale up and down as users of the service increase, so testing this scaling up and down is important.

Secondly the integration tests become more important. Communication between these services is different from a monolith and should be accounted for.

While there will be many more subtle differences in testing these depending on your context, these two areas would always be of importance.Anything else you would add to the list?

DevOps and Culture

By | February 10th, 2019|daily post|

While DevOps is thought to be synonymous with tools and automation,

Actually, IMO, it has to do more with cultural transformation..

The ultimate goal of DevOps is to bring what we develop faster and more useful to our customers

While automation is certainly a big part, even more important is the culture.

The tools just fast track the thought process we have,

It’s the experimentation with different ‘thought processes’ which is the secret

I always quote “Companies to take ideas to in the hands of consumers the quickest will win”,

Because they can experiment easily, and don’t have to fear a failed experimentation.

Now if the culture is not there, experimentation will not happen.

Then all DevOps will do is to facilitate in getting more “crap” out of the production line, but just “quicker”…


#DevOps with #CulturalTransformation = Measurable business value

#DevOps WITHOUT #DevOpsCulture = Same old crap, just delivered quickly

The art of Resigning

By | January 25th, 2019|Management|

When I switched jobs recently, it was a very surreal experience. The stakes were high and there was a lot of ‘be careful’ advise. Luckily I trusted my gut and my values, which made it such a great experience.

Here’s how the story unfolds and some important lessons I would like to pass on to you.


It was another day at the office, I was working late trying to get some kinks out of a new test harness we were creating. I get a call from a company asking if I would be interested to explore a new position. I almost refused since I was not interested in a new job, but loved the caller’s demeanor and reluctantly agreed to ‘scope out’ the offer. Things started to work out and during the process, I felt this might work.

The tough decision

I worked in a matrix reporting hierarchy with multiple stakeholders. Over the years we managed to build great trust among ourselves. I knew if I’d leave abruptly that could harm the future goals for my team and lose momentum in the progress we were having. Plus I would have less time to ‘pass on’ the wisdom acquired. Also the timing of all this was very unfortunate. It coincided with some changes in the organization and how we operated and I could sense expectations from me and our team.

Against the advice I was getting from some, I decided to inform my current employer about the new position under discussion. At the time, no offer had been placed it was very uncertain what the offer would be. I ended up telling my manager, and some senior managers about the position. I made it very clear that no formal offer had yet been placed, but this is the blueprint of what’s going on.

I have to be honest, after the fact I felt this might have been a big mistake. But then I was able to reconcile what I did thinking I did what I thought was right, to preserve the relationship we had. And no matter what happens next, I’m glad I took a leap of faith for the good.


The biggest weapon you can have is empathy. It’s easier to feel empathy towards an individual near to us, but to a ‘company’, no way. Most people hate corporations and I would not blame them. But think about a company like this: a bunch of people like you and me who have to operate under certain restrictions. When I say be empathetic towards the company, does not mean the ‘LLC’ entity incorporated with the SEC, it’s the ‘people’ you have worked with.

I always say: The most important thing you will take away from your job is what you learned and the relationships you built

It’s hard to be ‘nice’ to a capitalistic face, who we feel will strike us down in the first opportunity they get. I don’t want to justify how most corporations run these days, but I do want to distinguish between ‘the company’ and the folks like us who work there. If you can’t come to terms with ‘the company’, think of the people you have spent so much time with. Make it easy and a pleasant experience for them. If you are moving on, it does not mean your relationship has to end with them too.

Hand over

After informing management about the potential offer, I also started to delegate and train my team on the few missing pieces that I had been handling. Again at this time no formal offer was given, or any formal transition had started. The training was not just for my employer, it was for my team. We had shared tough times together, I wanted to leave them knowing they would be alright and would be well equipped before I leave.

After some time finally the offer was signed off on. By that time it had been almost 2 months since I had mentioned the position to management, which gave them enough time to plan. Also gave me enough time to cover bulk of what I wanted to train my team on. With the news the formal hand over process started in which we did a lot of documentation, created videos and even some last minute features that had to be done in the test harness.

The goodbye email

Most people send a generic goodbye email on the last day with some general lines saying I had a good time. For me this was different. It wasn’t an abstract set of names I had known without any human emotion. These were people I had cared about, and would continue to care about since I knew these were good people and who cared about me in return.

The most precious commodity we all have is time, and our subconscious knows that. Whenever we see a genuine effort by someone in sharing their time with us, we recognize that and respond differently.

So instead of a generic email, I met each person separately and went through what I had learned and admired about them. For those I could not meet but we’re close to me, I created individual videos for them and sent those in emails. For some I wrote individual emails thanking them and extending them my support. What followed was something I was not expecting..

What goes around comes around

I was not expecting much of a reaction, but to my surprise I got many times more love from everyone. I might have never felt such an emotional experience before as I did in those few weeks. The belief I had to spread knowledge, love and good revealed itself so beautifully. There were so many farewells, emails, calls, follow ups, kind words and just unreal responses from my co-workers, managers and senior managers which I will always cherish.

After all was said and done, the tough decision I took did not look like much of a tough decision at all. It felt like it was ‘exactly’ the right thing to do.

What if it all went south?

What if it didn’t work out. My employer would have felt I am actively looking for new positions while I had no real desire or intention of switching? That’s where trust comes in. They way they trusted me, and I trusted them back, I’m sure things would have worked out just fine. They understood I did this because I care. Unless someone is a really twisted freak, they would want to reciprocate with the same care.

We constantly undermine the good in others. Our first impulse to every new thought is mostly of fear, scarcity and negativity. Learning to trust people can be the greatest asset you can have.

All boils down to trust

We humans take this trust thing very seriously, It’s in our genetics. I have to admit you don’t succeed at building it every time, but most of the time it works out just fine.

But how to build trust? There are no shortcuts, you cannot fool people all the time. Building trust needs hard work and genuinely being ‘empathetic’. You care for others, they care back for you. It’s just that simple. You just have to take the leap of faith. Trust in each other, trust the good in others and around you. There is a lot more good than bad. We all are just more interested in the bad than the good, hence we create and attract the bad.

Did I just get lucky?

It can be argued I just got lucky. I happened to ‘charm’ my way into a few good books, not everyone is that lucky, and this might not go so well again.

I knew this would work because this was not my first rodeo. I had done this experiment many times before, sometimes intentionally and many times unintentionally. I cannot say it has always worked, but it has always been worth it. Even when it failed, there were a lot of things I salvaged and helped me become who I am.

If you did something good and it fires back, remember, you did what you did because of what you believe in. What the other person does is with them. If you spread good, you WILL eventually attract good in return. Just have faith, miracles happen all the time.

Intro to Pace Layered Application Strategy

By | January 19th, 2019|Product Management|

Just like products across different industries are not the same, similarly software products are not the same either. While I used to understand that difference, but perhaps did not appreciate how different they can be and how they should be classified and treated differently.

Recently I came across Gartner’s PACE layered application strategy giving a new perspective which can be very helpful for managing multiple products or programs.

Premise of the strategy

It was realised that certain applications don’t change a lot and need to be more cost effective and stable than efficient, while others had to be delivered very quickly and change frequently. Both require different processes and should focus on different goals. A mobile app compared to a mainframe application are not the same. Clearly both serve very different markets and have unique requirements, hence no single strategy can be used for both.

In 2010 Gartner introduced a concept where different applications in an organization can be delivered at a different ‘pace’, meaning some would have shorter release cycles and are more flexible, while other applications would be slower and more robust in delivery.

Understanding which applications need rapid delivery and change and where this is not a requirement is important. Also applications under these categories should not be organized around each other since the required results are different.

Pace Layers

From rapid deployment and flexibility to slow releases and stabile products, there are three layers defined with unique characteristics providing the needed support to one another.

Systems of Records

Established applications which might be legacy or core systems supporting or managing critical master data would come under this heading. Changes are less frequent and slow, can be due to well-established processes or regulatory requirements. These applications would have the longest time span, around 10 years.

For these large and very formally designed applications the processes might tend to be more water-fall or incremental development like. Funding would come from capital investments with annual budgeting, since the changes are important, few and less frequent.

System of Differentiation

Applications that support the organization’s unique processes or capabilities which differentiate it from rest of the market. While these applications have a medium life cycle, the change required is frequent to calibrate according to changing business environment.

These applications might embody more modern design practices like SOA or cloud based, perhaps composite with old custom applications. Processes here might again fall more under Incremental development and somewhat waterfall with some agile and lean principles incorporated. Budgets might be a mix of capital and operational expenses since iterations are relatively faster and more frequent.

System of Innovation

Developing new ideas and quickly validating those proof of concepts requires very different processes. These applications, revolving around ‘new innovations’ come under system of innovations, characterized by very short life spans and flexible / ad hoc processes.

Agile and lean practices would be more applicable here with latest technology stacks and architecture trends for these lightweight applications mostly serving end consumers. Budgets would come from innovation funds or departmental budgets, since these are supposed to be very frequent releases and in some cases throw away features.

After we have established the products falling under all three categories are different in the required culture, development methods and skills between them; the question is how do we organize these systems and build some coherence and synergies to manage them in a holistic fashion?

Pace layers are focused on business processes, not any particular business organizational model. So there can be many ways in which the organization can be setup, Gartner suggests to use the Hub and Spoke’ model

Hub and Spoke model

Hub-and-spoke model is common in a lot of other industries like transportation. Essentially the ‘hub’ holds a central position serving ‘spokes’ originating from a hub.

Let’s take an airline’s example wanting to support 10 destinations, with a hub and spoke model you need only n-1 = 9 routes to serve all 10 destinations. In contrast, a point-to-point system would need 10 * 9 = 90 routes!

What would this mean for managing software teams? The central team (hub) would focus on common applications that might be shared among different business groups. Applications having common governance, planning and management functions would be ideal. From the pace layered architecture, the ‘system of records’ would comprise of the hub.

The idea is to preserve coherence between layers, at the same time provide enough distance for the different record structures to work in their own cultures and operate independently.

The Hub

Applications typically having a predictable pace of change, where cost optimization or efficiency is more focused on instead of quicker and costlier solutions. Therefore the changes are predictable and long-term.

The hub does not govern any of the spokes in any way, rather it acts as a supporting function, a common platform which the spokes can use. The layers since should operate with very different goals, cannot report into one another rather would have separate reporting lines.

Systems of Innovation and Differentiation

The applications would be fundamentally different focusing more on flexibility and speed instead of predictability and control.

Differentiation layer applications, in many cases, might be a part of a larger system of records and therefore would require integrity between these two layers to work correctly as a whole.

Innovations are more around future concepts and developing POCs, therefore they can be an entirely separate group within the organization or even with a team outside the IT setup. The key here would be to deliver at pace and closeness to business for catching on changing / new ideas.



A common mistake large organizations have is to use a single silver bullet process institutionalized across all products. Understanding not all software applications have the same business objectives, in turn meaning one process cannot be the best fit for all. Speed and predictability are two main differentials which fundamentally change how processes should be designed for these products and achieve the varying goals for these products.

Products across the Pace layered applications architecture will have very different cultures and operating models and should therefore have independent reporting lines to the business. However, some synergies will exist, by the hub exposing some common platforms which can be consumed by differentiation and innovation products.

While Pace does not deal with what ‘kind’ of development process to follow, it provides a very good framework for program management looking after multiple product groups. This in turn allows development process diversity across products to use what is the best fit process for achieving the product’s business goals instead of imposing a single ‘best practice’ on all.


Automation and reusability

By | January 16th, 2019|daily post|

Automation helps by doing repetitive tasks efficiently

What happens when your code is not exactly ‘reusable?..

Automation engineers sometimes are trying to script for the immediate test scenario

And forget the whole point of automation was reusability.

This is different from a script breaking from not have good selectors..

Writing similar code across the project in multiple classes / files

And again repeating that in mulitple projects across one on multiple products

So make sure to keep each component of the framework reusable

As reusable as possible, not for just your project, but if synergies exist, between projects as well.

The concept of ‘loosely coupled’ somehwat captures this idea.

#QsDaily #Automation #FrameworkDesign


More on the subject here:


Pillars of Automation Framework Design

Using AUT’s JavaScript methods

By | January 13th, 2019|daily post|

A couple of ways to cope with web browser version updates,

Using the AUT’s own JavaScript functions is one way to mitigate issues, let me explain..

Depending on what type of application you are using, there can be custom JavaScript code running on your AUT

For cases like on interacting with a certain control a custom written JavaScript method is called to collect some data and pass to an AJAX call.

Think about it, wouldn’t the developer be using some methods to write data in the fields? Or read data from them?

In few cases they are the same as the Selenium library would use, however in a few cases there would be some custom methods,

Written by the developer or provided by the framework.

For instance, on entering data in an certain element on the web page, a JavaScript method is called parsing the data and sending an HTTP request.

Now instead of trying to interact with the element through Selenium / other library, call the JavaScript method,

Which is going to be called anyway on the mouse click / enter event, but can save you a lot of grief if Selenium has a hard time interacting with the element due to a browser update etc.

Us Vs Them, or being empathetic

By | December 29th, 2018|daily post|

Working together with teams can be difficult sometimes,

Instead of treating the situation as ‘Us’ Vs ‘Them’, here’s what I think:

All of us have similar desires, dreams and fears.

And each person is operating under certain limitations restrictions imposed by the environment they are in.

Mostly their behavior is driven by goals and limitations around them.

Being empathetic and really trying to understand thier limitations makes things a lot easier

It’s hard, time consuming and requires more attention,

But has lasting results and builds trust.

Granted cannot mot be done for every situation,

But where taking this hard route possible, this can do wonders,

Time and again I have experienced exponentional results with this, more on that in a separate post.

#QsDaily #Positivity #Empathy

Why time is the most important asset

By | December 28th, 2018|daily post|

Time, Money, Freedom; What’s more important..

Time is the single most valuable asset, here’s why:

– There is more than enough money and resources to go around, we’ve trained ourselves to believe in scarcity and spend our whole lives chasing it.

– In this age I suppose freedom is a relative term now, someone is more free than the other based on their circumstance,
– But NO ONE is absolutely free of any consequence. You are as free as you ‘think’ you are!

– The asset which is truly scarce is time.
– It cannot be replicated, or bought. A second gone is lost forever.

Successful people utilize their time to the fullest. The one to manage time the best will win.

An inspiring video from Arnold Schwarzenegger where he talks about his success and how he managed his time shared below.

#QsDaily #time #success