For example, an employee may
choose a new technology that hasn’t
been road tested enough in the wild,
and later that technology falls apart
under heavy production load. Another
example is someone writing code for
a particular function, without knowing that code already exists in a shared
library written by another team—
reinventing the wheel and making maintenance and updates more challenging
in the future.
On larger teams, one of the common places these knowledge gaps exist
is between teams or across disciplines:
for example, when someone in operations creates a Band-Aid in one area of
the system (like repetitively restarting a
service to fix a memory leak), because
the underlying issue is just too complex
to diagnose and fix (the person doesn’t
have enough understanding of the running code to fix the leaky resources).
Everyday, people are making decisions with imperfect knowledge. The
real question is, how can you improve
the knowledge gaps and leverage your
team to make better decisions?
Here are a few strategies that can
help your team work better, and in turn
help you create better software. While
none of these strategies is a new idea,
they are all great reminders of ways to
make your teams and processes that
Define how you will work together.
Whether you are creating an API or consuming someone else’s data, having a
clearly defined contract is the first step
toward a good working relationship.
When you work with another service it
is important to understand the guardrails and best practices for consuming
that service. For example, you should
establish the payload maximums and
discuss the frequency and usage guidelines. If for some reason the existing API
doesn’t meet your needs, then instead
of just working around it, talk about
why it isn’t working and collaboratively
figure out the best way to solve the problem (whether it would be updating the
API or leveraging a caching strategy).
The key here is communication.
Decide how you will test the whole
system. One of the most important
strategies is to think about how you
will truly test the end-to-end functionality of a system. Having tests
that investigate only your parts of the
system (like the back-end APIs) but
not the end-customer experience can
result in uncaught errors or issues
(such as my opening example of caching). The challenge then becomes,
who will own these tests? And who
will run these tests and be responsible for handling failures? You may
not want tests for every scenario, but
certainly the most important ones
are worth having.
When bugs happen, work together
to solve them. When problems arise,
try to avoid solutions that only mask
the underlying issue. Instead, work together to figure out what the real cause
of the problem is, and then make a
decision as a team on the best way of
addressing it going forward. This way
the entire team can learn more about
how the systems work, and everyone
involved will be informed of any potential Band-Aids.
Use versioning. When another team
consumes something you created (an
API, a library, a package), versioning
is the smartest way of making updates
and keeping everyone on the same
page with those changes. There is nothing worse than relying on something
and having it change underneath you.
The author may think the changes are
minor or innocuous, but sometimes
those changes can have unintended
consequences upstream. By starting
with versions, it is easy to keep every-
one in check and predictably manage
Create coding standards. Following
standards can be really helpful when it
comes to code maintenance. When you
depend on someone else and have access to that source code, being able to
look at it—and know what you are looking at—can give you an edge in understanding, debugging, and integration.
Similarly, in situations where styles are
inherited and reused throughout the
code, having tools like a style guide can
help ensure that the user interfaces look
consistent—even when different teams
throughout the company develop them.
Do code reviews. One of the best
ways of bridging knowledge gaps on a
team is to encourage sharing among
team members. When other members
review and give feedback, they learn
the code, too. This is a great way of
spreading knowledge across the team.
Of course, the real key to great software architecture for a system developed by lots of different people is to
have great communication. You want
everyone to talk openly to everyone
else, ask questions, and share ideas.
This means creating a culture where
people are open and have a sense of
ownership—even for parts of the system they didn’t write.
Hitchhiker’s Guide to Biomorphic Software
Kenneth N. Lodding
Ground Control to Architect Tom...
Kate Matsudaira ( katemats.com) is the founder of
her own company, Popforms. Previously she worked in
engineering leadership roles at companies like Decide
(acquired by eBay), Moz, Microsoft, and Amazon.
© 2016 ACM 0001-0782/16/09 $15.00