All Quotes and Illustrations are from City: A Story of Roman Planning and Construction, by David Macaulay (1983)
V. Build and Test
Backend and UI Development
“The materials used most in the construction of The City were stone, clay, mortar, and wood. The stone came from a limestone quarry owned by the government. Besides many work sheds, the quarry contained a forge for making and repairing tools and a carpenter’s shop in which cranes and pulleys were built. The skilled laborers cut, polished, or carved inscriptions in the stone. The unskilled workers separated and lifted the huge blocks from the earth…
A great variety of tools were needed throughout the construction of the city. Most were made in forges and workshops on the site. The more precise measuring instruments and squares were brought from Rome.”
Cities are born from the dirt they’re built on, but by relying on the resources at your disposal from surrounding kingdoms, you can dramatically accelerate and heighten the quality of construction. In our case, the role of unskilled labor is occupied by automated scripts, and the tools and refined materials are like reusable code — sourced internally (from reliable frameworks your team has already built and used on other projects) and, when necessary, from third-party libraries. Of course, it’s prudent to avoid becoming too reliant on foreign trade for your resources and experts — it’s important to cultivate expertise and resources domestically.
A skilled software engineer knows it isn’t necessary to redesign the wheel, but it’s important to understand how the wheel works, so when you need to create your own, you’ll be able to do it with ease.
This is basically what your engineers do all day.
“When the stone was very hard, the blade used in the saw had no teeth; sand and steel filings were placed under the blade and the back-and-forth motion of the saw ground away the stone. When the stone could not be sawed, a row of holes was drilled where it was to be divided. Wooden stakes were then jammed into the holes. When water was poured over the stakes, they swelled, splitting the stone along the line of holes.
The clay was made into bricks and tiles in factories near Arretium. The clay, dug out of large pits in the ground, was formed into standard shapes and sizes using wooden molds. The mold was then removed and the wet clay placed in an oven to dry and harden. All bricks and tiles were stamped with the name of the factory owner and the name of the Emperor.”
Unique requirements will often lead engineers to encounter unconventional problems that must be solved in unconventional ways. Trust your engineers to exercise their judgment and apply their accrued expertise during the software development process. While such flexibility is important, also remember the value of standardization. If you can dream it, you can build it, but you must be able to trust your materials. Take pride in even the shortest line of code — it’s contributing to the stability and success of something much greater.
Integrations
“The new roads and bridge were completed before work began on the city itself… At first, The City’s drinking water came from several deep wells within the city walls. But the planners knew that as the population increased the wells would no longer be sufficient. A pipeline called an aqueduct was proposed to bring water from the mountain lakes thirty-eight miles to the south…
To prevent people from stealing or poisoning the water, most of the aqueduct was raised about fifty feet off the ground. It was supported by a continuous row of arches built on tall square piers which rested on deep foundations.”
A city without trade is not a city. Likewise, an app that doesn’t communicate with external services is necessarily quite limited. Most applications benefit from communication and integration with third party resources. Building those channels securely and safely is critical to the success of your application. The work is painstaking, but the results are beneficial to all.
Quality Assurance and User Agent Testing
“Following the ceremony, the surveyors marked off the roads using an instrument called a groma to make certain that all roads intersected at right angles. The groma was a pole about four feet high on top of which a cross was laid flat.
Pictured above, a rare and elusive creature — the happy QA tester.
When weighted strings hanging from each end of the cross hung parallel to the center pole the groma was known to be perpendicular to the ground. The streets could be accurately marked off by sighting down the intersecting arms of the cross.”
Quality assurance doesn’t start after your city (or app) is built. It’s an ongoing process that proceeds in tandem with development. As new features are built, make sure they’re thoroughly tested and fully functional — with continuous deployment. Life in your app can’t come to a standstill just because it’s still undergoing construction.
Iterations
“From the boat bridge work began on the permanent bridge. It was to be made of wood and supported on five stone towers called piers which were to stand in the river. Cofferdams were built so the laborers could erect the piers without having to work underwater… A wooden road was nailed to the arches and covered with a layer of earth. The finished road stood almost sixty feet above the river.”
Rome wasn’t built in a day. Your app won’t either. Progress on a feature may appear slow or confusing to the uninitiated until the project is close to completion, as functional requirements may take precedence over polished presentation.
The scaffolding and supporting structures necessary to build the finished product may temporarily obscure its beauty and purpose; it takes patience and trust in your engineers to realize the vision of your planners and designers.
Security
“The city wall was built next. Two large ditches were dug along the furrow and the dirt was heaped into a high mound between them. A stone wall was built against each side for additional strength. The base of the outer wall went down thirty feet below ground level, making it almost impossible for anyone to tunnel under. On top of the outer wall alternating high and low sections called crenelations were built.”
It’s crucial to protect the integrity of your application and the personal information of your users. Make sure data is transmitted securely and stored appropriately with encryption and tokenization as necessary.
Usability Testing
“Before the wall of the city was finished, work began on the streets. [The] streets were designed for people. Therefore adequate sidewalks were built and strict laws were written to control any movement of carts and chariots which could endanger the health and safety of people in the streets.
During the day, all carts and chariots except those carrying building materials were banned from the streets. This meant that deliveries had to be made at night or in the early morning. Carts and horses were very noisy, so many of the streets were a one-way or dead end to reduce traffic. When it rained, the streets became the gutters and water ran into sewers under the sidewalks. Steppingstones enabled people to cross the street without getting their sandals drenched.
Much as a city is designed to be lived in, your app must promote the needs and wants of its users. A designer doesn’t need to start designs from scratch; mercifully, reliable patterns exist for user interface design—but it is always important to test your assumptions before development, test your execution during development and evaluate user opinions after release.
Putting users first is the key to creating effective, efficient and satisfying experiences — making a city they’ll want to live in.
VI. Rule Justly
Release, Observe, Measure, Maintain and Improve
“By 19 B.C. the city walls were finished and work began on the first and most important public areas of the city— the forum and the market… Because new temples were always being enlarged or replaced, the forum wasn’t really finished for another two hundred years. But the central market across the street was finished in less than five. This was not surprising since the city’s main function was that of a trading center.”
If you’ve worked in software, you are familiar with the myth of “Phase Two.” ‘Two Hundred Years’ probably seems like an appropriate timeline for the inclusion of all features left in the Icebox.
The city and the app share this trait. It’s common sense to build the parts that are the most important to your users first. That doesn’t mean you’ll never get around to other features — it just means you should focus on developing, revising and improving upon the features that make your app unique.
Once you’ve shipped your app, it’s time to listen to your users — the citizens of this new city-state. You’ve made intelligent decisions along the way, been informed by past experience, market conditions and the opinions of select test users. But nothing compares to the volume of information you’ll receive once your app is freely available and in the hands of users.
There will be many ideas and suggestions; some good, some bad. Some you’ve already considered and dismissed, others you had to push off to Phase Two. This is the beginning of a dialogue that will determine the ultimate success of your app. People will abandon a city with an unjust or uncaring ruler.
Cities are not static. They are organic, living entities pulsing with life and constantly evolving to suit the needs of their citizens. Nor are cities short-lived; the best will endure centuries, outliving their residents for generations to come. There are probably already several apps out there that will outlive you. Your app should aspire to be a sanctuary for its users—whether they are citizens, travelers, nomads, traders.
So take pride in even the smallest line of code, the smallest kerning adjustment, the most superfluous screen transition, the most ephemeral photo-sharing application — celebrated or forgotten, you and your work might just contribute to something that stands the test of time.
Published August 25, 2016
Blake Weis
Cameron Smith
David Mays