Agile programming and Parliamentary procedures

Supposedly the latest (ok not that latest – it’s been around for a decade) thing in software engineering is this thing called “Agile programming“. It’s basically about breaking away from the old “waterfall model” (which we had learnt in a software engineering course back in 2003), and to a more iterative model with quick releases, updates, etc.

I’ve never worked as a software engineer, but it seems to me that Agile programming is the way to go – basically get something out and keep iterating till you have a good product rather than thinking endlessly about incorporating all design specifications before writing a single line of code. Requirements change rapidly nowadays, and unless you are “agile” (pun intended) to that, you will not produce good software.

Agile methodologies, however, don’t work in parliamentary procedures, since there is very high transaction cost there. Take, for example, the proposed Goods and Service Tax (GST). The current form of the Goods and Service Tax is an incredibly flawed bill, with taxes for movement of goods across states and certain products being excluded from the ambit altogether. Mihir Sharma at Business Standard has a great takedown of the current bill (there is no one quotable paragraph. Read the whole thing. I’m mostly in agreement).

So it seems to me that the government is passing the GST in its current half-baked form because it wants some version (like a Minimum Viable Product) off the ground, and then it hopes to rectify the shortcomings in a later iteration. In other words, the government is trying some sort of an agile methodology when it comes to passing the GST.

The problem with parliamentary procedures, however, is that transaction costs are great. Once a law has been passed, it is set in stone and the effort required for any single amendment is equal to the effort originally required for passing the law itself, since you have to go through the whole procedure again. In other words, our laws need to be developed using the waterfall model, and hence have full system requirement specifications in place before they are passed.

It’s not surprising since the procedure for passing laws was laid down back at a time when hardly any programming existed, leave alone agile programming. Yet, it begs the question of what can be done to make our laws more agile (pun intended).

PS: I understand that Agile software development has several features and this iterative nature is just one of them. But that is the only one I want to focus on here.

27% and building narratives using numbers

Some numbers scare you. Some numbers look so unreasonably large that it seems daunting to you, infeasible even. Other numbers, when wrapped in the right kind of narrative, seem so unreasonably small that they sway you (the Rs. 32 per person per day poverty line comes to mind). Thus, when you are dealing with numbers that intuitively look very large or very small, it is important that you build the right narrative around them. Wrap them well so that it doesn’t scare or haunt people. As the old Mirinda Lime ad used to say, “zor ka jhatka.. dheere se lage..”.

So the number in the headline of this blog post is the proposed rate of the Goods and Service Tax. While it is the revenue-neutral amount that needs to be charge should excise and sales and other taxes go, the number looks stupendously large. The way this number was reported on the front pages of business newspapers this morning, it looks so large and out of whack that people might decide that it is better to not have a GST at all.

I’m not blaming the papers for this – they have reported what they’ve been told. It is a question of building narratives by the government. The government, and the GST sub-panel, has done a lousy job of communicating this number, and guiding how it needs to be reported in the media. It is almost as if the way the number was reported is an attempt to further delay the implementation of the GST.

The GST is too important a piece of legislation to be derailed by bad narratives. The government must make every attempt to build a narrative that shows the GST as being conducive to people and to businesses, to show how the transaction costs it reduces will result in better prices for both consumers and businesses, and why it makes lives better. Reporting numbers that look really large doesn’t help matters.

Also, the quant in me is disappointed to see one precise number being put out as the “revenue neutral rate”. Since different goods and services which are now being taxed at differential rates are going to be brought into this one umbrella rate, the real revenue neutral rate is actually a function of the mix of the contribution of each of these goods and services to the GDP. Given that in a dynamic economy these rates are constantly changing, reporting one revenue neutral rate simply doesn’t make sense. A range would be a better way of going about it.

Related to this, given that the revenue neutral rate is a function of mix of goods and services, and this mix will change over time, the assumptions and forecasts that need to be taken into account in the process of fixing the rate are important. The GST panel would do well to take into account the risk of product-and-service mix changing that can make all calculations go awry!

PS: If only they were to hire me as a consultant to this panel 😛