1. Frog Software Design Principles

Early in Frog’s history the software was designed pretty much entirely by one person, with odd exceptions. In principle, this is an ideal situation because it creates consistency in approach and ensures that the overall direction fits in with a single coherent vision.

As the company has grown, however, we now have a wide range of differently skilled people working directly with clients and feeding back customer requests and ideas for additions to the software.

Of late there are an increasing number of people developing a view on exactly how these new features should be integrated into the software. The fact that this is happening is, I think, a testament to the simplicity of the Frog software. The reality, of course, is that the Frog software is so simple on the outside because we’ve gone to so much effort to make it so by doing lots of work on the inside. Going forward, allowing it to be designed by what could be described as a “committee of enthusiastic amateurs”, while great fun for those involved, would be fatal for the future of the software.

Very few people in Frog are aware of the design principles that we use in the development team. It also occurred to me that some of our customers might be interested in our processes, so I’ve decided to serialise it on this blog. These are very specific to the componentised nature of the Frog software, and may not translate into other systems, but the principles we use may be of interest.

I’ve added a category called, “Frog Software Design” to the blog, and I guess you’ll need to start reading from the bottom, or click the links at the bottom of each post to navigate to the next post.

2. Fluffy Stuff >