In 1977, an important 20th-century architect and prolific author, Christopher Alexander, wrote a book, “A Pattern Language: Towns, Buildings, Construction” followed in 1979 by another book, “The Timeless Way of Building”. These were books about architectural thinking where patterns, a pattern language, and a “way” of building were discussed in depth.
The object-oriented programming world took notice and the seminal book, “Design Patterns: Elements of Reusable Object-Oriented Software”, emerged and changed the software world forever.
Over recent years, I’ve seen those early books re-enter into software conversations, but not with respect to the software organization itself. Could there be that connection too? I had wondered that from time to time, but when I arrived at Stitch Fix and observed the very purposeful way that our software organization had been built, I was pretty certain there was.
In this article, I share my thoughts on “the timeless way” of building a software organization and provide some examples of what we’ve done here at Stitch Fix.
Patterns and Pattern Language
As I write this, I’m visiting the Financial District of San Francisco and looking out the window. I see city blocks, buildings, doors, windows, roof-tops, traffic lights, stores, and people. Depending upon which direction I look, some parts (and people) even appear older than others.
Though I’m not from this part of the United States, nothing surprises me—I believe I could enter into the streets and eventually find my way around. Everything: city blocks, traffic lights, doors, etc, works the way I expect.
I fully expect I’ll meet with some surprises, but the familiarity, the recognition…the patterns, they all provide me with a baseline confidence that I’m in a familiar place.
Over the ages, patterns have been developed to build buildings and plan cities and these patterns have stood the test of time. In essence, we’ve developed a pattern language which makes building new cities and towns a (mostly) trivial process.
So as we refocus back on the software organization, we see some very desireable parallels. When we introduce new people into our organization, we’d like them to feel as comfortable and familiar as they would walking on (most) city blocks. We’d like for our patterns and pattern language to assure that this is the case.
Some Pattern Examples
You will not be surprised to find out that we at Stitch Fix have our own patterns and an evolving pattern language. We’ve never, as far as I know, discussed them using these exact terms, but we have them and they have helped.
To clarify what I mean, we don’t explicitly use the words “pattern” or “pattern language”, we just identify problems, solve and document them, and disseminate the information aggressively.
And now some examples harvested from this very blog:
- Startup Super Powers. A great article from 2013 which details several of our tactical practices and philosophies for our software development. It is a subset of a larger pattern language that has continued to serve us well.
- Rails Application Templates. An article focused on a pattern introduced in the “Startup Super Powers” article; the importance of building applications in a standardized way. The impact on your organization is the “sameness” and correctness of the applications that will eventually inhabit your eco system. Familiarity, like the building next door.
- ElasticSearch and Denormalization in Rails. A pattern to mitigate the problem of slow query response times at large scales. This established precedent allows us to solve similar problems in a faster, more confident way.
- Technology Radar. And finally, one last pattern example. It’s helpful to define and maintain a “blessed” architecture which limits the choices of ingredients in your apps and services. This pattern dovetails nicely with the first two examples and provides a level of transparency internally (and externally, if desired) for technology choices. The implementation of the Technology Radar is managed through a system (for more on systems, keep reading!).
I could go on and on citing examples from our fantastic blog, but I think you get the point. You want to develop a pattern language and a library of patterns for problems that you’ve solved. These become “your timeless way”; your operating system, your DNA.
Having a “way” manifests itself in a variety of positive scenarios. Consider these few for starters:
- Increased intuition and familiarity. Your apps feel the same and seem like they have one sane voice. They are familiar in the way it feels when dropped into an app which has a familiar structure (e.g. Ruby on Rails, Angular, etc.). This city block seems the same!
- Leverage. Your apps leverage the talents of your most highly-skilled developers; and/or, the collective benefits of all your organization’s problem solving. They are high-quality, accurate and maintainable apps that are developed with the best knowledge on-hand. Looks like this building was built by those great architects!
- Speed and Efficiency. When it is easy to generate apps that leverage your problem solving discoveries and which provide baked-in familiarity, you are able to iterate very quickly. To return to our principal analogy, you are able to build blocks and cities very rapidly and thereby add huge value to your business.
Worth doing? Obviously, we think so and our patterns and pattern language have served us well. It’s a big reason why we’ve been able to accomplish big things in our 5 years.
Systems Thinking
Earlier I pointed out that some of the buildings I see out my window appear older than others, so I can only imagine there have been various city planners and building architects over time. My point is that key people come and go permanently and temporarily (e.g. vacation) and building continues.
But all too often in software organizations, key people cannot leave because they are too attached to let go, too integral, or have not paved the way to let other people in. This, of course, is an anti-pattern. It is best for an organization to develop systems so that new people can operate within the organization.
So whereas a pattern and a pattern language helps in the way your software organization (or your software) is built, a system helps in the way your software organization (or your software) is operated.
But since the term “system” is overloaded in our industry, let me clarify the way I’m using the term. In this case, a system is a set of steps that are followed to get a desired output. Further, the presence of a system allows for consistency and accuracy with new people potentially filling in for others. Some consider a system the same thing as a process, but our industry has begun to frown on that term, so I’m avoiding it here!
Some System Examples
At Stitch Fix we have plenty of examples of systems that we follow that allow us to operate smoothly, consistently, and with new people.
A few examples:
- Technology Radar. As I mentioned previously, we have a process by which technologies come to be “blessed” or as we really call it, adopted. It’s not complicated or even original, but our defined system allows us to have a ready-made way to manage the evolution of our technology stack. And, of course, it requires no key people in particular.
- Engineering Recruiting. We have a system for recruiting which works the same no matter who we plug into the operation. We have documented the roles people play, how they conduct interviews, and how they provide feedback. Our goal is to be able to hire consistently and well no matter who is involved in the interviewing process.
- On-Call Support. Who supports your app(s) when they go down or who oversees any of their other operational facets? This may seem like basic blocking and tackling, but many software organizations haven’t systematized this type of thing. The consequences are fairly obvious, so I won’t patronize you by listing them here.
You likely have similar systems, so these are not ground-breaking examples. The trick is to systematize other pockets of work as appropriate, but without becoming a “process heavy” organization—no one likes to work in that kind of environment.
Going Forward
The point of this article was not to enumerate every pattern or every system or process necessary to turn your software organization into a well-tended software organization, but rather to invite you to think of the building blocks: the patterns and systems.
Here are a few starter questions you might use to begin identifying your gaps:
- Do your apps feel unintuitive or inconsistent or are they built with wide-ranging technologies and coding styles?
- Is someone doing “things” to keep your app(s) running normally? If so, what happens if they go on vacation?
- Is everything version-controlled that should be?
- Do you have documents and/or checklists for important knowledge or tasks?
- Are there key people or “knowledge silos” in your organization which may represent single points of failure?
- Are there key repetitive tasks which have not been documented or automated which only a few people know?
- When thinking back to your latest production events, did you respond systematically or reactively and/or under duress? If the latter, were any patterns or systems identified which would have helped?
- What common problems are being discussed in your chat app (e.g. Slack or HipChat)? If they are recurring and/or undocumented, they are candidates to get under control with a system.
- Similarly, do your teams tend to re-solve the same types of problems? Or, do they solve these same problems in an inconsistent way?
All in all, it’s much easier and more fun to work in an organization that’s built in a patterned and systematic way. This to me is the timeless way of building a software organization.
