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.”
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.
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.
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.
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