Software development and economics

One of the delights of working in the IT field is that it interacts with so many other fields. On one side is the "user" areas: user interface design, user experience, and don't forget accessibility and section 508 compliance. On the other side is hardware, networking, latency, CPU design, caching and cache invalidation, power consumption, power dissipation, and photolithography.

And then there is economics. Not the economics of buying a new server, or the economics of cloud computing, but "real" economics, the kind used to analyze nations.

Keynesian economics, in short, says that during an economic downturn the government should spend money even if it means accumulating debt. By spending, the government keeps the economy going and speeds the recovery. Once the economy has recovered, the government reduces spending and pays down the debt.

Thus, Keynesian economics posits two stages: one in which the government accumulates debt and one in which the government reduces debt. A "normal" economy will shift from recession to boom (and back), and the government should shift from debt accumulation to debt payment (and back).

It strikes me that this two-cycle approach to fiscal policy is much like Agile development.

The normal view of Agile development is the introduction of small changes, prioritized and reviewed by stakeholders, and tested with automated means. Yet a different view of Agile shows that it is much like Keynesian economics.

If the code corresponds to the economy, and the development team corresponds to the government, then we can build an analogy. The code shifts from an acceptable state to an unacceptable state, due to a new requirement that is not met. In response, the development team implements the new requirement but does so in a way that incurs debt. (The code is messy and needs to be refactored.) At this point, the development team has incurred technical debt.

But since the requirement has been implemented, the code is now in an acceptable state. (That is, the recession is over and the economy has recovered.) At this point, the development team must pay down the debt, by improving the code.

The two-cycle operation of "code and refactor" matches the economic version of "spend and repay".

The economists have it easy, however. Economic downturns occur, but economic recoveries provide a buffer time between them. Development teams must face stakeholders, who once they have a working system, too often demand additional changes immediately. There is no natural "boom time" to allow the developers to refactor the code. Only strong management can enforce a delay to allow for refactoring.

Mobile apps don't need tech support

I recently "fired" the New York Times. By "fired", I mean that I cancelled my subscription. The reason? Their app did not work on my Android tablet.

The app should have worked. I have a modern Android tablet running Android 4.1 and Google Play services. (I can understand the app not working on a low-end Android tablet that is not certified for Google Play services. But this was not my situation. The app should have worked.)

The app failed -- consistently, and over a period of time. It wasn't a simple, one-time failure. (The app worked on my Android smart phone, so I know my account was in good standing.)

So I uninstalled the app and cancelled my subscription.

A few musings on software and tech support.

Cost A software package for Windows is an expensive proposition. Most software -- software that is sold -- costs upwards of hundreds of dollars. Most enterprise software has not only a purchase cost but a support cost -- an annual fee. With such an investment in the software, I will only discard the software when I must. I have a strong incentive to make it work.

The tech support experience Software companies have, over the years, trained us lowly users to expect an unpleasant experience with technical support. Software companies hide the phone number, pushing you to their web-based documentation and support forum. If you do manage to call them, you are greeted with a telephone "torture menu" and long wait times. (But with a significant investment in the software, we are willing to put up with it.)

The equation changes for mobile apps Mobile apps are much less expensive than PC applications. Many are free, some cost a few dollars.

Customer expectations may be shaped by many things. Software is not always an expensive proposition. Consider:

• The (relatively) low cost for Mac OS
• The appearance of Linux (a free operating system)
• Open source applications (also free)
• Free apps for your smartphone
• Free e-mail from Google and Yahoo
• Unlimited voice and text with your cell phone plan.

While I may be willing to wait on the phone for a (probably polite but ineffective) support technician when the software cost is high, I am not willing to invest that time for free or cheap software.

I suspect that there are several doctoral theses in this phenomenon, for students of either psychology or economics.

I decided rather quickly to drop the app for the New York Times. The failing app was a frustrating experience, and I wanted to move on to other things. I may have posted about it on Twitter; I dimly remember a response from the Times folks claiming that their support team could help me. But by the time I got that response, I had already fired them.

Regardless of the economics and the psychology, the message for app makers is clear: Your app must work, with a quality higher than most PC applications. It must work and be simple enough that a person can use it without a manual, without a help system, and without a technical support team.

If it doesn't, your customers will delete the app and walk away. Your revenue from app upgrades or connected services (in my case, the subscription to the New York Times) will drop. You do not get a chance to "save" a customer when they call for support -- they're not going to call.