Let’s Iterate Fast
We’re 3 weeks in to a new project at work, or in sprint time, we’re half-way through our second sprint. We’ve had a rough go, to get started. Probably not anything worse than most projects. But since this is the first time on a project in this role, I really wanted to get out of the gate strong and impress our clients (and our boss.) Even though I knew there would be some initial churn as we get servers set up, and the project established, I still didn’t want to deal with it.
It’s been a learning experience, to be sure. One thing I’ve already noticed in the 3 weeks on the project, is that I’m saying a couple phrases a lot. The first one is “Done is better than perfect.” And the corollary to that is “Let’s iterate fast.” What I don’t mean by the second one is “Hurry up! Just push it out there.” Instead, what I mean is “We know we’re going to iterate on this. That’s ok. We know we’re not going to nail the design the first time. That’s ok as well. We know there are going to be parts of our code we don’t like. That’s ok. Let’s just plan on that, get our code in and when we realize our mistakes, iterate on it.”
Too many times in my career, I’ve tried to get the perfect design, or really, just the right design. I’m too much of a realist to know that we’ll never have a perfect design. What happens, though, is that I spend a lot of time trying to nail down a design that I like, and by the time the project is over, I realize that it’s not very good, or at least I know the pitfalls of that design.
I don’t want to do that anymore. One way we’re trying to help us iterate fast is small stories. So, for example, we had a story that there roles should exist in the API. That’s it, they don’t have to do anything, just exist. Then we had another role that said we should be able to assign features to those roles. Again, assigning features doesn’t have to do anything other than say “Role Admin has the ability to create users.” We don’t need to wire up the ability to create it, just know that it has that ability. We don’t have to know all the roles, or even any of the roles, up front, we just have to know that there are roles and there are features and they need to be assigned to each other.
Another way that we’re trying to iterate fast is by having tests. I have found over and over again, if I have tests covering my code to the point I’m comfortable know that if I make a breaking change they’ll tell me, then I won’t be afraid to refactor. How does this help? Imagine we have one big data context, it knows about every table in the database. As the project grows, we realize this is too cumbersome. If we don’t have tests we’ll likely say “What are you going to do about it?” But if we have tests, we can start refactoring and breaking out smaller contexts, re-run the tests and make sure everything passes.
But how does that help us iterate faster? It helps because I no longer have to worry that some day we’ll figure out a better way to do this. In fact, I’m almost positive we will find a better way. So rather than worrying about doing things the absolutely best way right now for all eternity, I just have to worry about doing things the best way for the problem at hand. As soon as I realize the data context is too big, it’s time to refactor.
I believe the ability to iterate fast is what’s going to help us not wind up in the “that code is horrible” trap.