The debate between development speed vs. product quality comes up often, and I want to share my approach to tackling hard problems. I don't believe that speed and quality are mutually exclusive, and while there may not be an optimal approach, I have found a sweet spot for my own personal workflow that keeps me moving at a consistent pace.
An Expression First Mindset
I approach problems with an Expression First mentality. I learn through expression, so I try to write code as soon as the project requirements begin to settle into something tangible. At this stage, major important pieces of the logic have not yet been fully defined, but I have enough information to at least stub out a sample of what we expect the application to do. As I express the requirements, I gain understanding of the business domain, and the resulting prototype serves as a flexible blueprint for the application.
With a functional, stubbed out prototype in hand, I now have a good idea of the big picture we are trying to achieve, and also a huge list of questions I can bring to stakeholders as the project evolves. This big-picture understanding also empowers me to give valuable feedback in the early stages of the project to steer us away from technical cliffs that we may encounter farther along in the project.
Pairing With Others
Whenever possible I embark on this exploration phase alongside other developers on my team. Despite the pandemic we regularly pair program remotely and work through the harder challenges of the project together. When one person hits a roadblock, there are others there to pick up and move us past it. We take turns leading the charge, and as a group it is easier to stay on task and focused. We talk through architectural decisions as we go, and can quickly change directions when we realize we've made a mistake.
I absolutely love the shared understanding that comes from pairing with another developer. When we find a challenging technical requirement, we both understand the problem and can work through it together. A shared understanding makes it far easier to write air-tight test cases around the major components of our system. With shared understanding, we can clearly communicate timelines and expectations to stakeholders, and when requirements inevitably shift we are already on the same page and can work on the requested change immediately.
Move Fast Without Breaking Things
I often achieve both speed and quality in the code I write by exploring and expressing requirements early, by pairing with others and by constantly asking questions and sharing progress with stakeholders. Maintaining high visibility into the progress of the project helps prevent catastrophic misunderstandings and makes it far easier to deliver a final product that is satisfying for the end user.
I'm curious, what is your approach to working through hard problems? How do you keep a project moving forward?
For more articles and discussions check out my locals community: Reflective Engineer
Here's the article that got me thinking about this topic: I'm slow and that's okay
Top comments (0)