By Steve Persch January 08, 2016
Eventually everyone in software development encounters Conway’s Law:
“Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.”
—Melvin Conway
A salient, and often positive, example of this law is that of decoupled web apps built by teams with clear divisions between backend and frontend developers. Those divided teams can align cleanly with the server-side and client-side components of the application. If the communication and delegation of responsibilities among the people on these teams is documented, comprehensible and efficient, you can expect the same within the workings of the application. Conway’s Law is raised more often when it manifests in inefficiencies. When the people building a website communicate poorly, the components of their site will not get along either.
Client Meetings
Compare the meetings that a web development agency has with a client to the “meetings” a website has with its client, the browser. Conway’s Law tells me that I could learn a lot about the performance of a website by observing. Meetings run well when there is a thoughtful agenda prepared ahead of time. A website prepared by Drupal or WordPress might be prepared in advance as well, and stored in a page cache.
The HTML document first delivered by a website is the agenda for the discussion that the client browser will then have with the server. The HTML agenda determines which files will be downloaded and in which order. Just as important, the HTML might exclude CSS and other assets that are not relevant to the conversation at hand. Those can be brought to the browser’s attention the next time the browser asks for a different page of HTML. When the flow of the assets in the HTML document is thoughtful and sensible, the client can get to the most important parts—the main content—as quickly as possible.
On the other hand, the HTML agenda might insist that small snippets of inline JavaScript be evaluated by the browser immediately, before it can even paint the full content. If Conway’s Law is to be believed, a website that knows how to get to the meat of the content as quickly as possible is probably produced by a team that knows how to cut the cruft out of the tops of their meetings, emails, requirements documents and everything else they do.
More Than Size
There is a shorthand—especially in the tech community—that for a team to be fast it has to be small. It’s often true that smaller, newer startups can move faster than larger, older companies. As companies grow in size and age, the penalties for disorganization become bigger. Young, small companies can often rely on word of mouth and collective memory to keep track of how things are done. Relying on that kind of culture is like using global state in PHP code. It scales to a point, and then breaks down painfully. Big teams pay big penalties for disorganized processes.
When big projects fail it is easy to blame the size of the team; too many stakeholders. The same pattern of blame happens on unusably slow websites. It is easy to point at JavaScript files as being too large. This focus on size can miss the point. I have certainly fallen into this trap. What can be done when you join a project with the somewhat vague direction to “make the site faster?” In a few minutes I can try to measure each piece’s size and minify. It is might take hours to describe each piece’s actual purpose. A team must understand how all of their pieces fit together in order to streamline the delivery of the site. Without understanding you are left with surface-level metrics like file size which only hint at performance bottlenecks.
The path toward performant websites requires constantly asking ‘why’. Why are we loading two different analytics platforms? The answer might be because there are two distinct groups of people tracking the website’s traffic, and they do not talk to each other. Ask why again. Evolving your website and making it faster will require evolving your team and analyzing how it works. Here I’ll plug my last blog post, Agile Your Agile, which covered how to adopt new project processes. At DrupalCamp New Jersey I will be presenting on performance further and digging into more specific ways team structure can impact each layer of website performance. For a deeper look at the shortcoming of size as a web performance metric and how it can unnecessarily raise body image issues, read this post from Marc Drummond.
 |
Get DevOps Consulting |
Topics: Agencies, Development, Digital Agencies, Speed & Performance
