Continuing our theme of Frog Software Design Principles (First Post):
The truth is that there is a lot of evidence to support these fluffy claims, but the reality is that it wouldn’t affect how we approach our software if there wasn’t. It is critical to have a guiding set of consistent principles when designing software, without them a system becomes nothing more than a collection of disjointed features. Without a clear set of principles, the design quickly becomes about “what’s easiest for the developers” rather than “what’s easiest for the users”. These are the principles we chose when we started out, and they happen to work for our customers as well, which is great. We could have chosen a different set. The key is that we have some and we abide by them.
So that’s all there is to it? Well, yes, but it’s not as easy to do this as you might think.
There’s an open source piece of software in our market, called “Moodle” that manages to elicit the same kind of evangelical devotion from it’s users. That’s why there is a lot of excited noise from the Moodle technical crowd, because they too feel this sense of empowerment and achievement. This level of meaningful flexibility is only available to the technical folk though, and does not extend to the ground floor users, so the system becomes part of the technical team’s domain and it struggles to get buy-in from the people at the coal face. Getting everyone to feel this is not easy.
So how do we build something that doesn’t need constantly re-engineering every time something new comes along? I’ll cover this in a future section of the blog, “Building for an Unknown Future”, but first we need to describe how Frog fits together in order to give it some meaning / context.