Meet Eunice. Eunice is a unit of code, and she and other units like her are what coders live to write, or at least write to live. A unit of code is the smallest testable part of an application. Coders like to break their code into pieces, such as units, so that it’s better organized. This facilitates the ability to validate, test, and reason about what the behavior and nature of the application should be. By following the events of Eunice’s life — from design to construction to testing to maintenance to decommissioning — I hope non-programmers can catch a glimpse of what it’s like to create and be held responsible for these units, and that programmers can enjoy a reflection on their work from a different perspective.
Life Before Kids
“We are such stuff As dreams are made on; and our little life Is rounded with a sleep.”
~ Shakespeare, The Tempest
To begin our story, we must go far back, before Eunice’s entire family was even a twinkle in a product owner’s eye. It’s well known that the many people we meet throughout life help shape our idea of the people with whom we’d like to start a family. Similarly, a team’s idea of the final product is best shaped through the interactions of many. In Eunice’s pre-history, these interactions included user interviews, journey mapping, persona building, and ethnographic studies. Later, as a shared understanding of the essential needs of the user and nature of the work were established among the team and stakeholders, the focus turned to prototyping, mockup iteration, focus groups, and architecting. At this point proofs of concept appeared, in titillating resemblances of things to come. Planning followed, in the form of story mapping, grooming, and a rough roadmap was even created by the project manager or someone in a similar role, to the slight apprehension of the developers.
During all this research and planning, developers had also been busy designing and setting up Eunice’s hometown. She’ll live in a virtual private cloud, in a spacious serverless architecture, with plenty of room to scale, a database to hold her family’s memories, and a messaging queue and API gateway to communicate with relatives. Much care has gone into ensuring the strength of the walls, entrances, and exits of this little town in the cloud, and the keys to the town are stored in a special key management system to ensure their proper handling. It’s a dangerous world outside those walls, with bandits and thieves of all shapes and sizes.
“A writer is someone for whom writing is more difficult than it is for other people.”
~ Thomas Mann, Essays of Three Decades
Initial construction of her hometown will continue as Eunice’s family also starts to take form. The stories written about them during planning are being pulled by developers and implemented. Eunice is one of the first units of code to be created. Tests are written to make sure she behaves according to the wishes of her creators. Further tests are written to ensure she and her siblings work together to accomplish their overall mission. Eunice’s embryonic state is a constantly shape-shifting bundle of logic, evolving each time her creator encounters edge cases, bugs, and performance and security issues. As her siblings are written, her shape continues to change in order to accommodate their integration. It can be disappointing to the parties involved when the act of human inception is shorter than expected, however in light of all that we have learned about Eunice so far, you may not be surprised to hear that in Eunice’s case (and the case of most of her siblings), the opposite disappointment is encountered: it takes longer than planned.
“When we are born, we cry, that we are come To this great stage of fools.”
~ Shakespeare, King Lear
Among Eunice’s relatives, there is a saying that goes “A well-constructed birth begins with a well-constructed birth canal”. Eunice’s owners take it to heart; they have made what they think is a pretty good one. It begins on her creator’s machine. Once her creator is satisfied with their work, they’ll push to the central code repository all the commits that form her current state, where Eunice will sit on a branch while other developers inspect her for quality issues. A continuous integration service runs all her tests and those of her family. Upon the approval of the other developers and the passing of the tests, the “bough breaks” and the branch collapses into the master branch. Eunice is now part of the official codebase, and her creator appropriately harbors a small amount of pride for the little thing.
“I solemnly swear that I am up to no good.”
~ J.K. Rowling, Harry Potter and the Prisoner of Azkaban
The continuous integration service now runs all the tests against the newly changed master branch, and then builds all the code into a runnable piece of software, deploying it out to a test, or “sandbox” environment. Eunice will spend her childhood here, where product owners and other initial users will get to meet her for the first time and decide whether they like her or not. If you spend enough time around human children, you will likely encounter bugs, germs, messes, tantrums, and other unpleasant things. The same is true of young code. This is why it’s important to give them a safe place where they can do no real damage as they mature into the units they were meant to be.
The Teenage Years
“Youth is a dream, a form of chemical madness.”
~ F. Scott Fitzgerald, Tales of the Jazz Age
Every few days, the product owner gives the green light for another production release and one of these days is Eunice’s coming of age moment. At last, she’s in production, and she and her creator swear she can take care of herself now. Some things don’t go according to promise, however. Despite all the testing and careful design, complex evolving systems inevitably produce at least a few errors. Despite her claims of maturity, Eunice has yet another bug, and, in a similar way to how teenagers seem to occasionally revert to an infantile state, she goes back through the birthing and childhood process of rewriting parts of her code and building yet further tests to ensure this new bug doesn’t happen again when she encounters future changes.
“Middle age is when your age starts to show around your middle.”
~ Bob Hope
As the software gets used over time, things will change for Eunice’s family. Some of her relatives have passed away, and Eunice is increasingly surrounded with a younger, newer crowd. This feels awkward for Eunice and her owners, and the more awkward it gets, the more they feel like it’s time to make some changes. Eunice’s workload has increased and her performance has come into question. There is talk about going and “buying the ferrari”, running her on faster, more expensive machines. Eventually, the owners decide to instead whip Eunice into shape by means of refactoring, which also involves the equivalent of cosmetic surgery, where Eunice’s interface changes entirely. Her makeover is complete, and she’s fabulous once again. If Eunice were any other type of heroine, the above may sound shallow and vain, but we must remember that one should never say to a unit of code “I love you just the way you are”. However cruel it seems, Eunice’s owners should never become too attached to her and should always be willing to give her up or change her. Admittedly, as an owner, it can be a little difficult to let go after pouring so much energy and creativity into the creation and/or maintenance of a unit and its siblings. It takes maturity to step back and remember the big picture.
“Reason thus with life: If I do lose thee, I do lose a thing That none but fools would keep.”
~ Shakespeare, Measure for Measure
There comes a time in every unit’s life when their current owners decide that the unit and her family have outlived their usefulness and it’s time to send them off to the Great Big Revision Log in the cloud. Eunice’s hometown and everyone in it have become so old that obsolescence and deprecation are everywhere, and it’s becoming increasingly difficult to find owners willing or able to maintain it. The decision to create an entirely new system doesn’t come lightly, and arguments against it have kept it from happening prematurely. Creating a replacement will be difficult. Eunice’s family has gained much wisdom over the years, in the form of arcane but valuable business rules, interactions that have been finally tweaked just right after many iterations, and veteran perspectives on how things should be done. Luckily, this wisdom can be read in tests that were built around the code, code comments, old issue logs, training manuals, and wikis. Current users prove to be one of the most valuable and accessible sources of knowledge about the software. Careful disposal of Eunice and her family prove to be a lot of work, but her owners eventually find their efforts were worth it. This is where we must say goodbye to our old friend Eunice.
I hope you enjoyed journeying with me through the ups and downs of her life!