The life of a software developer, who can never write a program as efficiently as his manager wants it, for the first time.

During one of my friendly conversations with my father, who is a layman in terms of software development, he asked me, why I had been working almost for a year to develop a simple application called Payroll, which he had always paid from his pocket directly. He felt that, I must work on improving my efficiency as a programmer, as my manager tells me all the time.

My blood was boiled, and I felt like opening the 100s of pages specs documents that undergo 10s of revisions, or the long spread sheets containing 100s of earnings and deductions to explain the complexity. But the fact of the matter is, he doesn’t understand most of them, and I also don’t know everything in them. So I thought, why wouldn’t I explain him through a simple story, why it takes so much time to develop a simple software, in general, and why there is a need to change it quite often?

Once upon a time there was a product manager, who found an intriguing opportunity and a huge market potential, to develop an application for sheep farmer, which helps in counting their flock at the end of the day, to check none of the sheep are missing. The app is quite simple, just count the sheep in the pic that the farmer uploads, and display the number.

The developer feels very delighted for being paid in lakhs, for writing such a simple program. He starts his programming for, “Count My Sheep” app that counts heads of sheep. He completes it quite fast and delivers it for review. The reviewer, being a very experienced gentleman says “You know what? Sheep are known to have no brain, and brain is synonymous with the head. So the industry guideline of best standard practice recommends to count legs instead and divide it by 4. So in a nutshell, change it.”  The developer thinks “OK, I am not convinced. But this man is more powerful and experienced than me, so why not just change it as per his review comment?”  He makes the changes and now the program is ready for QA.

The QA, being a very intelligent lady, finds that, some of the sheep have broken legs, and the count doesn’t match. The developer now, slightly comes to terms with his inefficiency, and curses himself, for not being able to imagine such a common (everything is common once known) test case before. He again changes his code, to consider broken legs.

Meanwhile, the BA, one more experienced gentleman, comes and says “The farmers may not have a good camera or skills, to take the pic of the herd in one shot. Moreover, the sheep may not be tied in their place, and they can be moving too."

Interim, the government also passes a rule, to pay a tax amount of one rupee to it, every time any computer application is used by anyone. The product owner thinks that it would be a great idea to support different types of animals other than sheep, and also a feature where farmer can make an acquisition in bulk.

Now, the developer sees real daylight stars and feels that he is not overpaid, but overwhelmingly underpaid. Understanding these concerns, the management with a kind heart, adds one more developer to work on these tasks. 

Both of them write complex conditions (changes procedural objects with nested ifs, that span deeper than Pacific Ocean and look more complex than a Sankranthi Rangavalli), somehow (don't ask me how) fulfills the requirement, and again deliver it to QA.

The new developer who was not passed the practical wisdom of identifying heads and counting them, uses industry standard way of counting legs, and messes up the count again. The original developer is called to justify the reason for reopened defects, and is heavily criticized for it.

Now, the performance tester enters into the picture, and outright rejects the program as it is way beyond the SLA and remarks that, for the first time in her career, she liked to see the hours hand in the clock moving faster. At the same time, the system engineer also points that unless the customer has a 10G connection, he will have to wait for his life to download this app.

Now, the developer who doesn’t have a solid computer science background, uses his search brain Google, to find out an algorithm that has minimal traversal to solve this problem. He learns about complex algorithms, feels happy and starts changing the program again.

While he is engrossed in doing this, the development manager calls him and says “You know what? You are taking too much time to develop this, and we have an impending release. So, we are moving the moving sheep requirement out of scope, for this release. Go and revert your changes.”  Having now understood the full cycle of software development, the developer silently goes to his seat and makes the changes his manger suggested.

That’s the end of my story. My father was quite convinced with my answer and also felt very happy because his son’s future is secured (though quite volatile) for his life.