Author Archives: Andy Theyers

Selecting off-the-shelf software (or, how to avoid buying a lemon)

Here at Isotoma we often get asked what the differences are between off-the-shelf and bespoke software, and how to decide which is the right approach for a given situation.

Generally software that has been written specifically for you (by companies like us) is referred to as “custom” or “bespoke”, while software that is customised, configured and deployed to many customers is referred to as “boxed”, “off-the-shelf” or “COTS” (Commercial Off-The-Shelf).

Isotoma is a bespoke software development company. This means that we take generic frameworks and build applications tailored to our customers’ needs on top of those frameworks, rather than having a single product of our own that meets a particular need that we resell to our customers (for example a content management system or an ecommerce system).

We’re very upfront in our answer to the “bespoke or off-the-shelf” question; if there’s off-the-shelf software that meets your needs we strongly recommend you go that route. While bespoke software brings huge benefits in the right situation it also has limitations, complexities and costs. You need to be sure that it’s right for you before going down the bespoke road.

Equally you need to be sure that you’re assessing the right things (not just features!) when considering off-the-shelf software for your project. All software investments bring risks to an organisation, and the risks of off-the-shelf can often be subtler and harder to spot, yet equally as impactful, as those of bespoke software.

At its best buying off-the-shelf software can be an extremely cost effective way of getting the features you needs and of future-proofing your software investment. But at its worst it can be a way of tying yourself in to a closed environment that is expensive to customise and hard to migrate away from.

Any off-the-shelf product works best when the requirements it serves are shared by lots of organisations. There the economy of scale means that every customer gets a great product without having to pay for the development of all the features. We wouldn’t ever suggest, for example, building a blogging platform from scratch, nor a word processor or an accounting package. These are all problems shared by countless individuals and organisations around the globe where product companies are easily able to serve everyone’s needs.

However, whenever an organisation’s requirements for the product diverge substantially from the needs of the primary customers problems very rapidly occur, meaning either increased cost, compromised experience or, more often than not, both.

When selecting a product consider how much customisation you will need to make the product really sing for your organisation. And consider how you would be affected if you simply couldn’t have half of those customisations you’re imagining (regardless of whether this was through technical limitations or lack of budget for the necessary changes).

Next it’s important to think about the existing customer base of the product. If the product has thousands of customers, many like you, all successfully using it then you can probably feel comfortable that a) the product really is likely to meet your needs and b) the team behind it are likely to be around and supporting the product for the lifetime of your use of it.

Taking on very niche off-the-shelf products or off-the-shelf products from small suppliers can be extremely risky. The worst case is that under the hood each installation is in fact an alteration of the underlying base product, the “licence fee” being used to cover the cost of the developers implementing the features that the salesman told you already existed. Here you risk expensive maintenance costs, delays in implementation and a high rate of bugs, as you were sold something off-the-shelf (and had assumed the time scales that go with that) yet in fact custom software is being developed on your behalf at cut rates and at double quick time.

You should definitely carefully assess products with very small numbers of installed customers. Unless you are extremely confident that it meets your needs entirely unchanged or you are happy to invest in the development of the product in the long term they should probably be avoided. These are often only products in the sense of “hey, we’ve made this thing for so and so, I bet others like them will need it too.”

Potentially as troublesome is the risk of delays or exorbitant fees if the resources of the team behind the product become stretched. If you need to call upon consultancy or professional services will the team be able to support you in a timely and cost effective manner?

Finally it’s worth considering the impact on your business processes. In general products work well for organisations that are just setting out, as any limitations imposed by a boxed product do not conflict directly with the way the organisation wants to do business. In addition, very young organisations do not entirely understand their requirements and so having a set of predefined features given to them allows them to develop their own business processes alongside those features.

Older organisations tend to struggle with products, particularly at the cheaper (and less customisable) end of the spectrum. They have a clear understanding of their requirements and are looking to create efficiency within their organisation. It is no longer acceptable to have predefined solutions forced upon the business, as it is exactly those predefined solutions that are causing the inefficiencies that the company is trying to drive out. In this case bespoke software has huge advantages, being tailored exactly to the organisation’s understanding of its own needs.

So you must consider the scope and scale of changes to your business processes that the new software will bring. How substantial are they? Are you ready for them? Will your users support you in making them? And can you drive them through at the same time as running a new software project?

With all the above in mind, how do you make sure that an off-the-shelf product will meet your needs and that you’re not investing in a lemon?

Here are some questions worth asking during the selection process. There are no right answers, but by having the conversation with potential vendors at this stage you may flush out some problems that you would otherwise have uncovered much later in the project:

  • How many paying customers do you already have for the version you are selling to me?
  • How many paying customers of our installation size and type do you have?
  • Can I talk to at least 2 of your customers about their experiences of the product and your services?
  • What is the average customisation cost of an implementation?
  • How much do you charge per day/per hour for professional services?
  • What is the average turnaround time for professional services requests?
  • Is there a VAR (Value Added Reseller) or partner network around the product that I can tap into if I need extra help with customisation/integration?
  • Is there an API that I can build on and use to integrate with our other systems? (if yes, can we see the documentation before we sign up?)
  • How easy is it for me to export my data from your product in a way that’s possible to import into an alternative?
  • Can I host the product myself? If so, what are the minimum hardware specifications for an installation of our size and type, and who is responsible for performance issues should they occur?
  • Do you offer a support agreement of any sort? What SLA options do you offer and how much might a support agreement cost?
  • When was the last major version released, and how many customers upgraded (and how many do you still have running the old version)?
  • What was the average upgrade cost when customers moved to this major version?
  • When do you plan to release the next major version?
  • Is there a user group for the product that I can talk to or join?
  • How are new features for future versions decided?
  • Do features I request and pay for get rolled out to other customers in future versions?
  • And perhaps most importantly: what is the roadmap for the product over the next 18 to 24 months?

Of course, there are equally detailed lists of questions you should be asking when selecting a bespoke development partner or when selecting an open source project, but both of those are for another day. Hopefully this list at least helps a little with the decision making process.

About usIsotoma is a bespoke software development company based in York and London specialising in web apps, mobile apps and product design. If you’d like to know more you can review our work or get in touch.

Seeking a Head of QA

Isotoma is looking for someone with solid testing and management experience to come and help us shape and build our QA function. The role will be to take on the formalisation of our quality control systems, from traditional manual testing to automated CI, build and deployment. We’re looking for someone who can run the testing function whilst also getting involved with all 3 teams within the company (dev, devops and ops), helping them improve their processes and approaches upstream.
Read more about it on the main site (Head of Quality Assurance vacancy) and please get in touch.

Squid and Facebook

Lenny (Debian 5.0) and Lucid (Ubuntu 10.04 LTS) both ship with Squid 2.7 as their default Squid version.  If you plan on deploying squid as a web proxy in a modern mixed browser environment you should seriously consider Squid 3.0.  If you can’t (or, like me, you’d already spent some time getting Squid 2.7 set up just right) you are likely to find users reporting that Facebook is returning blank pages or that links within Facebook don’t work.  Looking at Facebook in a browser with debugging tools installed you’ll see lots of cross domain Javascript errors.

At this point you should either upgrade to Squid 3 (which doesn’t exhibit this behaviour) or make the following change to your squid.conf:

  • Add server_http11 on

Facebook uses different methods of shipping the Javascript depending on whether the client has made an HTTP/1.0 or an HTTP/1.1 request.  By default Squid 2.7 alters the request to be HTTP/1.0, so Facebook sends it’s fallback methods to the modern browser, which then proceeds to break.  The change above stops Squid rewriting that part of the request, ensuring that Facebook ships the right content to your users.

On Ubuntu Python, Exceptions and unnecessary imports

A few days ago Alexander Limi (one of Plone’s founders) tweeted the following:

Ubuntu Python: Raise an exception, import 190 modules: – this is why you don’t want to use the system Python.

Now this gets my goat on a few points. First up, why the hell would I not want to use the system python? If I’m using any sane distribution I’ll have package management and security updates, and any flaw in Python will be patched, packaged and tested by people that are far smarter than me. Upgrading the Python that ships with the Plone Unified Installer just isn’t going to be as easy, however you play it. And that’s without the risk of the Plone community moving on to more exciting things, leaving their version of Python unsupported.

Secondly, there’s a fatal flaw in the original blog post to which limi refers. Yes, on the desktop, Ubuntu imports 190 packages when an exception is raised. As the author explains this is to enable Apport to provide as much information to the Ubuntu devs about application failures. What the author does not mention is that this doesn’t happen on the Server edition of Ubuntu. Why would it? Apport is designed to handle desktop application failures and to improve the end user experience. It isn’t installed by default on the server edition, because it isn’t needed.

On my Karmic desktop:

Python 2.6.4 (r264:75706, Dec  7 2009, 18:43:55) 
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> len(sys.modules)
>>> raise KeyError
Traceback (most recent call last):
  File "", line 1, in 
>>> len(sys.modules)

On my Karmic server:

Python 2.6.4 (r264:75706, Dec  7 2009, 18:43:55) 
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> len(sys.modules)
>>> raise KeyError
Traceback (most recent call last):
  File "", line 1, in 
>>> len(sys.modules)

Being quick to condemn Ubuntu, and their packaging of Python, doesn’t do anyone any good. Think before you tweet. And don’t go live on a desktop distro.

Location of Zope/ZEO transient caches

When Zope connects to ZEO it is configured with a database cache, where objects are cached by Zope so that it doesn’t have to constantly return to ZEO. These caches can be transient (they don’t persist past a Zope restart) or persistent (where they do).

If all you do is uncomment the example ZEO client configuration in your zope.conf you’ll have a 20MB transient cache. If you follow one of the many buildout recipes on the web you’ll likely have a transient cache of anywhere from 30MB (plone.recipe.zope2instance) up to 300MB (from this howto on

Zope uses the Python tempfile module to decide where to put these transient caches, which on Debian defaults to /tmp. Our default production server installation has /tmp as a subdirectory of /, with the root partition being only 1GB. This means we have a maximum of about 400MB for temporary files on our servers.

With the default 20MB or 30MB this is fine, even in multiple Zope/ZEO installations on the same box. However, when we recently tried to up the size of the caches on a system that needed it we quickly found ourselves running out of diskspace in the root partition, which in turn caused some very strange behaviour, ultimately resulting in the site being unavailable.

The trick is to move these transient files to a more sensible location (like /var/tmp). You can do this (with thanks to mauro on zodb-dev) by setting an environment variable in your zope.conf, either manually:

  TMPDIR /var/tmp

Or in your buildout:

recipe = plone.recipe.zope2install
environment-vars =
     TMPDIR /var/tmp

Compiling Python2.3 on Karmic

We still have some (now very old) Plone 2.1 sites running.  Up until Ubuntu 8.10 python2.3 was still available from package management (albeit with limited support), but as of Ubuntu 9.04 python2.3 was removed entirely.

To recreate a development environment for these older sites means downloading Python 2.3 and compiling it by hand.  Unfortunately it’s not a default build any more – as it says on the download page:

Since the release candidate, we received various reports that the this release may fail to build on current operating systems, in particular on OS X. We have made no attempt to fix these problems, as the release is targeted for systems that were current at the time Python 2.3 was originally released. For more recent systems, you might have to come up with work-arounds.

For Ubuntu 9.10 (Karmic Koala) to compile python2.3 you’ll need to disable buffer overflow checking by doing the following:

tar zxvf Python-2.3.7.tgz
cd Python-2.3.7
./configure --prefix=/usr/local BASECFLAGS=-U_FORTIFY_SOURCE
sudo make install

update: this post has been translated into Belorussian if you prefer that.

On what to do with downtime

There’s a fascinating post over at TCUK today about agencies building their own applications. We even get a mention in the intro with reference to Forkd. The comments get pretty heated too, with some people claiming agencies that have the time to do such things are over staffed while others are worrying about how to fit internal developments alongside client work.

So, given we’re mentioned, how do we feel about it?

It’s always going to be hard getting the balance of client work and your own projects right. We started work on Forkd in summer 2005 and launched it in early 2008. In that time the world and his wife had built a food social networking site and we were on the back foot right from launch. Keeping a focus on internal development ideas while working with clients work is always going to be a killer.

That said we have more in the pipeline and aren’t going to stop…

The reasons (at least for us) are threefold. First up, what better shop front is there than something that you made for yourselves? A real case of putting your money where your mouth is; new customers can see exactly what you could be making for them.

Secondly, scaling a technical agency is hard. You only have the person hour to sell, and growth only comes through selling more person hours. That is, unless you can “productise” some of your own work. And what better than productising something that you and your team enjoy making and using?

Third – it’s always best to learn new technology on something that isn’t so important that your business depends on it. That latest cut of your favourite app server from svn might look like it provides the killer feature (or bug fix) you need, but do you really want to try it on your current big client project?

And to those that claim agencies must be over staffed if they can do work like this… We all know that the entire team will have downtime whether it’s explicit or not (and all of you with “100%” utilisation just have a miserable staff hiding their downtime at the water cooler or on facebook). A shared goal to aim at during that downtime makes the downtime explicit and supported, which makes a whole let of sense to me, anyway.

And hey, who wouldn’t like to be the next Skinny Corp?

kupu 1.3.9 and Firefox 3

Just a quick note to say that we’ve just discovered that kupu 1.3.9 (the one that ships with Plone 2.5 by default) breaks rather nastily in Firefox 3. First looks show that kupu 1.4.10 (the latest from is just a drop in replacement, so it shouldn’t be too bad to get sorted. If you too are suffering weird behaviour when using the kupu internal link tool or image browser it may well just be that.

We’re hiring

We’re looking for developers ASAP, due to a quick burst of new work. If you (or anyone you know) is looking for their second or third programming job and has good Python skills (preferably with some experience of one or more of Turbogears, Django, Twisted, Zope or Plone) and aren’t scared of HTML, CSS and Javascript please get your CV to ASAP. We’ll put a formal job spec up on the main site shortly but the sooner we hear from you the better.

Facebook advertising

We’ve been running a Facebook “social ad” for Forkd for the last few days. I’ve been interested in what Facebook advertising could do for our customers for a while, and thought that the best way to find out was to try it for ourselves. Some interesting things have arisen from it, too:

  • It’s a very simple ad format – hard to really make compelling. Despite that, and having made little effort in the ad design, we’re getting 1 in 2,000 click throughs, which feels to me like a good number.
  • We’re getting roughly 1 new account sign up for every 8 clicks. Again, this feels like a good number. Both of these make me think that a good advert well targetted on Facebook is definitely worth the money.
  • Side effects were the discovery that our click throughs dropped by 50% over the weekend, but that the sign up rate improved to 1 in 4. From this, I guess, we can infer that a) Facebook is primarily a work diversionary tactic, and b) people in that diversionary mode are clicking with less purpose

All in all then? I’ll be recommending that customers do it, but I’d ask them to think about only running campaigns at the weekends, particularly if the landing page from a click requires a little reading for the reader to understand the benefits.