practice

DOI:10.1145/ 2948981
impacted the mobile experience where
Article development led by
queue.acm.org
browsers cant handle as many concur-
rent requests, so the front-end team
made the decision to cache part of the
When people dont work well together data locally.
they make bad decisions. The crux of the issue was the teams
had not communicated well with each
BY KATE MATSUDAIRA other. Neither team had taken the time
to understand the needs of the other

Bad Software
team. The result was a weird caching
bug that affected the end user.
You might be thinking this could
never happen on your team, but the

Architecture
reality is that when many different
people are working on a problem,
each could have a different idea about
the best solution. And when you dont

Is a People
have a team that works well together,
it can hurt your software design, along
with its maintainability, scalability,
and performance.

Problem
Most software systems consist of
parts and pieces that come together
to perform a larger function. Those
parts and pieces can be thought out
and planned, and work together in
a beautiful orchestra. Or they can be
designed by individuals, each one as
unique as the person who created it.
The challenge is if you want your soft-
ware to last, uniformity and predict-
ability are good thingsunique snow-
I T A LL STARTEDwith a bug. flakes are not.
One of the challenges of manag-
Customers were complaining their information ing a software team is balancing the
was out of date on the website. They would make an knowledge levels across your staff. In
update and for some reason their changes were not an ideal world, every employee would
know enough to do his or her job well,
being reflected. Caching seemed like the obvious but the truth is in larger software
problem, but once we started diving into the details, teams there is always someone get-
ting up to speed on something: a new
we realized it was a much bigger issue. technology, a way of building soft-
What we discovered was the back-end team managing ware, or even the way your systems
the APIs and data didnt see eye-to-eye with the front- work. When someone doesnt know
something well enough to do a great
end team consuming the data. The back-end team job, there is a knowledge gap, and this
designed the APIs the way they thought the data should is pretty common.
When building software and moving
be queriedone that was optimized for the way they fast, people dont always have enough
had designed the schema. The challenge was that when time to learn everything they need to
the front-end team wrote the interface, the API seemed bridge their gaps. So each person will
make assumptions or concessions that
clunky to themthere were too many parameters, and can impact the effectiveness of any soft-
they had to make too many calls. This negatively ware that individual works on.

42 COMM UNICATIO NS O F THE ACM | S EPTEM BER 201 6 | VO L . 5 9 | N O. 9

 For example, an employee may Decide how you will test the whole those changes can have unintended
choose a new technology that hasnt system. One of the most important consequences upstream. By starting
been road tested enough in the wild, strategies is to think about how you with versions, it is easy to keep every-
and later that technology falls apart will truly test the end-to-end func- one in check and predictably manage
under heavy production load. Another tionality of a system. Having tests their dependencies.
example is someone writing code for that investigate only your parts of the Create coding standards. Following
a particular function, without know- system (like the back-end APIs) but standards can be really helpful when it
ing that code already exists in a shared not the end-customer experience can comes to code maintenance. When you
library written by another teamrein- result in uncaught errors or issues depend on someone else and have ac-
venting the wheel and making mainte- (such as my opening example of cach- cess to that source code, being able to
nance and updates more challenging ing). The challenge then becomes, look at itand know what you are look-
in the future. who will own these tests? And who ing atcan give you an edge in under-
On larger teams, one of the com- will run these tests and be respon- standing, debugging, and integration.
mon places these knowledge gaps exist sible for handling failures? You may Similarly, in situations where styles are
is between teams or across disciplines: not want tests for every scenario, but inherited and reused throughout the
for example, when someone in opera- certainly the most important ones code, having tools like a style guide can
tions creates a Band-Aid in one area of are worth having. help ensure that the user interfaces look
the system (like repetitively restarting a consistenteven when different teams
service to fix a memory leak), because throughout the company develop them.
the underlying issue is just too complex Do code reviews. One of the best
to diagnose and fix (the person doesnt ways of bridging knowledge gaps on a
have enough understanding of the run- team is to encourage sharing among
ning code to fix the leaky resources). team members. When other members
Everyday, people are making deci- review and give feedback, they learn
sions with imperfect knowledge. The the code, too. This is a great way of
real question is, how can you improve spreading knowledge across the team.
the knowledge gaps and leverage your Of course, the real key to great soft-
team to make better decisions? ware architecture for a system devel-
Here are a few strategies that can oped by lots of different people is to
help your team work better, and in turn have great communication. You want
help you create better software. While everyone to talk openly to everyone
none of these strategies is a new idea, else, ask questions, and share ideas.
they are all great reminders of ways to When bugs happen, work together This means creating a culture where
make your teams and processes that to solve them. When problems arise, people are open and have a sense of
much better. try to avoid solutions that only mask ownershipeven for parts of the sys-
Define how you will work together. the underlying issue. Instead, work to- tem they didnt write.
Whether you are creating an API or con- gether to figure out what the real cause
suming someone elses data, having a of the problem is, and then make a
Related articles
clearly defined contract is the first step decision as a team on the best way of on queue.acm.org
toward a good working relationship. addressing it going forward. This way
Hitchhikers Guide to Biomorphic Software
When you work with another service it the entire team can learn more about
Kenneth N. Lodding
is important to understand the guard- how the systems work, and everyone http://queue.acm.org/detail.cfm?id=1016985
rails and best practices for consuming involved will be informed of any poten-
Ground Control to Architect Tom...
that service. For example, you should tial Band-Aids. Alex Bell
establish the payload maximums and Use versioning. When another team http://queue.acm.org/detail.cfm?id=1317396
discuss the frequency and usage guide- consumes something you created (an Broken Builds
lines. If for some reason the existing API API, a library, a package), versioning Kode Vicious
doesnt meet your needs, then instead is the smartest way of making updates http://queue.acm.org/detail.cfm?id=1740550
of just working around it, talk about and keeping everyone on the same
IMAGE BY MICH AEL D. BROW N

why it isnt working and collaboratively page with those changes. There is noth- Kate Matsudaira (katemats.com) is the founder of
her own company, Popforms. Previously she worked in
figure out the best way to solve the prob- ing worse than relying on something engineering leadership roles at companies like Decide
lem (whether it would be updating the and having it change underneath you. (acquired by eBay), Moz, Microsoft, and Amazon.

API or leveraging a caching strategy). The author may think the changes are
The key here is communication. minor or innocuous, but sometimes 2016 ACM 0001-0782/16/09 $15.00

SE PT E MB E R 2 0 1 6 | VO L. 59 | N O. 9 | C OM M U N IC AT ION S OF T HE ACM 43