Sorry to be somewhat off-topic as far as economics goes. This is another one of my biases about systems development–not that I am a qualified professional at it. But on an earlier post, a commenter wrote,

code sent messages to customers by e-mail, phone, text, etc., for flight notifications (on time, late, cancel, gate change, etc.). Just for frequent flyers, the decision making on whether to send a message that a flight was delayed ran past 1000 lines of code. It depended on whether messages had been sent before already, plus results from multiple databases with customer contact details, timezones, whether the flight was a connection or originating, time-of-day, saved preferences, plus legal issues such as whether the customer had triggered telco opt-out for text messages.

My claim is that none of that should be written into computer code. Instead, think of a list of conditions that might trigger a message. Put those into a database and write code that constantly checks against those conditions. Then think of a list of conditions for sending a message by phone, a list of conditions for sending a message by email, etc. Put those into a database, and when “might trigger a message” is true, check these conditions and if they are satisfied, send a message.

My point is that business rules should reside as much as possible in data, not in code. That way, you know where they are, and you do not have the maintenance problems that come with large amounts of code.

One of the advantages I see in rewriting software is that you take the business rules that have crept into the code out of the code and into data.

Kathleen Madigan writes,

In the inflation gap between goods and services, one of the biggest chasms is between the price of a television set and the accompanying cable bill. In the past five years, the price of a new TV set is down nearly 58%, while the cable bills have risen nearly 14%.

Her article cites the higher prices being charged by content providers, such as ESPN.

My household is providing a subsidy to cable TV. We don’t watch it, but it comes bundled with our Internet service. When will the cable TV model break, so that it can no longer extract so much revenue? Some possibilities.

1. Never. My household is an outlier. Other households are getting ever-increasing value from cable TV, and they will gladly pay more for it.

2. Never. The business model of bundling is sound when there are high fixed costs, as in wiring up a community.

3. When enough spectrum is freed up that consumers like me start to get rid of cable and rely solely on wireless.

4. When enough consumers shift toward Internet-based entertainment.

A commenter pointed me to an article by Joel Spolsky from 15 years ago.

The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they’ve been fixed. There’s nothing wrong with it. It doesn’t acquire bugs just by sitting around on your hard drive.

This might be thought of as a Hayekian view of software. Accept what has evolved, even if you do not understand it. In contrast, I think that if you are maintaining software, and there are parts of it that you do not understand, you are in trouble.

Perhaps I am wrong, and Hayek/Spolsky are right. You should not try to rewrite software that works.

However, I think that it might be possible to distinguish software modules that perform generic functions in a reliable way (do not re-invent these) from application-specific software that lives in a world of changing business rules. My hypothesis is that in the latter case, frequent rewrites are more cost-effective than a process of continual patching.

From a Washington Post article on the software glitch that briefly grounded United Airlines:

“When the two airlines decided to merge, they had a choice to make: Would they take the Continental system, or would they take the United system?” Seaney said. “They decided to go with the Continental system and basically dumped Travelport.”

Flipping one reservation system into a notably different system is complicated and problematic, and it has led to headaches for United.

“There wasn’t a lot of commonality, and there were a lot of glitches along the way,” Seaney said. “They had issues with reservations, with elite status, all their awards programs had issues.”

I feel United’s pain. About 17 years ago, my homefair.com web site (which I now have had nothing to do with for 15 years) bought a related web site. We had very similar business models, so our software did similar tasks, but theirs was written in Perl and ours was written in Java. Rewriting their software to work with ours cost more than building both of our individual systems. Still, I think it was worth it.

I am a huge believer in rewriting software. In particular:

–As soon as you finish the first working version of an application, you should rewrite it from scratch. The rewrite will go quickly and will involve a much better design.

–Letting any software application go more than two years without a total rewrite will create maintenance headaches. You will have accumulated patches that turn the code into a mess. Your developers will not remember enough to be able to discern what sorts of changes could blow up the system.

The Perl code that we inherited was not only hard to follow (all Perl code is hard to follow–that’s why I hate it) but had undergone continual patching without rewrites. Most corporate software evolves that way, and sooner or later that ends up costing a lot.

Related: Zeynep Tufekci writes,

In the nineties, I paid for parts of my college education by making such old software work on newer machines. Sometimes, I was handed a database, and some executable (compiled) code that nobody had the source code for. The mystery code did some things to the database. Now more things needed to be done. The sane solution would have been to port the whole system to newer machines, fully, with new source code. But the company neither had the money nor the time to fix it like that, once and for all. So I wrote more code that intervened between the old programs and the old database, and added some options that the management wanted. It was a lousy fix. It wouldn’t work for the next thing that needed to be done, either, but they would probably hire one more person to write another layer of connecting code. But it was cheap (for them). And it worked (for the moment).

Megan McArdle writes,

Does Congress need to give agencies a freer hand in developing good systems? I’m all for it. Should Congressional Republicans commit to support the president in hardening our government against cyber-attacks and other disasters, rather than simply holding political show hearings? Heck yes. But these things won’t happen unless the president makes fixing government IT a bigger priority — and starts enforcing accountability for every disaster that happens on his watch.

Along similar lines, David Strom, an IT consultant, writes,

If a private industry CIO had this sort of security record, they would never work in IT ever again, unless to become a motivational speaker and tell people what not to do. Instead, because they are the Feds, we just shake our heads and wonder what is going on, and some how give them a free pass to mess something else up again. It really boils my blood.

In my view, bureaucracies are notable for two things.

1. They filter out new ideas.

2. They blur accountability. When you make a reasonable request and are turned down because of “policy,” you have encountered this blurred accountability.

I understand the constructive value of filtering out new ideas. A large organization can only focus on a few major initiatives. Those initiatives had better be good ones. Most new ideas are bad. Think of a Type I error as making a catastrophically bad bet and a Type II error as missing out on a profitable opportunity. Bureaucracies help to curb Type I errors but tend to make Type II errors. And every middle manager who has ever had an idea die in the bureaucracy is convinced, usually incorrectly, that the organization committed a Type II error.

Perhaps there is also a constructive value for blurred accountability. But I cannot think of one.