The Magic Of Thinking Small: Embracing Limitations As A Strength
I work on a very small team. It's me and three other full-stack developers. And while we are a cohesive unit, the four of us tend to work on completely separate initiatives. In some ways, the size of our team is very limiting. But, this limitation has also proven to be a tremendous benefit as it prevents us from thinking too big. As a natural rule, we are forced to think about and to solve only the problems that are right in front of us. We don't have the capacity or the resources to think too far in advance; or to come up with grandiose visions that require a large number of dedicated man-hours. We have to identify problems, solve them as best we can, and then move on to something else. If we don't, our team productivity grinds to a halt.
I've been thinking a lot about this lately. Not about team size specifically; but, more generally, about how my team embraces its weaknesses as a strength. Because, in the world of web application development, the reality is, everything is nuanced. No decisions are clear-cut. No contexts are objectively superior. Everything is a trade-off. And, in that trade-off - amidst the balance-sheet of calculations - my team is constantly fighting to find an area in which it can chew bubblegum and kick-ass.
That's not to say that all limitations are inherently a strength; but, rather, with limitations that are beyond our control, we are forced to look at each limitation and figure out how it empowers us to make decisions and to move forward. With fewer options on the table, we spend less time worrying about whether or not those options are optimal; and, more time just getting stuff done.
I am proud of my team. We are pragmatists; and, we are passionate; and, we bias towards action. We have a lot going against us. But, we have accepted the things we cannot change; and, it has truly given us the strength to move mountains.
Epilogue on James Shore And Evolutionary Design
A couple of months ago, I listened to an old episode (from 2016) of Ruby Rogues featuring James Shore. In the podcast, James Shore talked about early Extreme Programming and the birth of Agile development; and, he talked about how "evolutionary design" has gotten lost in translation over the years. I was riveted by this entire episode. And, his take on solving only the problems that are right in front of us hit me hard in the feels!
Taken from the show's transcript:
You may have heard the phrase, "You aren't going to need it." (YAGNI) That was one of the big catch phrases of extreme programming in the early days. This is the idea that we're only going to build code for what we need to do today. We're only going to solve the problem we have in front of us, we're not going to anticipate the future.
It's really hard to do because as we look at our architecture, we can say we're going to have a performance problem here, we're going to need to scale here, and we're going to build in hooks to make that possible. YAGNE and Ward's definition of technical debt says to get out faster, deliberately take on that debt and don't build those things.
Evolutionary design is how you get from not having those things to having them without rewriting your entire system. It's a series of refactoring, gradual refactoring to improve the quality of design in your code so that you don't have to build the world, so that you can ship with a third of what you need because you're only delivering a third of your product right now.
It's very tied in with a minimum viable product, lean startup ideas. Evolutionary Design is how you get from your one third product and one third code base or even one quarter code base or one fifth code base. The less code you write, the better. Because the less time you spend, the less bugs there are, and the more you can get out quickly.
Eric Ries who founded Lean Startup was a big extreme programming person. His ideas of continuous deployment and minimum viable product are very much a natural evolution of this evolutionary design and YAGNE ideas. I think it's very important, one of the most powerful ideas on the technical side and extreme programming. But because it's so difficult to see without a big example, it's almost never taught. (James Shore)
Since listening to this episode, I've been trying hard to solve the problems that are right in front of me without worrying too much about the future. It has been an interesting challenge. But, I've been finding it very fruitful.
Epilogue on Ryan Singer And "Appetite" For Work
Last week, on an episode of The Changelog, Ryan Singer was interviewed about his new book, Shape Up: Stop Running in Circles and Ship Work that Matters. In the interview, Ryan talked about this concept of "Appetite". Appetite, as I understood it, is the amount of time that you want to invest in work. So, instead of taking a task and arbitrarily working on it until it is done, the Basecamp team sets an "appetite" for the work; and then, scales the scope of work down to fit that appetite.
Taken from the Shape Up book:
An appetite is completely different from an estimate. Estimates start with a design and end with a number. Appetites start with a number and end with a design. We use the appetite as a creative constraint on the design process.
This principle, called "fixed time, variable scope," is key to successfully defining and shipping projects. Take this book for an example. It's hard to ship a book when you can always add more, explain more, or improve what's already there. When you have a deadline, all of a sudden you have to make decisions. With one week left, I can choose between fixing typos or adding a new section to a chapter. That's the tension between time, quality, and scope. I don't want to release a book with embarrassing typos, so I'll choose to reduce the scope by leaving out the extra section. Without the pressure of the fixed deadline, I wouldn't make the trade-off. If the scope wasn't variable, I'd have to include the extra section. Then there'd be no time to fix the quality issues.
We apply this principle at each stage of the process, from shaping potential projects to building and shipping them. First, the appetite constrains what kind of a solution we design during the shaping process. Later, when we hand the work to a team, the fixed time box pushes them to make decisions about what is core to the project and what is peripheral or unnecessary.
I absolutely love this idea! I want to start applying this mindset to all my work. Instead of just blindly implementing tasks, I want to understand how much time the Product team is willing to put into it. And then, tailor the scope of work to fit that "appetite". I suspect that this will make communication much more transparent and significantly change the way that we manage expectations.
Reader Comments