Everyone likes quick-wins and getting there quickly. The problem with the shortcut I took recently is that it ended up not being one at all. I used a code generator to prove a point. Tempted by the initial success and quick return I then ploughed on and tried to turn this dummy application into something worth keeping forgetting the journey required to fully understand what the generator did and how it hangs together. Now I’ll have to go back 😦
Prototypes are shortcuts – they get us to a point stakeholders can interact with a materialised version of their idea. That is good and we should use that more often but there are issues I have faced with this:
- A lot of people think we’ve arrived at final destination once we’ve completed the short journey to prototype and the big journey with the tasks required to get to this point if we did the full trip are forgotten or assumed done. It’s also very hard to say we now have to go back to the starting point if people expected a shortcut;
- The shortcut turns into an expedition of its own and we spend an endless amount of time trying to find our way back;
- There’s a third reason why I think shortcuts are … sub-optimal – they are reducing our drive towards iterative delivery and we end up with an incremental build.
So how do we take the good things of prototyping and minimise the bad? I would suggest that rather than shortcuts, we should do more small excursions that get us to a point and back to the main path. I think that’s what spikes are for – you go and see this fun thing to the side, if you like it you take a picture and a few notes and hopefully that makes the whole journey even more worthwhile but sometimes there’s nothing really there but that’s fine too, you’ve only wasted a bit of fuel and time.
Safe travels and beware of the dangers of shortcuts 🙂