Skip to main content


Moving away from CMS as a platform

Cross-posting an article written for the agency I work for, Zone, on moving away from "CMS as a platform", a concept I first came across in the Thoughtworks tech radar, warning against building too much directly into the CMS/web application, and considering external services, data sources and asynchronous processes.
Recent posts

Thoughts on "A Philosophy of Software Design"

I took a recommendation from the blog of Gergely Orosz on a recently released book on software architecture, "A Philosophy of Software Design" by John Ousterhout, purchased and have just finished reading it. In short, I'd second the recommendation - it's not a long book, but is packed with good, practical advice presented from the perspective of an academic, mostly based on his views of many implementations of projects by his students. What I particularly enjoyed about it was that it's a book that makes you think as you go... you aren't simply ticking off a list of things you agree with already. Gergely had a few reservations that he outlined in his post, most of which I also agree with, and I also had some of my own - but all in a postitive way as it made me think and question some practices I've used up to now and consider them from a different viewpoint.In the appendix, John lists 15 design principles that he describes fully in the book, which I'…

Practical Decisions on Testing: Using TDD

I think this will be the final post in this unplanned series on "Practical Decisions on Testing". Previously posts have covered:Considering a UnitCode coverage metricsTrading off value with difficultyIn this post I wanted to consider the topic of test driven development (TDD). It's a technique that tends to divide developers into two camps, those that swear by it, and those that don't touch it (even if they are on board with unit testing itself). Over the course of my career I've used it on occasion, and found some value, but on balance find I fall mostly into the "tests after" camp, and the method of using tests to drive the design of the code isn't something that's really become part of my programming workflow.In particular, going the full TDD approach where you write code that doesn't initially even compile isn't something I've found grabs me, perhaps due to my background in statically typed languages, primarily C#.A peer of mi…

Practical Decisions on Testing: Considering a Unit

Without intending to when I started, I've three posts on a topic now, which I think constitutes a series on "Practical Decisions on Testing". Previously posts have covered:Trading off value with difficultyCode coverage metricsAs with the above two posts, the intention I've primarily got is to put down in words some discussions I've had at various times, for a reference and as something to point to.In this post I want to discuss what we consider as "the unit" when it comes to unit testing. For many developers, it's the class, and the mark of good coverage is to ensure that all public methods - and via them, the private ones - are covered by tests. In doing so, there will certainly be a well tested code base.There can be a downside discovered in this though, in that it serves as a deterrent for refactoring at the inter-class level. For example, a decision to split the responsibilities of a class into two to better meet the single responsibility pr…