Using a cache is often how the applications mix display code with the data. When data is mixed into the template, the result is stored back in the database to be served again and again.
Using a suboptimal foundation
It used to be that choosing the “wrong” architecture or strategy for your long-term growth goals meant imminent project death. These days, however, recovering from poor early choices can be relatively easy, as long as throwing more cloud machines at the problem remains a workable solution.
If your server stack is slow or your databases are getting bogged down, you can often simply turn up the dial and rent more machines. Then when the crowds dissipate, you can dial back the extra computing power. When extra machines cost mere pennies per hour, it’s no longer as catastrophic to make an architectural mistake.
Of course, not all errors can be fixed by throwing pennies at them. Some poor decisions lead to exponential blowups when the company grows. Those kinds of failures can quickly empty any wallet when the cloud meter is running. But simply choosing a stodgy database or an elaborate filter that’s merely twice as slow isn’t a deal breaker as long as it doesn’t compound.
The key is to avoid bottlenecks in the central, most crucial part of the design. Keeping the moving parts separate and independent helps ensure that they don’t interfere with each other and produce a deadly lockup. As long as the core architecture doesn’t produce gridlock, bad decisions can be covered up with faster hardware. It’s not pretty, but it’s often effective.
Consider Facebook, a company that began using PHP, one of the early tools for web applications that already felt a bit dated by the time Facebook launched. The unappealing issues, though, were ones that bothered programmers -- not users. For all the odd syntax and limited power, the approach was solid. Facebook has since spurred PHP development by creating the HHVM, a much faster version that inspired a rewrite of the PHP core. Now Facebook runs the old code much faster, and users don’t know the company settled on an early platform choice that still makes some programmers' eyes roll.
Choosing a passable solution is often cheaper than engineering a sophisticated new approach. Sitting everyone down to redesign software so that it runs smoothly and efficiently could cost a fortune. A smart programmer makes $200,000 a year -- but that can be more than millions of server hours at Amazon. Being smart often isn’t worth the trouble when more hardware is cheap and rentable by the hour.
Keeping dusty code in production
A team of managers once called me in to look at a fancy, modern web application developed with the latest ideas and the newest language (Java, at the time). The problem is that the old mainframe talking with monochromatic dumb terminals was so much faster that everyone who had to use the new code was complaining. Can’t we go back to the ’60s-era tech?
Sign up for CIO Asia eNewsletters.