From a software engineering perspective, what is autonomy? In a business setting, software engineers are generally required to continually produce value for the company. In this setting, autonomy is extending the ability to make most, if not all, decisions for the development of a product or service to the software engineers. As such, this includes the decision of whether to prioritize producing business value in alignment with the company’s objectives.
As an example, let’s explore the story of Jan, a software engineer for a large Fortune 50 company. Jan is an excellent senior-level engineer – her attention to detail is unmatched and her passion for building cool software unparalleled. She spends much of her free time building software, making electronics projects, and buying more spools of plastic for her 3D printer. She keeps on top of the latest trends and is interested in finding unique ways to solve problems.
Jan brings this passion to work and when she’s assigned a new task to build a simple CRUD application she rolls her eyes a bit. Such a simple application is beneath her, she thinks. A CRUD application will only utilize 0.5% of her wide-ranging skillset; what a drag. However, this CRUD application, as simple as it may seem, is important to the business. It is required to catalog the Widgets in the currently unwieldy Widget Library so that all of the developers in her organization can more effectively perform their jobs.
Now, while this CRUD application is simple, it will need to be maintained over time. Due to its criticality as a business resource, it will need full observability, support, and maintenance. It will need to be operated and maintained by a small team of developers with varying levels of expertise.
The Widget Catalog
So, at its onset, the requirements for the project are straightforward:
- Must allow for the creation, update, deletion, and retrieval of Widget taxonomy
- Must provide an authenticated web-based API
- Must synchronize with the actual Widget repositories (where the actual Widgets are stored)
With these requirements, Jan is made the technical lead and given autonomy to fulfill the requirements however she sees fit. This comes as a relief to Jan because this is an opportunity for her to exercise some of her new-found interest in functional programming languages. Most of her company is filled with “just get it done” engineers who would default to one of the wildly popular programming languages to “just get it done”. Not Jan, though; not this time.
Given that these requirements really spell out that the Widget Catalog is just a simple aggregator, Jan can spice things up a little bit by building the project with Staircase- a functional-inspired language built on top of the wildly popular Coffee programming language and runtime environment. Some baseline research shows Jan that Staircase is used by less than 1% of her company’s projects and by fewer than a handful of people. In the wild, Staircase sees a proportionate amount of popularity. It is dwarfed by titans like Coffee, Snake, Proceed, and Sea and most other modern programming languages. “Great!”, she thinks, “This will be a great way to introduce my passion for functional languages into the company’s engineering population!”
Because Jan was given autonomy to solve the problem, this is the route she decides to take. As time ticks by, she builds out a simple version of the Widget Catalog backed by Staircase. To keep things extra flexible, Jan even utilizes the “Opaque Box” Data Pattern which will surely delight any future code spelunkers. And with that, it’s time to go to production!
Production, Baby!
In order to go to production, and be a truly supportable service, it requires real-time security scanning and static code analysis. The problem? There are no security tools that support Staircase; it’s too niche. Nevertheless, there are some Jan fans in the company that can let this minor “security concern” go unaddressed.
Without the burden of compliance with corporate security policies, Widget Catalog is a “go” for launch. At first it’s a major headache to get teams to adopt it since many people are used to the old way of finding their Widgets via the Widget Library. Through persistence, though, the Widget Catalog replaces existing tooling and other developers are left with little choice.
With great adoption comes the moniker of “success”. Every developer in the company is now using the Widget Catalog Built by Jan™, but as it grows in popularity, it needs more and more maintenance to scale it out and add features that the developers need. Jan builds out a small team to help her – she must settle for junior engineers because there are too few Staircase engineers in the company. That’s not a problem, though, because Jan can train them on the way that she likes to do things. What’s more, the vanilla Staircase just isn’t fun anymore. It’s no more interesting than object-oriented programming was when she first learned it. And, even worse, Staircase isn’t a purely functional programming language. Enforcing concepts like “zero side-effects” becomes difficult given Staircase’s leaky functional abstraction.
As more time passes, the Widget Catalog is shored up with additional software libraries that bring Staircase closer to the mathematical purity found in truly functional languages like Curry. The entire team talks in terms of monoids and functors as the descent into Category Theory continues. In fact, all new team members are required to read “Practical Category Theory” and university-level mathematics education joins the list of requirements for a position on her team.
Eventually word starts to spread that “nobody understands what Jan’s code does; she must be a genius!”. Jan is feeling accomplished but eventually tires of teaching people how to fix bugs in her code. Jan receives an offer to work for the Machine-Learning-AI-Blockchain-IoT-Cloud Company® and leaves the Widget Catalog behind.
Fallout
The Widget Catalog is running fine without Jan. Without her however, most of her team disbands, leaving the company or moving into other positions. The team members, who are intimately familiar with “the way Jan did things”, are shocked that there’s a larger world of problem solving. The community support for more mainstream programming languages is vibrant and makes producing value orders of magnitude easier.
Jan’s teammates also find that it’s much easier to grow their new teams when there isn’t a requirement for a mathematics degree and when the pool of candidates is larger than “a few dozen, total”. They can effortlessly grow and scale their teams. Everyone they hire brings different sets of experience, which strengthen the team. Gone are the days of “undoing all of that OOP knowledge” (as Jan would often phrase it). Gone, too, are the days of doing everything the “Jan Way” – everyone can contribute, and the diversity of thought and expression is a welcome alternative.
The Widget Catalog languishes in a stable state. The code works and there are very few, if any, outages. But the growth in features that the Widget Catalog once saw slows to a halt. The organization that is responsible for the Widget Catalog must now find someone to fill Jan’s shoes. They post job openings for a Staircase developer, but they are too few and far between. Even folks that do have Staircase experience, don’t really know what to do with the amalgam of libraries that Jan put together to make Staircase “even more mathematically pure”.
Teams that rely on the Widget Catalog start to look for other options since it seems that the Widget Catalog is not being actively maintained. A significant migration effort is planned to move everyone to another offering. The Widget Catalog, once a functional beacon in dark object-oriented sky, withers on the vine and dies. With it, so too does Jan’s legacy.
Trust, But Verify
Maybe Jan’s story resonates with you. Maybe you are like Jan. That’s okay – the world is full of curious people and curiosity often leads to innovation. However, like many things outside of computer hardware, most decisions are not binary. Most decisions should not be made in a vacuum, devoid of context. Most decisions should be accompanied by due diligence to ensure the long-term success of whatever that decision yields.
So, while the Widget Catalog eventually faded away, there were a lot of lessons to be learned. First, when building software as part of a team that is tasked with producing value for their employer, it is not necessarily about what is “most fun” or “most interesting” for the people building it; it’s about producing said value. Further, the value produced isn’t limited to usage of the software; it includes the ability to maintain the software, build a team around it, scale that team, and solicit new ideas and larger participation.
Further, many technology companies have “Inner Source”, a kind of company-specific Open Source. Like Open Source, Inner Source leverages the collective experience of a multitude of contributors. By choosing a niche language, these contributions are limited to only those who were willing to try to to decipher the hieroglyphic-nature of the code, or those who were intimately family with the language
In the long term, having unbridled and unchecked autonomy may produce artifacts that are the antithesis of innovation and collaboration. Should engineers be curious? Absolutely. Should they experiment with new technologies? All of the time! Should they be eager to share their enthusiasm for a particular approach? Definitely! Should they do all of these things without analysis of potential long term consequences? No.
Autonomy simply provides engineers with flexibility to choose and use the tools that best suit a given application. However, autonomy is not freedom from oversight and it is not freedom from consequences. Autonomy should always be coupled with peer review because, as the saying goes: “trust, but verify”.
