A place where we write words Ignition Blog

Welcome to the Ignition Development blog, where we talk about a wide range of technical and non-technical topics.

February 2010 Entries

Disk Management 1.1 for Windows Home Server

This morning saw Tentacle Software release version 1.1 of it’s incredibly popular Windows Home Server Add-in:

Tentacle Software is proud to announce the release of Disk Management 1.1, the next version of our very popular Windows Home Server Add-In. It has, as they say, been a long time coming.

This release also sees a large update to their website – the new site is looking very shiny indeed. If you’re a current user of their Disk Management Add-in, or a WHS user who hasn’t seen it yet, then you should definitely head over and check it out.

This blog entry was posted @ Monday, February 22, 2010 9:01 AM | Feedback (0)

Why we wrote the Site Foundation Framework

A couple of months ago on my personal site I briefly wrote about a post I read called Engineering your way to marketing success. I found the post interesting for a few reasons personally, but it was interesting from Ignition’s perspective because it mentions about writing your own CMS software which is what we did with our Site Foundation Framework.

There’s a lot of interesting bits in that post (which is well worth reading in its entirety) but here’s the quote I’m talking about:

Write your own CMS.  I would have totally disagreed with this advice up until last week or so, but Thomas convinced me: writing a single-purpose CMS is pretty much the new Hello World for modern web frameworks (heck, it is the official Rails demo), and with a man-week or two you can make something much more productive for your purposes than using, e.g., Wordpress.  (Though if you can do whatever functionality you need as a Wordpress plugin, I’d still be inclined to suggest that.  No need to reinvent the wheel for basic CRUD operations on textual content, or HTML parsing.)

Early on when we started on the Site Foundation Framework I had to stop and have the important discussion: Are we reinventing the wheel here? There’s plenty of choices when it comes to CMS software, what are we bringing to the table by writing our own offering?

Obviously we managed to justify carrying on with the project, and we’re glad we did - so what were our reasons?

1. We wanted a framework, not a product. When you have to create something which can be 100% configured and setup by a non developer then there’s a huge amount of time spent making everything configurable outside of code. We wanted something for our own internal use – to help US build sites and applications quicker for our customers. If we wanted to sell it, and make it downloadable by other people then we’d need to spend a whole lot more time on certain aspects of it, but we don’t, which meant that the amount of time we spent on it was reduced a great deal (on a side note, that’s still something which is a possibility for the future).

2. We wanted something we could easily build on and a codebase we know well. Again, as what we were writing was a framework more than a package we were free to make a few decisions which make it easier for us to use this code to build non-CMS sites with. We can easily add custom code on top of SFF, and because we wrote the whole thing we know up front about any constraints that we were likely to run into – and (this is the more important part) change or remove those constraints if we needed to.

3. Other online shop functions seemed laden with features we didn’t need or want. Throughout the development of SFF we followed the YAGNI principle, and when we looked at the range of shop modules that were available with other CMS products they either seemed to come with too many things we didn’t need, or missing features we wanted. Either way we were going to have to write some code to achieve what we wanted, and so why not write the whole thing and get exactly what we want without anything we don’t?

4. It’s an excuse to use the latest technologies. If we were using something which wasn’t fully in our control then obviously we’d be less in control of the adoption rate when it comes to new tech and shiny bits. This way, we have full control. Of course we don’t have to upgrade all our customer sites at once, so there’s no risk for the customer, but it puts us in control of the technologies we use and the ones we don’t. We like that.

5. Dogfooding helps drive development. Running your own sites and applications on the same software that our customers use helps keep us in touch. It also helps us think of features and remove pain points which improves the experience of our customers. If we were using some other framework or software then we’d still be able to experience the bits that need improving, but without the ability to do much about it.

While we had to spend a little more time up front to build the basic foundations (no pun intended) we’re now seeing a return on that investment and savings for our customers every time we build another a site or application. There’s no doubt we could have taken an off the shelf product and made it work for us, but building our own has given us a great deal of flexibility and control which we feel is well worth the initial investment up front.



This blog entry was posted @ Friday, February 19, 2010 3:00 PM | Feedback (0)