As developers, it can sometimes be tempting to focus purely on the technical, engineering challenge of the task at hand. When we succumb to this, we often end up spending time on technically challenging or interesting aspects of a problem or software application, which aren’t necessarily of greatest value to the end user or customer. Sometimes, we end up over-engineering, or worse, building completely the wrong thing because we’ve lost sight of how our code is supposed to improve the life of the end user.
The best way to avoid this kind of tunnel vision is to actually sit with users of your software. See what they do with it today (or, if they aren’t yet using your software, see how they’re accomplishing their work without it). Get ideas from them on how they would like things to work, and bounce your own ideas off of them about how you might solve their problems. Then, if your organization allows for it, get your ideas into real users’ hands as quickly as possible, even in an imperfect state, in order to get their feedback. The sooner you learn that you’re heading off course, the smaller the effort required to steer the application back in the right direction. Coding without end user feedback is like driving while blindfolded – neither is likely to end well.
Developing software should involve continual learning about the problem domain. Our initial assumptions, designs, and models will be flawed, and as we learn more, we’ll improve them. More important than a completely fleshed out Big Design Up Front is an overall vision of what needs built, and close interaction with the people whose problems will be solved by our software. We will almost certainly spend some time going in directions that will ultimately not lead to success. That’s part of the process – the key to success is to fail fast. Learn as quickly as possible which paths are the wrong ones, so that progress can continue down the right path.
“As developers there are two ways we fail: we build the thing wrong, or we build the wrong thing.” – Steve Smith