Continuing our theme of Frog Software Design Principles (First Post):
Usually, when a company wants to add a new application to their system it will tend be a “bolt on”, typically adding a new menu option so their users can get to it. Where possible we look to not build that application at all. Instead we look at what features we would need to add to the core Frog Bricks in order to allow it to be built from these directly.
The risk with this, of course, is that you could end up just adding application specific capabilities into the Frog Bricks – adding capability so targeted towards a specific need that you don’t actually extend the capabilities of the system beyond this immediate requirement.
It’s also tempting to believe that you can invent these features in a generic way – we’re clever enough to do this, right? No, unfortunately not. It would just end up with lots of bolt on pieces of functionality slapped onto an existing component.
So how do we do it?
We’ve been learning how to do this for nearly 10 years now, and we’ve found a way to get pretty close to the target outcome, but it takes a lot of work. The process we use includes the following steps:
- Look at it from the user’s perspective
- Throw more problems into the mix
- Plan a number of journeys
- Bring it back down to earth
I’ll cover these one by one in the following posts.