I love to travel, and I especially love to travel in Europe and most particularly in France, which I know well, having studied there many years with the aid of various grants including a Fulbright. I never get tired of wandering the Grands Boulevards or the small side streets of the Latin Quarter in Paris or visiting the small towns in the countryside, mostly because I enjoy looking at beautiful things. I find inspiration in the grandiose architecture of the great monuments as well as small details like the basic circles and rectangles of a small white cup of espresso with its bit of sugar served on a zinc bar.
Vacations can help rejuvenate your mind and offer time for contemplation. On my most recent trip, I found myself noticing the City of Light in a different context. I found myself drawing inspiration and correlations between the beautiful sights and our work as software engineers. Whether it was the architecture of the Eiffel Tower, the mixture of old and new in the Louvre or the details of a painting by Monet – each offered parallels to the design and, dare we say it, artistry that great developers put into the work of software development.
In this article, I’d like to share some of my own inspiration for software development that I found in Paris. If you have something or some place that inspires you in similar ways, please feel free to share them in the comments.
I experienced three “aha!” moments recently while strolling through Paris. The first occurred at that most iconic monument, the Eiffel Tower.
I conquered my vertigo and went all the way up to the top, even managing to look down for a few seconds while clutching the wall. The main takeaway from ascending this monument is that it is built to last…and yet it was not, at least originally!
Built with a twenty-year permit, this most famous of towers was built for the 1889 World’s Fair and was to have been dismantled afterwards. It was also roundly criticized by a large group of artists, writers, and musicians, who deplored the fact that they would have to look at it for the next twenty years:
“We, writers, painters, sculptors, architects and passionate devotees of the hitherto untouched beauty of Paris, protest with all our strength, with all our indignation in the name of slighted French taste, against the erection … of this useless and monstrous Eiffel Tower …And for twenty years … we shall see stretching like a blot of ink the hateful shadow of the hateful column of bolted sheet metal.”
–The Artists’ Protest
Interestingly, the Eiffel tower wasn’t saved because people suddenly grew to love it after twenty years, but rather because by then it had become a radio tower that proved quite useful in jamming enemy transmissions during the First World War.
Standing in line to ascend the tower, I started to think how the evolving history of the construction of this tower reminded me of how a greenfield software project can evolve. Often, we build software that is designed to solve a particular problem, and attention to scaling can come secondary. Yet successful software projects have clearly been built to last; they have a solid foundation, like that of the tower, and they are designed with intention, as Gustave Eiffel did.
Designed properly from the beginning, a well-architected software project may evolve in its detail or primary use cases, but its core can remain the same even if its use changes. You may not have intended to build a radio tower, but your project may turn into one and if it’s well-designed, it will scale as beautifully as the classical arches of the Tour Eiffel.
Another moment of convergence between classical design and software architecture occurred at the Louvre. Walking through the enormous courtyard of this famous art museum, you are awed by the amount of historical artifacts it contains. I was reminded of the challenge of legacy – specifically of legacy software.
The Louvre was originally designed as a fortress, converted to a residential palace, and eventually evolved into one of the largest and most-visited museums in the world, averaging 15,000 visitors per day. In the 1980s, the congested entrance of this much-loved museum was overwhelmed and an audacious new design was put in place by the architect I.M. Pei: a group of glass pyramids that allowed visitors to descend into a lobby and then be distributed into one of the museum’s wings.
While the large glass pyramids proved controversial (as in the previous example of innovation) the design, based on classical constructs, solved the problem of an overloaded legacy system. I was reminded of the ‘fixes’ that developers often ‘bolt on’ to older code structures to help it to evolve and serve the modern consumer.
Additive design is ultimately successful if it is both classically-inspired, in other words not simply following a trend, while also meeting users’ needs. A new series of forms, for example, replacing an older checkout system must function both within the classical format – on the desktop with text fields and proper validation, but it must also meet a newer user’s requirements to checkout on a mobile device. Merging classical design paired with the requirements of newer formatting, it seems to me, is the way forward when updating legacy content.
A third moment occurred to me when standing in the large oval rooms of the Musée de l’Orangerie where eight of Claude Monet’s many water lily paintings are housed. These paintings, viewed from afar, appear to be nothing more than random flicks of a brush in a sort of fog. Closer inspection, however, shows the careful brushwork and planning that went into these large-scale paintings. The water lily pads float on the water in which the clouds are reflected, a real masterpiece of the abstract representation of nature. Monet’s goal was to paint as many views of the beautiful light that bathes Northern France at his home in Giverny, and he spent the last 30 years of his life painting and repainting his gardens with their varying water and plants, eventually producing over 250 water lily paintings.
In my mind, these paintings recalled the importance of the attention to detail that the careful engineer must demonstrate even while working on large-scale projects. The paintings wrap around entire walls, but each lily pad, cloud, flower, and weeping willow leaf is meticulously rendered. Nothing is left to chance. The total effect is that of a harmonious whole almost accidentally rendered, yet it is obvious how much careful planning, composition, and work went into the design decisions of these large works. It is a beautiful example of how careful planning and attention to detail can result in work that will survive the ages.
As engineers, we are too often frightened of anything involving ‘design’ – whether UI or UX decisions or architectural decisions often left to specialists. This fear is unfounded. I think that Gustave Eiffel ought to have the last word:
Are we to believe that because one is an engineer, one is not preoccupied by beauty in one’s constructions, or that one does not seek to create elegance as well as solidity and durability? – Eiffel’s response to the Artists’ Protest, written in Le Temps of February 14 1887).
Whatever your project, I invite you to be inspired by the great designs of the past to create the architectures of the future!
Join me in person on May 4th in Boston, MA at TelerikNEXT for discussions on AppBuilder and the new M.I.K.E. Stack using Mongo, io.js, Kendo UI, and Express plus a cool IoT panel. Use promo code LOOPER when you register for $50 off the standard ticket price.