We can apply Conway’s Law to learn about a company’s structure and values, and the lessons are insightful to insiders & outsiders

Catapulted into most developer’s set of oft-quoted computer laws by The Mythical Man Month, Conway’s Law says:

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations

Typically when developers mention this, it is to complain about how complicated their current project is while lamenting that change is out of their control. And they’re usually right. But what if this whole time we’ve been looking at Conway’s Law from too narrow of a vantage point.

Rather than typically applying Conway’s Law to our own organization’s code base, we should be using it to gain opinions of other companies.

It turns out when you apply this lens, you start to think of view-source: as an invaluable piece of research on par with Bloomberg or Glassdoor (and actually probably more accurate). I’ll walk through a couple examples (ignoring the obvious like broken links, starting with some basics and ending on obscure corners). In the end you’ll have more tools for answering questions like “Do I want to work for company X?” and “Why is company Y so good at Z?” You’ll see a lot of these answers can be inferred from the very ways their website is assembled. I’ll cover 8 aspects that you apply in-part or in-total to your research:

1. Where is the site hosted? Who does the SSL? Who does the CDN? Is it fast?
2. Is the site all on one application, or a bunch of them? Is there a consistent feel across all the sections?
3. How many 3rd party assets are loaded on the site? None? Some? Too many to count?
4. The JavaScript and CSS — is it consistent? Is it modular? Is there a lot of redundancy? Are there 17 different personalities at work?
5. What about the comments in the code, and the variable naming?
6. Are there a lot of antiquated artifacts on the page?
7. The 3rd parties that are integrated — are they quality? Is there consistency? Is there diversity?
8. How does the DOM render?

Also keep in mind that not everyone is in the web design business, but vendor selection can say just as much as a self-developed website. Was the agency local? They appreciate supporting their local community. Is it an out-of-the-box WordPress-esque solution? They realize not everything needs to be a special snowflake. When the site is designed out-of-the-house, not as many of these lessons can be applied — but some of them are universal.

Aspect 1: Where is the site hosted? Who does the SSL? Who does the CDN? Is it fast?

Like I warned, the first couple are pretty obvious. You can use tools like https://www.hostingchecker.com/ and https://www.sslshopper.com/ssl-checker.html to get the answers, if you’re not comfortable with terminal. But with this information, you can get a feeling for things like:

• Do they host it themselves? They might suffer from NotInventedHere-itis.
• Do they use a bargain basement $1.99/mo unlimited bandwidth service? They’re probably a bit too frugal.
• Is it slow? They probably use the phrase “Well it worked fine for me” a lot before sayings like “Tell me more about your experience”.
• Does it have an SSL and is it using https? They care about security and aren’t waiting until the last possible second to move away from http.

Aspect 2: Is the site all on one application, or a bunch of them? Is there a consistent feel across all the sections?

There’s a Mark Cuban quote that is great for this question:

Know your core competencies and focus on being great at them.

Generally every part of the website that isn’t directly related to the business’ core purpose should try to leverage some other company’s work (ideally something open source), so the company can focus on their competency. But if this is done, and the way it is done, says a lot:

• Did the company roll their own blogging solution? Unless they’re in the business of making blog software, its a sign that they spend cycles on things they should be using something off the shelf. The same goes with career portals / applicant tracking systems.
• Do you see 5 different versions of the company’s logo? They’re probably spread too thin to make sure they’re consistently giving the same impression, or there’s too much red tape that the effort to look good isn’t worth it.
• Are some of their partners so sub-par that it makes you wince? And I’m not talking “Eww, they use Chrome and I like Firefox”, more like “Eww, they’re recommending people upgrade to IE6”. Then they’re probably a company that either carries a lot of baggage, fears change, or tends to stick with what the CEO’s wife once recommended at a holiday party. The phrase “Nobody Ever Got Fired for Buying IBM” probably gets mentioned a lot during RFPs…

Aspect 3: How many 3rd party assets are loaded on the site? None? Some? Too many to count?

This one is a lot like the previous point, but we’ve multiplied the nerd quota. This one also probably says more about the people managing the IT staff/servers/architecture and less about the people making the business decisions. By evaluating the 3rd party assets being loaded, you’ll uncover a lot of subtle & meaningful points:

• Don’t see any 3rd party assets loaded? The company might have an out-of-control ego and frequently say “We’re too complicated nobody understands us” or “We can do it better ourselves.” Its good to be proud & competent, but there’s a point where even Einstein recognized help made him better.
• Are there dozens loaded on the same page? Variety might be the spice of life, but ever tried cooking with every spice in your pantry? I still don’t get what I’m supposed to use Alum for, but I digress. The point is that WAY too many 3rd party assets, especially ones that are fundamentally the same (like ShareThis.com and AddThis.com), indicates an inability to make choices or self-regulate, which rarely leads towards happiness.

Aspect 4: The JavaScript and CSS — is it consistent? Is it modular? Is there a lot of redundancy? Are there 17 different personalities at work?

Now we’re getting closer to the core on Conway’s law. Once you have more than 30 developers, it becomes really complicated to have consistent in front-end, back-end and infrastructure. Seeing consistency is a great thing — it implies strong communication, well-established standards, and wisely applied technologies like linting. If you’re browsing through the front-end and see occasionally discrepancies, it means you’re working with humans (and that’s a good thing). But if you’re seeing frequent & far-reaching flavors of coding:

• Are there an overwhelming number of case variations (camel, snake, kebab, StUdLyCaPs)? Then you’re seeing a company that doesn’t apply coding standards. Style guides & consistency are good because it shows a company that doesn’t get bogged down by turnover and can flex team sizes based on demand. A lack of it might indicate a place where career growth or variation aren’t common.
• Do you see the same one (either different or identical versions) several times? Then you’re looking at a company that has a hard time with internal communication & collaboration. If the company can’t handle simple things like “Yeh, I’ve already loaded jQuery so don’t worry about it” then how can the company handle complex things?
• Do you encounter 3 types of form validation and 7 forms of date calendars? Then you’re probably looking at a company that isn’t very good with internal knowledge sharing and has some pretty large silos between teams.

Aspect 5: What about the comments in the code, and the variable naming?

Ignoring how you feel about code comments in general, the sheer presence of the comments can shed a lot of light:

• Are there large sections commented out and talking about something being broken?
• Are there several different large blocks of comments in very different styles? Especially of the “Something something starts here” and “Something something ends here” variety?
• Are there swears words in the code base? Names of developers on the team? Names of competitors or clear signs of large copy & pasting?

In moderation, most of these aren’t a big deal — we’ve all been there. But if you see these on a large scale, there’s a systematic lack of quality control that’s probably worth consideration. If there’s a lot of piecemeal pasting of code, expect a general vibe of “whatever it takes to get it done” and some rather fragile systems.

Aspect 6: Are there a lot of antiquated artifacts on the page?

In our personal lives, we often hold out hoped that our once loved service/protocol makes a comeback *coff*Wave*coff*. But there’s a point when the company’s website should stop promoting its Vine channel. So while browsing the website, you see some sections & links that have collected dust, there are some strong lessons to take:

• Are old social media accounts still recommended? It either means the sunk cost fallacy is embraced by marketing, there’s a lack of engagement between IT & the rest of the company (in this case marketing or communications), or simply that the programmers are expected to manage communication channels themselves.
• Are deprecated parts of the company still proudly served on the site? A lack of house keeping for company links (either 410ing or updating to explain the sunset) spells either disarray, or too many “pivots” have made the company numb to cleaning up after themselves.
• Are old versions of the site just left up without anyone turning off the lights? The broken windows theory applies to companies just as much as cities.

Aspect 7: The 3rd parties that are integrated — are they quality? Is there consistency? Is there diversity?

You can’t pick your family, but you can pick your friends and pick the 3rd parties that you work with. And just like friends are a reflection of your values, you can learn from 3rd parties:

• Don’t see any 3rd party integrations? Either serious trust issues or an out-of-control legal department.
• See way too many 3rd parties & a lot of overlap? You’re likely either seeing a culture of unchecked ADHD, poor internal communication (e.g., team A isn’t aware of team B’s analytics capabilities), or a culture that relies too little on testing & too much on seeing what sticks.

Aspect 8: How does the DOM render?

While I deeply appreciate the Two-Pizza Team Rule, there’s an art form to making sure that the teams still behave as a well-oiled machine and not a splattering of islands in roughly the same ocean. I split that analogy, but you get my point.

Honestly this point has a lot in common with Aspect 4, and there’s an argument being made of combining them. But Aspect 4 doesn’t offer the same visual interpretation as the DOM assembly, and for that reason I split them out. When you visualize the DOM, a lot of pieces become clear:

• Do you see common patterns? That’s great! It means people share.
• Do the components mesh together relatively seamlessly, or are there some obvious points of isolation? If it feels like pieces of the DOM have to be split onto their own islands, that’s probably how teams are treated.
• Do you find 3D DOM rendering fascinating? Me too. I get sucked into it over and over. This doesn’t say much about the company, but it is a great way to impress & intimidate anyone looking over your shoulder.

What did I miss?

There are a lot of opinions here, and a huge amount of exceptions to all of these viewpoints. But I believe that there’s some substance here to help people — from jobseekers to competitors to admirers — to start to learn a lot and take a hard look in the mirror.

If you have any suggestions for alterations or improvements, I would love to hear them!

Originally posted on Medium.