Category: General

Homogeneous & heterogeneous queues – Why it is important in software engineering
Photo credit

From very early age, software engineering has been borrowing heavily from manufacturing industry. We as software professionals has learned a lot from manufacturing systems/concepts such as TPS. No doubt, this has helped a great extent to the success of software engineering profession.

But there is one fundamental issue with borrowing blindly from manufacturing. That is manufacturing queues and software development queues are fundamentally different.

Do we have queues in software engineering???

Queue in this context is the line up of work to be completed. In software engineering, our queues are  sprint or product backlog. In manufacturing, queues are the jobs to be performed in a production line.

Manufacturing systems

All (almost) the manufacturing systems are based on “homogeneous queues“. What that means is that each piece of work (job) produced is similar or homogeneous. For example consider a Toyota factory. There will be multiple production lines but one line can produce only one type of vehicle at a time. If the line required to produce another type of vehicle, a considerable downtime is required to for the change.

Software development systems

In software engineering, we can equate a “production line” to the software team and queue to the sprint/product backlog.

Software development teams are never get similar (or homogeneous) type of work.  The first user story (or task) is totally different from the second user story. Therefore the software development queues are “heterogeneous queues” as one task is different from another.

What does this mean? Why this difference is important?

This simple difference in queues makes the DIRECT application of some of manufacturing concepts such as six sigma to software engineering is fundamentally flawed. The concepts which work in homogeneous queues do not necessarily work in heterogeneous queues.

For example, six sigma relies on the variance to identify problems in the system. Variance can only be tracked when the work is repetitive. I.e. when somebody produces the same thing over and over in the same way. We never get this repetition in software development.

If Toyota produces the software in their factory;

Imagine a situation where Toyota has been asked to produce software in their production line.

Photo credit

Engineers will set up the production line for story 1 – Let’s say to develop “User creation” feature. We will have BA workstation specifying the requirements, to be passed to UX workstation to produce prototype, etc. Finally it goes to deployment slot after passing QA.

When the second story (This is a bug to fix in “Global search”) comes to first workstation, that workstation requires a total change of set up. This require downtime for change of set up.

With this amount of variability, most of the manufacturing concepts/tools will be  ineffective.


One needs to be careful and understand this fundamental difference before directly applying manufacturing concepts & tools to software development.

Many misses this important difference between the types of queues which results in pressurizing development teams to deliver software like cars coming out of Toyota production line.

Obviously if the software teams are asked to develop same task over and over again, there will not be any problems

A big cautionary note

A big cautionary note here is that this does not mean that there is no use of adopting concepts from manufacturing or every manufacturing concept is not valid. For example lean concepts such as “inventory as a waste”, “eliminating waste”, etc. are fundamentals and they are still valid fully in software engineering.

My argument here is that as software professionals, we should not blindly adopt ALL the manufacturing concepts in to software development.


Importance of controlled failures


We try to avoid failures as much as possible. But there are certain situations where failures can be beneficial.

For example take a situation where things are not going according to the best possible path but it it is beyond your control to take it back to the correct path. There are few alternatives in such situations.

  1. One option is to fight all out and try to get it back to the track.
  2. Second option is to let it go & brace for the disaster.
  3. The third option is to led the way towards a small & controlled failure.

The purpose of this discussion is to explore the third option. First let’s look at the first & second options. If you use the first option & fight with all guns blazing, it would require significant amount of energy and time. After all it may be that you are fighting a losing war.The second option can lead to a total disaster & the chance of revival can be slim.  

What is a “Controlled failure”?

If you look at the third option next, there are many advantages. My definition of controlled failure is that you let certain variables to fail. Those variables are carefully selected as well as limited.

For example consider a situation where a project team is pushed to deliver under unrealistic deadlines over and over. You are trying to explain to the decision makers about the risk but you hear back every-time “our customers demands it and without meeting those demands company will not survive“. There are many variables to this situation. Examples are “Code quality”, “Functional quality”, “Developer burnout”, “Penalty of missed deadlines”, etc.

So in a controlled failure you open only the cards (variables) you want to play. For example it can be that you select the “Code quality” variable and let a internal deadline to be missed. (Normal option would be to ask the developers to work in another weekend). This can lead to decision makers to realize the importance of adjusting unrealistic deadlines and start working on them. 

The importance

The important aspect of controlled failure is the word “Controlled“. The failure should be such that it does not lead to significant loss and should be possible to control the situation through non-failed variables.

Some further examples for situation where controlled failure may help

  1. The request to improve code quality being ignored for a period of time
  2. Request for full regression cycle being ignored
  3. Certain teams are not preparing for the sprint demo & review & come up with all the excuses
  4. In personal life example, kids are ignoring the instruction to go to bed early

The natural tendency of  a leader is to work with the situation and get it back to track. It takes some considerable energy and situations where there are multiple of such scenarios. It requires leader’s heroic effort & it is not a sustainable strategy.

So setting up a controlled fire can help the situation!

For example connecting to above situations

  1. Let the next change request to over-run (than working late to finish on time) due to brittle code
  2. Let the staging release (before the production release) to have bugs which are noticed by the customer
  3. Let an important demo to fail
  4. Let the kids to take their own time to go to bed but get them to wake up exactly to the time you want next day

Concluding thoughts

Failures are good on long run if you learn the lesson out of it. A controlled failure will help to learn the lesson and “Control failures” are an important tool in management.

Eisenhower Box

4I was reading this post Eisenhower box from James Clear. (James Clear is one of my favorite bloggers and he posts wonderful posts every Tuesday & Friday)

Eisenhower was the 34th president of USA and he has used a simple technique to prioritize the work. Many of us struggle to prioritize work and the method used by Eisenhower (called Eisenhower box or Eisenhower matrix) would help us a great deal. It is so simple and just knowing it would help us a great deal.

Urgent vs important

This is the corner stone for Eisenhower’s method. According this classification, urgent things are not always important.

  • Urgent: These are the work which we need to act immediately. Examples are attending to a frustrated a customer, helping a colleague who is struggling on a piece of work, answering a phone call from unknown number, etc.
  • Important: These are the things which contribute to long term vision, objectives or achievements. For example a retrospective meeting is an important piece of work.

We normally don’t recognize or differentiate the urgency vs importance while working. The key to productivity lies on differentiating the above two aspects and we should treat & prioritize work based on them.

What Eisenhower box tells us is to categorize our work based on the above two factors. So it creates a 2X2 matrix. There is a guideline given on how to treat each box.

Eisenhower box


The above diagram is self explanatory and I am sure this can make a huge difference in our way of working and productivity.

Reference :

Photo credit:

Everything looks like a failure in the middle …

DohWe take decisions to improve ourselves from where we are now. This is common to any significant decision we make in our life. It can be that when we start a new job, new project or even when we migrated to a new country, we expect things to be better than it used to be.

At the start everything is fine and things are happening according to the script.

The new job offers a lot of learning and able to catch up on the technologies/opportunities we missed previously. The new country offers a lot better infrastructure, services, facilities, opportunities, etc. Everything is perfect and positive energy is overflowing. We are thrilled about the decisions we made.

After this initial period, not everything goes well. Things are not folding to the way it should be.

Now we feel that new job does not provide enough challenges or it is not going as per way it was described initially. The new country does not provide the value system which we used to be and we see negative aspects of the new culture. This is the stage where the reality takes over and the negativity slowly emerge. Then we ask ourselves  “Why an earth I took that decision?” We get frustrated on the situation very often and sometime curse ourselves for the decisions we took. We wonder whether there is a second chance where we can correct ourselves. In some situations we goes to an extent to label ourselves as a “failure” or a “looser”.

There is one thing we miss in this situation/context. This is not a situation which we need to get frustrated. This is not a situation where we should label ourselves as a “failure”. This is not a situation which is specific to us. This is a situation which happens to every individual, every organization and it happens every-time and everywhere.

There are many scientific and social research on this perticular subject. There is one such law called Kanter’s Law. It was developed by Rosabeth Moss Kanter, a Harvard Professor. In this law, she argues that we feel “Everything looks like a failure in the middle“. She further goes to explain how one should overcome this middle period. The advice she gives is that “Recognize the struggle of middles, give it some time, and a successful end could be in sight.

Further details can be found out from her post in HBR

Another relevant piece of work is called “The Satir Change Model” developed by Virginia Satir, an American author and a family therapist. It is a five stage model that describe how the change happens from one stable position to another over the period of time. You can see that it is not a straight line and there are many ups and downs in the middle. And most notable thing is that the performance in the middle period is far worst than where it started or before the change.

Satir change model








Illustration by Jurgen Appelo

The lesson to lean here is that as humans we feel that things will “progressively improve” over the period of time. What we don’t realize is that it does not happen in reality and there is struggle in the middle. World is not linear by any means for things to happen in straight. We need to have patience and push through this middle period.


Further reading

Today’s problem and Tomorrow’s problem
Photo credit:

I am a great follower of Jim Highsmith and I am still fascinated by his concept “Today’s quality and tomorrow’s quality”. Reference

I read this long time ago and had a post regarding this as well. But what I realized recently is that the concept of today’s … and tomorrow’s … is more universal than it seems from the outside. It is applicable for many things beyond just quality in the software engineering.

One contrary application of this concept can be found in problem solving.There is a general struggle when it comes to how one approach problem. Going with Jim Highsmith’s concept, there are today’s problems and tomorrow’s problems. We waste lot of our resources (let it be money, time, etc.) finding solutions for tomorrow’s problem.

For example if you are planing a software system to be used by 5 million users (like Trello) without even writing a single piece of line, then it is a waste. In a realistic example, many software designers are being pushed on concepts of “re-usability”, etc. before even a single piece of line is written. [I think the term “Use before Reuse” was coined due to this :)] Finding solutions for those are simple waste of resources.

We struggle in classifying a certain problem to be today’s problems or tomorrow’s problems. As humans we always like to think big and therefore pretty much liking to find solutions to tomorrow’s problems. So it is not easy to identify and categorize whether it is today or tomorrow in the outset.  As I mentioned people waste lot of their resources on solutions for tomorrow’s problem. Let’s see how.

The resources are wasted due to the timing of the solution. In simple terms, if the problem is today, then solution would be for tomorrow. If you implement a solution for a today’s problem, it will give results tomorrow, not today. You have the pain of the problem today anyway no matter what the solution is. If you are sick, then the medicine will make you better tomorrow, not today. If you have a “quality” problem in your piece of software, whatever solution to that would result in improving quality tomorrow, not today.

If the problem belongs to tomorrow’s then where the solution belongs to? It simply belongs to waste basket.


Note: Jim Highsmith’s concept of today’s quality and tomorrow’s quality is not about finding solutions for tomorrow’s problem. It is about keep an eye about tomorrow’s problem, which is always a good thing. Avoiding tomorrow’s problems and finding solutions for tomorrow’s problems are two different things.

For example if you exercise thinking that you will become obesity in 10 years time, that is good. All lies in analyzing the problem not finding the solution like in Lateral thinking

Readability Index – How good are you at writing?

All of us learn to read and write when we were in our elementary school. These two activities considered to be part of the very basic skill set of mankind. But the question is how good we are at reading and writing. Is there a systematic way to measure the reading and writing ability of a person? Is it possible to measure the readability in an objective way at all? Let us try to look in to these questions in detail.

If you look at a typical working day, a person may read and write many thousands of words per day. On the same line, there are many books being written every day. No of books being read by human population per day will be enormous. Let us look at some stats which I could found in the web.

Some Numbers

According to Google there are 129 million books written in this world. I think this stat was as at mid-2010 or earlier.

According to Verizon report in 2005, they estimate 2.25 billion emails per day. According to Radicati Group, there were 294 billion emails send per day.


You will probably agree with me that some books are easy to read and some books are not. The situation is same with the emails and any other document contain text. But the important question is what makes a book or an email easy or difficult to read? There seems to be many different views when it comes to answering the question.

It seems that readability depends mainly on the length of the sentence or no of words in the sentence. Also no of complex words being used in a sentence has an impact on readability. All of these factors can be objectively assessed and measured. (

There are factors which are subjective. The writing pattern has a very strong connection with the readability. For example how many examples you use in the text will affect the readability. Whether the text flows in a uniform direction (meaning that text in the start, middle and at the end is connected to the topic of the subject) is another factor. Whether you have a summary which explain the overall idea has a strong effect on readability. There are many other subjective factors which contribute to the readability.

Readability Index

OK, now back to the original question – Is there an index to measure the readability? To my surprise, there are not only one but many indices available. There are many organizations including Department of Defense USA using those indices to a good effect.  There are free online tools to measure the “Readability Index”.

One of the commonly used methods to assess the readability is the “Flesch–Kincaid readability test”. This test seems to be based on some empirical values as well as some parameters in your text such as “how much words per sentence”, etc.  Further details can be found in the following Wikipedia article.

Tools to Measure the Readability

Following are the some of the online tools which I found while searching the Internet which uses the F-K index.

What made to astonish was that Microsoft has inbuilt these rating into MS Word.  (May be MS have developed this feature to be used in their own documentation and somebody may have come up with the brilliant idea of integrating that tool to MS Word. Whoever it is, hats off to you.) I was missing such an important piece of information for this long. But the positive news is that now I can use the index to improve my writings. You can find the details in the following link.

One needs to understand that these indications are not perfect by any means. I couldn’t find a research on the accuracy of the online tools.

Let us now look at what these tools can do for us.

What can we do with these tools?

Can you recall the latest occasion where your email was not understood by the intended party? How many times you heard that “Sorry I understood it wrong”? It is not only emails which we encounter this situation. There are much more documents we write every day which contain text. How many of us complained that a requirement specification is difficult to understand?

All of these difficulties lead to many unproductive and frustrating hours at the office. If somebody converts the unproductivity to money, I am sure we are talking about billions of Dollars per year.

If we can use the above simple tools to check the readability our writing, we can save many billions of Dollars per year. Mind you, Microsoft has built the readability index to MS outlook as well. I really can’t understand why nobody promotes the idea and save quite many money.

When it comes to software engineering, it is not only about unproductivity. Imagine how many times we build a wrong piece of functionality due to the developers had readability problems in specifications. How much this world could have saved if somebody looked at the readability indices and their use?


It is up to us as professionals to use these indices and make our documents better. Anyone can save lot of money if bothered to check the readability of their documentation. The return will be immediate.

When it comes to software development, there is a different way to tackle the problem of readability. Agile methods promote the active discussions over the passive documentation with requirement owners. Still the writing is not something we can forgo today and I don’t think it will happen in near future. If there things are being written, there will be people who will read. Therefore it is our duty to improve our writing.

I wanted to test these indices while writing this post. This is how I improve my text. I use the Flesch-Kincaid Reading Ease score:

Reading Index Tool First Version Second Version Third Version Fourth  Version









MS Word





Some Information

# of Words





# of Characters





# of Paragraphs





# of Sentences





You can see that the three tools are not consistant when it comes to the values in the first version.  In the second version, I see that I have done some improvements in all the indices. I have added more text in the document but readability has gone up.

In my third version, I have decrease the readability. The post has grown. Since my second version is much more readabile, I need to improve the thrid version. With the forth attempt, I was able to increase the readability again. I got an average F-K grade of 8. That means this document can be understood by an average student. Fair enough rating for me. So I think I am done enough with the improvements and ready to publish.

Learning the Lesson

Learn from your mistake, which is the best way to improve yourself.

I am pretty sure that you will have heard that sentence at least once. Well we should be learning from our mistakes as it will enable us to avoid those mistakes again and also clear the path for us. But I was asking the question to myself “What is the best way to improve? Is there a better way to improve than just waiting for mistakes to happen and learn from them?”


Unknown to me (with obvious reasons), there has been many research happened around this as well as many people talked about this. To list few I found in the Internet.

There are few reasons that I can figure out why we should be focusing on our successes over the mistakes

Successes are proven but failures are not

When you consider the typical way of learning from mistakes, you will analyze the mistake and understand why it was made. Then make up a good plan so that it will not happen again.

There is only one problem with this. You have a plan not something proven to be correct. This plan can go right or can go wrong as well. There is no guarantee about plan’s success.

But if you follow the same process for leaning form successes, the plan you are going to make to follow is based on proven results rather than extrapolating a failure. This plan can go wrong at any given time as well. But if you are presented with two plans, one based on success and other based on failure, what will you select?

Many successes and fewer failures

When you reflect back your life, I am pretty sure that you will realize that there are many successes and only few failures. This may be against the surface belief that we do mostly fail and suffer, frustrated about our work life, etc. But if you detail each and every major incident happened to you, you will realize that success rate is much higher than failure rate. If failure rate is higher, I am pretty sure that you are not doing this job.

OK what this has to do with learning from success? Pretty simple. There are many learning points if you focus on successes compared to looking at failures.


When we try to improve, when we try to learn, the best way to do that is to start looking at our successes. Looking at failures would help if you have a plan is based on successes. Looking at failures would help you verify your plan from successes.