{
Adam Ard
}
The Fountainhead and Software Engineering
I just finished reading The Fountainhead by Ayn Rand and am convinced that it holds the secret to how engineers should build software. Howard Roark, the main character, is our perfect example.
The Fountainhead begins immediately after Roark is expelled from the Institute where he is studying. His unwillingness to reverence the older architectural styles being taught inevitably persuades his teachers to act against him. With his studies abruptly discontinued, Roark must now strike out on his own. After several failed attempts working at architectural firms, Roark meets a newspaper columnist that finances his first independent project. He never looks back. He uses this project to springboard him into his own practice.
In spite of his exceptional talent, Roark’s refusal to imitate older building styles leaves him relatively few commissions. He struggles to keep afloat. To make things worse, he insists that every potential client accept two stringent requirements before he provides any services:
- He must be the only architect commissioned for the job — no collectives, councils or collaborations.
- He must be granted full artistic freedom to design whatever he feels is best for the client’s needs in whatever method or style he prefers. The resulting design must be accepted without modification.
As one might expect, many people find this unreasonable. They wish to determine their building’s style or at least add decorative touches. After all, it is their money, so they should get what they want. Not with Howard Roark! With Roark it is always a take it or leave it proposition.
With time and significant opposition, Roark slowly grows his portfolio and gains enough of a following to be viable. The book concludes as he is engaged in building what will be the tallest building in New York — his pathway is looking clear and bright.
What can we learn from Roark’s experience and his unique client requirements? It is actually quite simple. He insists on maintaining the full integrity of his design and thereby produces superior, consistent work. These are his words as he tries to convince a hesitant client:
“He spoke for a long time. He explained why this structure could not have a Classic motive on its facade. He explained why an honest building, like an honest man, had to be of one piece and one faith; what constituted the life source, the idea in any existing thing or creature, and why — if one smallest part committed treason to that idea — the thing or the creature was dead; and why the good, the high and the noble on earth was only that which kept its integrity.”¹
In other words, if maintaining integrity in your work is of ultimate importance, to engage in collaborative work compromises the main thought behind a design by dividing it among several parties. One fully consistent “piece” or “faith” must be the product of one mind, lest it be two or more related pieces or faiths strung together. The result being a collage not a painting.
Likewise, to allow the client to interject implementation guidance is equally troublesome to the process. He effectively becomes a collaborator, but worse, as he is not likely to be educated or skilled in the craft he seeks to inform. Again, the result will lack continuity.
To illustrate, you can imagine a customer at a restaurant. He is free to order Filet Mignon instead of Chicken Cordon Bleu, but it would be neither permissible nor productive for him to insist on the type of pan to use to cook it or dictate the presentation of the food on the plate. This is the domain of the chef. It is for him to produce the most delicious and beautiful presentation. The patron must accept (or reject) the full product.
In addition to consistency and integrity of design, Roark reasons that working in this matter is simply more enjoyable and fulfilling:
“But you see,” said Roark quietly, “I have, let’s say, sixty years to live. Most of that time will be spent working. I’ve chosen the work I want to do. If I find no joy in it, then I’m only condemning myself to sixty years of torture. And I can find the joy only if I do my work in the best way possible to me. But the best is a matter of standards — and I set my own standards. I inherit nothing. I stand at the end of no tradition. I may, perhaps, stand at the beginning of one.”²
If you find joy in your work, passion will follow. Can there be any greater motivator? Any greater means to increasing employee engagement? Greater quality and utility will surely be the result. Note also that Roark insists on setting his own standards of work. Standards that are mandated by an organization often act as hidden collaborators, diluting the strength and clarity of a good design. Standards have to be re-thought in context of every new project for optimal results. In the words of Steve Jobs:
“Your time is limited, so don’t waste it living someone else’s life. Don’t be trapped by dogma — which is living with the results of other people’s thinking. Don’t let the noise of others’ opinions drown out your own inner voice. And most important, have the courage to follow your heart and intuition.”³
So far, Roark’s philosophy is pretty straight forward, but there is still one question to address. How does Roark interact with the contractors that build his buildings? How does he interact with his employees? He can’t be a complete island to himself. He does need to interact with people. How does he maintain his convictions in these scenarios? Luckily, the Fountainhead addresses this as well. Here Roark explains the nature of proper collaboration:
“An architect require a great many men to erect his building. But he does not ask them to vote on his design. They work together by free agreement and each is free in his proper function. An architect uses steel, glass, concrete produced by others. But the materials remain just so much steel, glass, and concrete until he touches them. What he does with them is his individual product and his individual property. This is the only pattern for proper co-operation among men.”⁴
When Roark employs a sculptor for one of his projects, he holds to these principles:
“You work as I work for my clients. You know what I want — the rest is up to you. Do it any way you wish.”⁵
Here we see the proper model for interacting and collaborating with others — clearly delegated responsibilities. Each individual acts with full-autonomy and full-authority over their stewardship and then submits that work to each other. In this way, an employer and employee are not fundamentally different from an employer and a client. They “exchange their work by free, mutual consent to mutual advantage when their personal interests agree and they both desire the exchange.”⁶ A firm or corporation can operate like a micro free market, utilizing individuals that exchange work that is under their full control. To put it most succinctly:
“The only good which men can do to one another and the only statement of their proper relationship is — Hands off!”⁷
Finally, to address the central thesis of this essay: what are the analogous stipulations for working in the world of software development? What are the rules that can maintain product integrity and consistency for software engineers? How can we collaborate properly with each other in the large software firms that exist today? Below are a few implementation suggestions:
Strong Ownership
Delegate authority over each part of your system. Delegate this authority to individuals not teams. If you have clearly defined and separate components, divide them among your engineers. Engineers can contribute to each other’s work by sending pull requests.
Because most software engineers are now using git to manage their code revisions, this is easy to implement. Make the code owner be the only person with write permissions on a repo. Give everyone else read permissions. This way, anyone can suggest changes (through pull requests or feature requests), but only the owner has the ability to integrate it into his work.
It is important that owners really have full control. This is not a democracy where everyone votes to tell them how to write their code. They are the autocratic leaders of their domain. Engineers can and should consult each other for guidance, but they should retain ultimate authority and make the final decisions for the things they own.
Further, much more is involved in being a steward over code than simply having write permissions to a repo. Engineers should own their own deployments, continuous integration pipelines, documentation, and monitoring. They should meet with customers and understand how their product is used so they can make informed product decisions. If domain specific departments control these elements of the software process, the owner-engineer will never fully be the custodian of their work. It will prevent them from creating their highest quality work.
No Committees
Do away with architecture and shared service committees. Engineers can organize their own interactions with each other and write their own communication tools. By decentralizing these efforts, best practices can surface organically. Better tools will win the day, because engineers will rally around the best ideas and implementations. Committees or boards, on the other hand, will mandate practices that are not tuned to each necessary context. The result is more likely to be an obstacle than an aid.
Ayn Rand’s description of a committee should sound familiar:
The Council of American Builders met once a month and engaged in no tangible activity, beyond listening to speeches and sipping an inferior brand of root beer. Its membership did not grow fast, either in quantity or in quality. There were no concrete results achieved.⁸
Just say no
Each customers has their own agenda. In their perfect world, they would have your organization cater only to their needs. Do not allow a big contract to force the direction of your organization. Be calculated in who you do business with. In the works of Roark:
“… I don’t intend to build in order to have clients. I intend to have clients in order to build” “How do you propose to force you ideas on them?” “I don’t propose to force or be forced. Those who want me will come to me.”⁹
Have faith that those who want your services will eventually come, and when they do, it will be on your terms.
Do it for yourself
For my last implementation suggestion, I would simply draw your attention to how well these principles function in the open-source community. When an individual scratches an itch and writes a piece of software that they release to the world, they do it for themselves and in their own way. Even though many of their practices may differ from their peers, amazingly high quality code is produced. Individuals take care to guard their implementations; they go as slow as they need to; they spend extra time designing. The world can profit from their work, but the world does not dictate what the work will be. Others can contribute ideas and pull requests that will be accepted if they align with the author’s intentions. But, in the end, if they don’t like the results, they cannot compel the author to address their needs. Just as with Howard Roark, the relationship is a take it or leave it proposition. These are quite literally passion projects — the results have been astounding.
Linus Torvalds, the initiator of and “benevolent dictator” over the wildly successful Linux project exemplified this mentality when he said,
“most of the good programmers do programming not because they expect to get paid or get adulation by the public, but because it is fun to program.”¹⁰
If you are serious about creating a vibrant software ecosystem that implements the suggestions from the Fountainhead, look no further than the open-source community and model your process after their practices.
Summary
I am confident that giving engineers more autonomy and ownership will transform the way software is created and increase the quality of the results, and The Fountainhead provides an excellent example of what real autonomy and ownership look like.
3. Jobs, Steve, https://news.stanford.edu/news/2005/june15/jobs-061505.html
1,2,4,5,6,7,8,9. Rand, Ayn, The Fountainhead, 1943
10. Torvald, Linus, http://firstmonday.org/ojs/index.php/fm/article/view/583/504