Continuing our theme of Frog Software Design Principles (First Post):
Because we’re not building a specific, hard coded application, we next look at how to modify our existing components to provide the kind of capabilities we might need to build this application using the toolkit. We are looking here for a variety of different approaches, creating as many options as possible – and resisting the temptation to just “solve” the problem.Now we have a few possible routes, we look for other customer requests, or ideas on how we might use this additional functionality, “What else could we do if we extended the Frog Bricks in this way? What about if we did it this way?” This more often than not leads to a Eureka moment, something along the lines of “Oh hold on, if we did it that way and then did this and this instead, we’d be able to use this to solve that request we got last week as well, but look what else we could do with it, ……..”
This sounds easy, but it isn’t. There are too key areas of difficulty with this approach:
- preventing everyone from trying to “solve” the problem as quickly as possible (I know I’ve said this 3 times now, but there’s a reason for that ;) )
- getting everyone to invest meaningful thought in the other cases that could be added to the equation (it’s very easy to say, “I can’t think of any, let’s just do this, there’s too much on at the moment”)
To get around this we try to start thinking about the design of systems a long time in advance of building them. I’m a great believer that the best ideas come in the shower, metaphorically speaking – when we’re relaxed, or when other events in our life trigger associations and ideas. Let things grow and develop naturally. Hunched over a computer banging a specification together with a deadline to meet, or running a committee meeting full of people looking for quick fixes, is not, in my experience, conducive to building strong software (but this is how it’s usually done).