600 million years ago, the planet was inhabited by simple organisms. There was no predatory behavior and life was peaceful. Then over time, our nervous systems got more and more complex and interactions increased exponentially. All of a sudden, we needed to be able to sense our environment and the beings around us in order to stay alive. We started to evolve, along the way we developed tools like eyes and ears that helped us get a better understanding of what was happening around us.
We learned to interact with each other and our environment.
This metaphor holds up very well when held against the current state of web development. Users are coming at us from more directions than they ever have and (either through user-expectations and technological advances) the environment is ever-changing. There is an opportunity here for us to evolve.
Evolving our nervous systems
The environment around us is changing. Perhaps we should too, but how should we be changing? In evolution theory, a species branches off from its current form because of a change in the environment around it and in turn forms a new "subspecies". This new species is better at solving a small set of specific problems that endanger its survival. They become "specialists". Perhaps we can apply something similar to web development. Let's look at how we as developers can work towards becoming a group of "specialists".
For reference: We currently house 2 product teams with each: 2 frontenders, 2-3 backenders, 1 designer and 1 product-owner.
The goal here is to develop a framework that helps you communicate and improves expertise. The boundaries you set as a group of specialists indicate the points of contact you have with the outside world, be it other teams, or be it your users.
Gaining eyes and ears
After defining what kind of specialism we could benefit from, we should start working towards a better understanding of our environment. A big part of this is knowing where you need to go and what is happening around us. We need eyes and ears.
A pair of eyes
We are trying to change our behavior in order to become better adapted to our environment. With evolution by natural selection, there is a clear indicator of whether or not we are heading in the right way, survival. However, it is probably for the better to look at a less radical approach when applying this metaphor.
As a group of specialists, it is very useful to know if our change is having the desired effect. We should try to measure our progress.
You have probably come up with a few themes or goals that you want to achieve while defining your specialism. It is important that you really tailor these to your team. There is no set of themes that will work for every team. For instance, a few of the themes that worked for us when we started moving towards a more separated existence:
Developer experience
Most of the code at MyOnlineStore (although this is decreasing at a pretty fast rate) lives in a monolithic application, which is a giant Symfony application. Symfony isn't really built for having a wide array of frontend tooling that can help us build features faster. We wanted to have independent tooling that would not interfere with Symfony. You could keep track of your developer satisfaction as well as to measure how fast your javascript builds are compared to before.
Deliver faster
Getting things done was hard at the time and often required one or more handoffs with backenders. This often clogged up the delivery of a feature. Backenders wrote controllers in PHP (in a traditional MVC architecture) that would directly affect user interaction. We would be a lot faster if we could deliver the entirety of a feature with just the UX designers and frontenders. Backend would still supply us with the data, but we would be able to freely interpret this. To keep an eye on how much faster you can deliver, you could start looking at the number of handoffs you are skipping. Or how your estimations for user-stories change (or the amount you deliver within the same estimations).
Deliver better
The complexity of our client applications would suddenly increase. We wanted to at least try to make this as sound as possible by writing tests and documentation. Our frontend stack at the time didn't lend itself for this, however. We decided that we should start migrating to a javascript framework in favor of a template language like Twig. The progress here could be measured by the amount of test coverage you can gather or a percentual decrease in bugs.
Themes like this can help you stay on track of the change you are trying to apply to your teams. Once you are starting to become more comfortable with your newfound specialism, you could start turning these into metrics to track your performance. "Delivering better" could be redefined as % of bugs that occur compared to before. "Developer experience" could be tracked by taking internal surveys or by measuring the time spent waiting for code to build or tests to run. Note that these themes or metrics are never set in stone and you might be required to change directions once your environment changes again (which it certainly will).
A set of ears
Now that we know what we need to look for when starting this process, we need to talk about the things that we cannot visually perceive. Instead of only looking at our progress we should also start listening to our environment.
Implicit knowledge
Like I mentioned earlier, handoffs are horrible (for us). The team alignment required to get things done is a pretty hard topic to get right. However, one thing that is great about handoffs is the fact that you are required to share knowledge formally. Almost every application and every feature of that application has undocumented knowledge that could turn out to be important somewhere along the road. Something that works great for us is refining user-stories together with other specialisms and working our way towards the implementation from a user perspective. This makes sure that you can still rely on all specialisms involved when solving a problem that a user faces, instead of letting team members like UX designers or frontend developers be the only ones responsible for user experience.
Traceability of bugs
Another thing that you could lose track of is the traceability of bugs. A lot of teams that migrate towards a more headless approach may come from an application that renders server-sided documents and fetches data synchronously with something like PHP or Ruby on Rails. This is a pretty big contrast compared to modern javascript frameworks that tend to heavily focus on asynchronous data-fetching. Because of this, bugs can have several surface points. It is important that you can follow errors all the way down to the origin, wherever it may be. There are several tools (we use Rollbar for this) that let you log errors across multiple applications or services by providing some form of a shared identifier everywhere in your stack. That way you can easily follow the bug on its path of wreckage and plug the hole it came through.
Walking on land
I hope our story has prepared you a bit for what will come when changing your team or organization. This story is by far a conclusive approach but it helped us get where we are today. At the time of writing, we are in a happy symbiotic relationship with our environment and our investments are starting to pay their dividends. Our developer experience has drastically improved, we are delivering a lot faster and are delivering more robust client applications than we ever have. We are at a point where we want to turn the themes we set into metrics that we can actively measure and work towards improving.
Like actual evolution, this is not a fast process, not 600 million years long, but still pretty slow. Getting proficient in these topics is something that takes time and practice because it fundamentally changes the way you interact with each other. Give it some time and keep your eyes and ears on what you are trying to achieve together.
Time for you to venture out there and explore everything your environment has to offer!
- This article was heavily inspired by one of my favorite blogposts/talks: https://emptysqua.re/blog/api-evolution-the-right-way/ by A. Jesse Jiryu Davis
- The beautiful imagery comes from a collection of old atlases bundled here: https://www.flickr.com/photos/biodivlibrary/albums/page1
- Another inspiration for this article was the book "Other Minds - The Octopus and the Evolution of Intelligent Life" by Peter Godfrey-Smith
Top comments (0)