Answers From Experiments
You choose technology, architecture, and design alternatives by using experiments. With an experiment, you can get some degree of objective evidence that a technology will work for you, and see what needs to be tuned and tweaked as necessary.
(Note this is the same idea as in Adopt by Experiments, except applied here to technical uncertainties.)
- No one ever tries to introduce new, better tools or designs
- New tools or design approaches don’t work out
- You’re not sure what advice to take from different sources
- You’ve tried the latest and greatest technology stack, tool, or design approach and it failed to deliver results
There are two main benefits to this concept:
- Lower risk and cost: before investing in a wide-scale rollout or even a full-fledged pilot program, you’re just trying a small, low-risk, low-cost experiment first.
- Better learning: it can be hard to learn the limitations and opportunities of a technology or a technique when it’s embedded in a large project with lots of moving pieces. As an isolated experiment, you can hone in on the aspects that matter to you more quickly, without distraction.
Rather than relying on what might have worked somewhere else, you can inspect and adapt in the proper context: yours
What Does it Look like?
When choosing a new technology or design approach, have at least three alternatives to choose from.
Keep the experiment short: no more than a week or two, or a few weeks at the very most. Bear in mind that development cost is only part of the criteria for a new tool or design. You should also consider:
- Short-term Development cost
- Long-term Maintenance costs
- Ease of replacement (if it’s not easy to rip out and replace, don’t chose it)
- Overall impact of this decision (is it reversible if you choose poorly or conditions change?)
- Experiments last six months. They should be no more than a few weeks at the very most
- Experiments becomes a rubber-stamp approval
- You experiment with less than three alternatives when there’s a question
- An experiment impacts production code
- The decision at the conclusion of the experiment is irreversible.
How To Fail Spectacularly
While evaluating different approaches to technology, including the age-old tension between developing software from scratch versus adopting software that’s already built by someone else. The key question to ask is why you might be developing this piece yourself.
Deciding to re-implement your own custom version of a commonly available, off-the-shelf technology is almost always a very, very bad idea.
Unless this is your core product itself, you have no business trying to develop your own:
- Object-relational mapping layer
- Database connection pool
- Version control
- Widget set
This is all well-trodden commodity territory, and it’s unlikely you’ll produce anything of value beyond what currently exists off-the-shelf.
Save your development resources for areas that can really make a difference.
←Prev (Adopt By Experiments)(Remove Proxies to People) Next→