Presentation: Evolutionary Architecture as Product @ CircleCI

I'm the CTO of the company. I spend a very large amount of my time on longer term strategy and direction: understanding where the business is going, where the market is going, and then translating that into both technical and product direction because our product is for software developers. I believe I play a larger role in product strategy than probably many CTOs do. I don't know for sure because I haven't been the CTO of that many different companies, but acting as both an outward advocate of the product, and internally understanding long term software trends and understanding where we have opportunities in the market and helping to drive product strategy off of that, as well as turning it into a technical direction.

The goal of the talk is to impress upon people the relationship between their industry and the product they're offering, and the way in which they choose to build their software. As we grow as engineers and leaders, there becomes a stronger connection between the work that we do every day from a technical perspective and the product and the business, both in terms of what's happening currently, but also architecting intelligently for the long term direction of your industry. So helping people realize that connection and see ways in which they can think about building software to support that.

I think that's a really great question, because usually you don't when you start out, you are just trying to figure out what your business is. I think this is one of the transitions that a lot of young companies go through as they grow. You're trying to do the smallest possible thing to figure out what your business is. And that's ideal. I mean, we all love talking about MVPs and the simplest possible proof point. It's usually on the second or third round that you're actually thinking about building a system that is going to be effective and grow. And one of the big transitions that we've gone through as we did one of our major re-architectures was trying to go from solving a current problem to solving a new problem, but positioning ourselves to solve more future problems as they arose. A big part of that is understanding or having a perspective anyway, because it's hard to predict exactly where software development is going to go. We are an industry of rapid innovation for sure. But understanding your industry and longer term trends in your industry and how those may impact your system.

One of the things that I like to think about a lot–I don't know that I'm perfect at implementing it, I doubt anyone is–is rate of change. Understanding where you expect there to be significant amounts of change and investing more in an abstracting effectively in those areas. Building the perfect adaptable architecture in every area is a very high cost endeavor that doesn't tend to lead to completion. Honestly, it just ends up in a lot of architecture and not a lot of construction.

I love this notion of rate of change. I think there are better terms for it. But, understanding where you expect there to be a significant amount of change inside the product and building for change there. The spectrum is to hard code at one end, which sounds terrible, but it's certainly the fastest way to get something done. At the other end is configuration-driven, like pricing. We've gone through this effort recently of changing our pricing plans and building for a more flexible one. There are a lot of parameters that we want to be able to change. How long is it before someone shows up and needs a discount or a different tax code, those sorts of things. Some of those are predictable and some aren't. And it's the ones that aren't that I think are most interesting. Either designing to be changeable or designing so that the implementation is simple and light enough that when you have to come back and change it, then then you know how.

There are some classic principles that we all talk about, like YAGNI, rule of three (don't build that abstraction until you've been faced with it a couple of times), those sorts of things. Some of the questions that have been interesting for us are the very fundamental core pieces of our platform that we thought were constants and then changed very significantly over time.

First, when I think about talks or when I read books or listen to a podcast, it's usually not that there is a very clear solution to one of my problems, but rather some inspiration for a new way to think about one of my problems. You're probably not a CI/CD provider. You probably don't have some of the very specific problems that we have. Or the solutions that we've taken to deal with those might not be yours. So I just want to inspire people to think about their industry, about longer term trends in their industry and places that they can either build something more adaptable or not build something more adaptable, because for all of us, we're balancing cost and risk, or the return on investment in what we do. I want people to expand their thinking about how they apply thinking of cost-risk, return on investment, into their architectural decisions and how they can make better decisions around that by better understanding trends in their own industries.

The second part is the entertainment value of some of the horrible things that we've done and maybe some inspiring ideas out of that.