In the classic short story by W.W. Jacobs a magical monkey’s paw grants three wishes at great cost. Why does software development sometimes imitate the monkey’s paw experience & what can we do to change it?
The monkey’s paw is a magical item that grants wishes to the letter - but the outcome always brings unintended consequences that are detrimental to the wisher. For example a person wishing they are rich & famous could find themselves becoming a wanted bank robber with their face in hourly news reports.
A common approach to software development is the specced build. The client’s requirements are documented into technical specifications for delivery. These specifications go into great detail about what the software will do & form the basis of a contract with developers.
Time & time again I’ve talked to people who have gone down this route & found that while the software is developed to the letter of the specification/ contract it delivers detrimental unintended consequences.
How does this happen? The first thought is often that the specifications weren’t documented correctly - that if they’d be written with more detail or more depth the end product would have been perfect.
The problem with this line of thinking is that software development is in itself a journey of growth & learning.
development
noun
the process in which someone or something grows or changes and becomes more advanced
During development there will always be issues, hurdles, opportunities, discoveries, changes of direction & new requirements. Without the ability to change to meet challenges a project will hit them head on.
Done properly development should be a journey of discovery towards a solution, not fulfilling an ironclad specification. Developers are great at solving problems, but a locked down specification will naturally become the problem that needs solving. If a developer is focussed on ticking off specifications to the letter they’ll easily lose sight of the bigger picture.
When the primary focus is on locked down specifications a project is doomed from the start.
At UpShift we start with defining the audience, purpose & goal of a project. From there specifications can be documented, but specifications should only act as a roadmap to building a solution.
We try & keep our projects as flexible as possible so challenges & opportunities can be dealt with during the build process. Having the client involved in a collaborative approach is a great way to make sure the end product achieves success.
If you want your project to succeed go for a flexible, collaborative approach. Like storybook wishes a rigid technical specification will never give you what you really want.
Banner Photo by Artem Maltsev