Month: April, 2014


We had an admin interface from which people could download an Excel report. One day, we got a mail saying that the report format is Excel version so and so and it does not work with new Excel versions. The scramble began to find out which version of Excel was used, which version our app produced, how we can upgrade the library the app uses to create Excel documents to the latest version etc. For people not in the know, it is a pain to programatically work with any Microsoft office format in Java, you invariably feel like pulling your hairs out. In the middle of all this madness, I asked a simple question, instead of creating the document in excel format, why do not we create it as CSV? The report consumers were neutral, they were like we do not care as long as we can open it in excel.

As programmers, a lot of times, we blindly work on product requirements without questioning the intention behind them. As it was in our case, the person who gave the Excel requirement did not have any idea as to the difference in the amount of work one would have to put in to create an Excel report versus a CSV, nor the technical debt of the two approaches. From his perspective, it was all the same.

When a requirement comes to you, take a step back and go through them, see if there are chances to simplify. If some of the requirements sound absurd to you, tell it to the stake holder, if some of them might take a long time to implement, talk to him about this. The person providing the requirement has absolutely no idea that some of these features might be technically difficult to pull off or take a long time to implement or there is a better alternative that might not meet the criteria strictly but will not take eons to implement. Bias towards action is good, but a trigger happy one hurts everyone.

Designing for failure

In the world of software, failure is a certainty. Servers go kaput, databases go down, processes go out of memory, things break all the time. You can categorize software as good or bad based on how they behave in these adverse scenarios. I am not trying to imply that software has to be resilient to all these, on the other hand, I believe that it is perfectly fine to crap out when shit hits the fan. The question is how do you handle this crapping out.

Whenever architecting components, devote ample amount of time to failure scenarios. Let us take the case of a piece of code which interacts with an external, third party API. What are the questions you should be asking when designing this component? What happens if the API suddenly stops responding one day? Can I hold my main thread hostage to the API response time? What happens if the API takes eons to respond? In case there is an exception, am I logging enough data to debug? If there are performance issues, do I have enough diagnostic data? Diagnostic data might be in terms of graphing the API response time, no of times the code path was executed, etc. Do I need to send out an alert when something goes wrong? All these question revolve around failure handling. These questions should be second nature to you as a software engineer.

I have seen a tendency among developers to devote inordinate amount of time in making their code adhere to the latest programming fad, trying to use the best possible library etc, but not to failure scenarios. Logging data might not be as sexy as debating which design pattern to use, but once things break, logs are your only friend. Next time when you are furiously pounding on the key board, take a step back and ask these questions. In the future, the developer who maintains the code that you wrote today, will thank you for doing this.

Poor cannot eat roads

Rahul Gandhi allegedly made this statement. It is sad that an armchair, untrained economist like me understands the significance of good roads while someone who is poised to lead India does not. Check out this vice documentary on truckers in West Africa to get the connection between roads and economy. Jim Rogers, author of the excellent book Investment Biker also alludes to how Africa is rendered poor due to bad road connectivity. In spite of so much evidence suggesting good road connectivity being essential for a healthy vibrant economy, Rahul Gandhi makes this asinine statement and our so called independent media is busy discussing his dimples and his charm working up pubescent teenage girls.

A road is something that transcends socio economic, caste and religious boundaries. A road does not discriminate between a rich man driving his BMW or a poor milk seller riding his bicycle or a pandit riding his Luna or a moulvi riding his scooter. I do not for a second doubt the ingenuity of our so called secular politicians to come up with statement on the lines of Minorities have the first right to our roads, but until that happens, for all purposes, we can take rest in the fact that a road is a great unifier. 

How do good roads benefit the poor? Good connectivity makes the transportation of goods efficient there by negating the cost that would be introduced due to transportation inefficiencies. This is an indirect benefit that is enjoyed by everyone not just the poor, but let us take a specific case of how good roads will make the life of a poor auto driver better. If an auto driver drives his auto on pot holed roads all day long, imagine the toll it takes on his auto. This will directly reflect in the efficiency of the auto as well as the money he has to spend on maintenance, not to mention the umpteenth lost opportunity to make more money by ferrying more customers due to the reduced travel time. All in all, an auto driver has to gain a lot with smooth roads. Instead of working on these, our government is hell bent on extending the economic black hole of NREGA to urban poor and our media is a silent spectator to this theater of absurd.


Moving up the value chain

In the gym that I go to, there is a guy whose job is to sanitize(spray, clean, rub etc) the equipment after each person uses them. I always pity him and think how boring his job is. How can this person move up the value chain?

The other day, people at the gym were opening up the machines and lubricating and tuning them. This guy was taking a keen interest in the job and helping them out. This sparked a wave of thoughts in my mind where I put myself in his shoes and thought how I could move up the value chain if I were him. I would learn how to tune and lubricate these machines properly. If the norm is to do this activity once a month, I would volunteer to do this every week. Everyone wins, the machines are smoother to be used by the members on a regular basis and I get a good opportunity to hone by skills. Once I am adept at doing this, I would go to the other gyms and offer my services to them. There are a lot many gyms in Indiranagar that I know of and probably some more that I do not know of. I am sure all these people are looking for someone who knows his way around the equipment because such people are usually scarce these days. Once I have a good number of gyms under my belt, I would probably bring more people from my native village and teach them the job so that I can build a team and expand my operations throughout Bangalore. In this way, I am not only bettering my life, but also providing employment opportunities to the people of my village. Once I have Bangalore under my belt, you know the drift, expand more etc.

This is a very hypothetical scenario, but a belief that I very much hold on to, if you try hard enough, there is always a way to move up the value chain.