Software makers, like surfers, need to be ready for unexpected problems. We need to “surf with our knees bent,” using a stance that takes the unexpected into account. Here are four ways you should adjust your stance to avoid being thrown into the water… metaphorically.
This excellent metaphor comes from Jim Price’s talk about good and bad lessons learned from Silicon Valley at the recent Positive Business Conference.
1. Estimates are good guides, but not the absolute truth.
Understanding what a project will cost is an important factor when embarking on custom software development. We use several estimation approaches to focus on a responsible range where a product development team can find success.
I think we do a pretty good job of this when riding the big waves involved in estimation:
- We’re estimating at the point of greatest ignorance. Some complexity will remain unknown until project execution is underway.
- What we are estimating will change. You should collect feedback and make adjustments to what we’re building throughout the project.
- Technical risk can be hard to quantify, especially with third-party integrations. This is doubly true if those integrations are built on legacy technologies or lack good documentation.
To ride these waves, it’s best not to take a rigid approach. Instead, we “keep our knees bent” by building flexibility into contracts, continuously releasing software, and closely tracking progress throughout a project.
2. The design should change.
Mike Tyson once said, “Everyone has a plan until they get punched in the face.” Thankfully, we generally don’t have to get punched in the face during software design and development, but we do need to accept the likelihood that our plans will be upset.
Going into a software project, you probably have a good idea of a market need that the software will fulfill. The need might come from an external or internal source. We also have an idea of what the software should do, including key features that users want and a picture in our mind’s eye about how it should work.
Expect those assumptions to be challenged. You may find that once real-world users get their hands on the software, they use it completely differently than you expected. And when you’re developing with “bent knees,” it’s easier to adapt to obstacles you didn’t see or winds of change you didn’t expect.
One way we do this at Atomic is to get the software into the hands of end users as soon as possible, often through usability testing. You can do this very early in the process, creating inexpensive clickable prototypes from low-fidelity designs. By observing how users interact with these prototypes, experienced designers can note how the system is used and synthesize findings to tweak the design. Before writing a line of code, you can iterate on the design.
3. Some things will be harder than you think.
Embarking on custom software development means creating something new. For a software system to be valuable, there must be some risk involved. Otherwise, it is already a solved problem, and the customer may as well purchase off-the-shelf tools.
In technical terms, these risks can manifest as bugs or slow progress. These may temporarily slow you down, but as long you’re surfing with bent knees, they’re no reason to get out of the water.
Humans write bugs, but we can also use testing and good software design to overcome obstacles. You can be ready for these “bumps” by asking the following questions:
- Are you writing automated unit tests?
- Do we have end-to-end testing in place that exercises the whole system under real-world conditions?
- Have we load-tested the software?
- How long does it take for a new developer to set up a development environment?
- How confident are you in your story estimates?
The answers to these questions can show you whether the software is being built on solid ground or a quality problem may be lurking. When the unexpected happens (e.g., feature changes, a new integration, a significant change in the user base), knowing that you have a high-quality software system makes it easier to change or map out a clean plan that adapts to the new requirements.
4. Release early; release often.
Finally, the best way to ride out changes and obstacles is to uncover them early. And the best way to do that is to release real, working software to end users and collect feedback. This way, if there are waves on the horizon, you can identify them as soon as possible and adapt your stance to overcome them quickly and efficiently.