Of Two Cities, And Technical Debt

Aug 19, 2016
Mark Gonzales


If you deal with customer data systems—marketing platforms, transaction systems, and analytical databases—you’ve probably run across the concept of “technical debt.” Wikipedia defines the term as:

“Technical debt (also known as design debt or code debt) is a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution.”

Whether we realize it or not, every day we make decisions that impact technical debt. As the debt increases, eventually we must pay it by replacing or redesigning systems. But all technical debt is not created equally. I suggest that there are two types of technical debt. One type is inexcusable. The other is unavoidable.

To understand the difference, let’s tell a tale of two cities; two cities and technical debt. And sewage. Trust me, I’ll get there.


In the 1780s, the first European settlers of what would become the City of Chicago built farms around the mouth of the Chicago River. In 1829, the Illinois legislature commissioned a plan to locate a canal and lay out the surrounding town. By 1840, the town had a population of some 4,000 residents.

In 1848, a population boom was sparked by the arrival of the first railroad lines connecting the city to other states. Along with the opening of canals between the Great Lakes and the Mississippi, this caused Chicago to become a transportation and commerce hub. By 1845 the population had grown to over 12,000. By 1850, there were over 28,000 residents. By 1855, the population was over 83,000.

And by 1855, Chicago was crowned by travelers as “the filthiest city in America.”

You see, the land elevation of Chicago was virtually nonexistent. The entire boom town was basically at the same elevation as Lake Michigan. When rains came, the streets became impassable swamps as there was no “downhill” for the water to run. Worse yet, there was no “downhill” for sewage to run. What wasn’t much of a consideration for a small town of 4,000 with a canal, suddenly became a critical roadblock to growth for a city approaching 100,000.

Success had overrun the original design of Chicago.

What did Chicago do? They elevated the entire city, by as much as 14 feet.

During the 1850s and 1860s, engineers raised every building, street and sidewalk. Hydraulic jacks or manual jackscrews were placed by the hundreds under every building, lifting each up and filling underneath, allowing for piping and other underground infrastructure. What’s amazing (as if raising the city wasn’t amazing enough) is that the lifting process was done while people carried on living and working in the buildings. In one case, an entire half block on Lake Street was raised all at once with some 6,000 jackscrews and 600 men.

Of Two Cities and Technical Dept_Fig1

The raising of the Briggs House in 1857, Chicago. Source: Wikipedia

In the end, the city had one of the first storm water and wastewater systems in the country. By 1870, the population of the city was 300,000—the fifth largest in the country. The rest is, as they say, history.


In the city of Dubai stands the tallest building in the world—the Burj Khalifa. At 2,722 feet tall, it represents a feat of modern architectural engineering, encompassing technologies to handle the pressure of winds, the sheer weight of the building and its contents (and residents), and the movement of people between its 154 usable floors (there are 57 elevators including two double decker lifts).

But the one thing it didn’t have when it opened in 2010? A sewage system.

Of Two Cities and Technical Dept_Fig2

The Burj Khalifa (center) in Dubai

The Burj is capable of catering to some 35,000 people at a time—more than the 1850 population of Chicago. Those residents, employees, and travelers can generate 15 tons of sewage and wastewater a day. The world’s tallest building has a system for moving that waste down to the base of the building (thank goodness), but then nothing.

In the zeal to build and open the world’s tallest building as soon as possible (lest another building beat it), city planners prioritized. They built the skyscrapers. They built the wastewater treatment plants. But they didn’t build the system of pipes and pumps that would connect the two. They decided that they’d deal with a central sewer system…later.

At this point you might be thinking, “But the building opened in 2010, they must have come up with a solution.” That they did. In what was perhaps the finest example of an engineering “kludge” in the history of, well, engineering, hundreds of trucks would stop by all of Dubai’s skyscrapers, including the Burj Khalifa, 24 hours a day, 7 days a week, collect the wastewater, and drive it to the wastewater treatment plants. At times there was a line of trucks 24 hours long waiting to dump their dirty cargo at the treatment plants.

The city of Dubai eventually addressed the problem, but only after significant costs generated by the truck system and a rather large PR problem when viral videos of the line of trucks hit the Internet. Even today, the perception of Dubai’s underdeveloped sewage system lingers.


The concept of technical debt can be abstract when you are in the middle of product and information system design and implementation, with pressure to ship or bring up the system as soon as possible. Or when you are enhancing existing systems to adapt to new products, new customers, and new expectations.

I often use the examples of these two cities to make the abstract concept of technical debt more tangible for people designing and implementing customer information systems. They illustrate the difference between inexcusable and unavoidable technical debt.

The Burj Khalifa represents an inexcusable form of technical debt—debt that is purposely designed into the system from the start. Dubai wanted to “ship first” and accepted the costs of the truck kludge. But they also accepted the unforecasted costs of the negative PR, and the risk of more permanent operational costs. We can all think of situations where technical-debt-by-design ended up being permanent technical debt when follow-on recovery projects were delayed, cancelled, or failed.[1]Dubai is often considered a “start-up” city, willing to take risks to get to market first. But most start-ups aren’t backed by billions of dollars in oil revenues. Be careful with “first-to-market” reasoning. What could Dubai have done? Built the sewer system in parallel with the skyscrapers. This would have required incurring the costs up front, but would have avoided the risks and likely higher costs that were actually required just a few years later. As it turned out, their predictions and forecasts were wrong. The Burj Khalifa was and is the tallest building in the world and will remain so at least until 2019. It would have been “first” in any case.

The City of Chicago represents an unavoidable form of technical debt—debt generated by success and unforeseen technological change. The agricultural community of a few thousand was transformed by the development of long distance canals and the invention of railroads. Chicago outgrew its design, and as it did so, technical debt accumulated and had to be addressed.[2]What we all would give to have had Chicago’s success-generated technical debt.

We can’t predict every possible technological and market advance when we are designing systems, and we shouldn’t try because we may very well be wrong. Just the process of predicting and forecasting the future can often lead to decision paralysis.

But technical-debt-by-design is inexcusable because it is almost always justified by underestimating the risks and costs. If an organization can sustain those costs then perhaps the risks are justified. But usually technical-debt-by-design is a short-term cheat.

We want our technical debt to be created by success, not by design. Keep this in mind when your technical teams describe a quicker, easier path to launch.


Footnotes   [ + ]