We set up LiverpoolWebDesigner.com on the WordPress.com service in part because we were curious about what the traffic effects of being on WordPress.com could lead to.

But you know, there comes a time when you want to play with the extra features that a self-hosted WordPress site can give you over the hosted options.  We want to use some of our own themes, instead of the limited selection here and although our themes are lined up to become available at WordPress.com, it’s taking time.  A loooong time.  And some of our cleverer stuff isn’t even suitable for here.

So on that note… within the next week or so, the moment you find this post has disappeared and been replaced by a We’ve Moved post, you’ll know that we’ve gone to our new home on our own server.  Join us and help us warm the place up!

I’ve been thinking hard about Open Source and whether or not to GPL all of our forthcoming themes at Spectacu.la, following on from Brian Gardner’s decision with Revolution.

And I’ve decided that it would be a rather bad idea for us.  In fact, if you’re trying to build a strong business up from Open Source you can never make everything truly open.  So for example, although WordPress is free and GPL, WordPress.com has lots of proprietary code that will never see the light of Open Source.  And you pay for various services that use this proprietary code.  At the same time, they can cheerfully absorb, at zero cost if they wish, various GPL licensed themes and plugins.

A Toaster Analogy

The broken toaster - by Charles Dyer (CC License some restrictions)

A toaster company realises that although developing toasters is hard and expensive, they’re practically free to manufacture.  So why not give the toasters away and just charge for repairs, and helping people install their toasters at home, cleaning services, insurance if it burns the house down and so on.

Where does the motivation for service rather than product related income then come from?  Well - it comes from not making a simple, reliable and easy to use toaster.  In fact, because anyone can copy your toaster, you have to continuously add new features to stay ahead of the rival toaster copiers and keep people coming to you rather than your rivals for help.  You can make your toaster corporate strength - a toaster for major organisations that need to make vast amounts of toast… and they’d definitely want support and help… but you end up with small users running vastly over-powered and over-complicated toasters.

In fact, if you make perfect, simple toasters that just work for a long time, the business can’t make money.  It might even be unable to make enough money to develop new toasters unless it has a near monopoly on the toaster market.  If people can simply receive their toaster in the post, plug it in, and make bread brown, then how does the toaster maker generate some income?

A business makes money by solving people’s problems.  If your product is free then it needs to create new problems in order to give you a continuing income stream.  Open Source as a business model, rather than as a philosophy, is rather similar - even if that isn’t always the actual intention.  In fact, I believe almost all Open Source projects start with good intentions but end up shifting somewhat because ultimately, the developers, writers and other members need to actually make a living and put a roof over their heads.

The Exclusivity Problem

This is another major issue.  If anybody can use your product, regardless of whether somebody uses your add-on services or not, you have no exclusivity.  And people do want that.  If everybody could simply download a Bentley, a lot would do exactly that - even if it was far too big and unwieldy for their needs.  Some would learn that the maintenance costs would be ruinous, but many would persevere - bodging the thing along as best they can.  Before you knew it, there’d be modified Bentleys everywhere looking like they’d crashed into a Halfords store.  At the same time, the original market for Bentleys would disappear - they’d either go bespoke, or find a maker that doesn’t give away its cars to just anybody.

Closed Source Software Suffers Too

Of course, closed source generates its own problems too - and in fact, can be just like Open Source in this respect.

I used to be an independent PeopleSoft consultant.  PeopleSoft is an ERP software package, now owned by Oracle, which helped large companies to run themselves.  But it wasn’t perfect software in any way.  In fact, I believe that PeopleSoft made more money from supplying consultants to their clients than on licensing fees.  Perfecting their software - making it super flexible, easy to understand and slick to implement would have cost them a fortune to do while at the same time losing them their lucrative support business.

In fact, it’s worth noting that PeopleSoft’s original founder, Dave Duffield, toyed with the idea of an Open Source ERP system for a while, but that appears to have gone over to a hosted solution - another way in which a company can control the software.

So What’s the Benefit of Open Source?

Well in many ways, it’s wonderful stuff.  People can check out the code, add their own improvements and the project can choose whether to integrate it.  Similarly, projects can look at improvements made by other GPL projects and take that code themselves.  This is great for rapid software development and saves a lot of the real trouble of license management.

My big worry is the business motivation.  Few businesses in the software field are motivated by the concept of making perfect ‘just works’ code.  I believe that few Open Source projects, with exceptions (Ubuntu is one) have this desire.

So - should a company go open source?  Well, if they can guarantee being a market leader, then why not?  Brian Gardner, at the moment, is perhaps one of the market leaders in the WordPress themes market.  We’re not, because we’re only just starting out.  We need to feed ourselves, pay for equipment and so on.  Somehow we need a revenue stream - and one thing I’ve discovered is that if you write really good, reliable code, you don’t get much in the way of aftersales income.

While I believe in Open Source, I don’t believe it suits all businesses and all projects.   In WordPress themes, the simple ones are suited to GPL because they don’t really take much time to code up (a couple of days for many of them) but the complex stuff can involve significant amounts of artwork, development and testing.  If you do a really good job, nobody will need you after they’ve installed… and then what?  Goodwill doesn’t pay the bills.

Now, this may seem a little bit of a testy post.  But ultimately I want to help.  The post’s being written because I was thinking back to the past couple of years, and the range of clients and potential clients I’ve met.  It’s also based on what I’ve seen in forums, on websites, and in other events.

To be honest, most of our potential and true clients are great.  True pros who value what we do, and trust us to do it well.  But there have been a few who tried our patience.

So here’s ten simple rules of how to work with web designers, developers and other IT professionals.  Most of it boils down to the headline.  Be professional yourself and reap the rewards.

1. Don’t Call Us Geeks

No really.  Don’t.

I can call me a geek.  I can call a geek a geek.  But just like I can’t call a black dude n**ger even if he uses the word himself, you can’t call me a geek.  It suggests a lack of respect.

And don’t even think of calling us nerds.  That might just add 50% to your quote.  Or at its worst, cause an undesired tension in your working relationship which is far worse than paying a bit more.

2. Remember that it’s Complex and Fragile Stuff

Writing code is hard.  No two ways about it.  Writing a lot of code that interacts with other code is even harder.  That means that building a sophisticated website, that looks right in every browser, is hard.  Writing one that you can install on varying versions of PHP, mySQL and Apache is even harder.  Writing one that’ll work on Zeus too is a touch harder again.  In fact, let’s run through some numbers:

I’d estimate I’ve seen about 20 different versions of PHP installed on servers.  There’s a lot more, but let’s just stick with what I’ve seen.

Then there’s at least ten different mySQLs that I regularly see, that’ll work on each of the above PHP versions.

Looking at our server logs, there are about fifteen commonly used browsers and browser variations.

And there are six commonly used platforms (eg, Windows XP, Windows Vista, OSX, Ubuntu, iPhone, Windows Mobile)

So - for a single install of our code we’re looking at a minimum of 20×10x15×6 permutations of environment by the time something is delivered to an end user.  18,000 different possibilities we have to consider.  Without even thinking about minority stuff like Opera on Symbian phones.

But you’re thinking that all those variations are all essentially trivial, but here’s one that caught us out recently:  Put what’s known as a regular expression in at least one version of PHP inside double quotes, and use a $ in the expression and PHP tries to parse the $ as a variable.  Put the expression inside single quotes and it’s fine.  It’s a subtle difference which didn’t show up in testing, but the minute we loaded up to a server caused problems.

When we code, we need to take consideration of as many possibilities as we can.  We do our best, but mistakes will always slip through because we don’t control the environment in todays broad base of platforms.  Twenty years ago I coded for just one link library, one compiler, one OS version and so on.  Before a change to any of those we would run our code through and make sure the results came out the same.  But with at least 18,000 variations to consider it’s impossible to test every possibility, or to know of it.

So yes, things will break.  Deal with it, or accept the developer’s specified platform requirements.  And things still might break.  You can’t afford to have unbreakable code.  Well, you can if you’re building an airliner, I suppose, but otherwise, no.

3. Learn How to Assess a Professional

Don’t assess a pro by the quality of a salesman, their literature or the cut of their suit.

I know very little about accounting beyond the basics.  How do I know if I have a good accountant or not?  Well, I asked people who shared values with me for their recommendations.  I asked a few questions.  I also did a little reading on the subject.  Ultimately that decision might have saved me £50k over the years.  Or cost me that.  To be honest, I can’t really be 100% sure.  I’m pretty certain things were good but at the end of the day I have to trust the guy and listen to his explanations.  My initial research was worthwhile because of the exposure to risk.

Same goes for hiring developers.  You can get two developers, both smooth and charming (well, as smooth and charming as an IT guy can ever be), who’ll build you an application for completely different budgets.  I mean, you could be talking about one who’ll quote £2k and another £20k.  A third may be quoting £200k!

And you know what - they could all be spot on.  Not one of them ripping you off.  £2k guy may feel that £200k guy is a robber and little more.

Again, ask questions and do your research.  £2k may be doing little more than buying in an off-the-shelf application and skinning it up or modding it to fit.  He may or may not tell you.  The code may be closed to you too. £20k guy does some better quality analysis and produces a lot of code in-house, but you have access to the code and you can fix things.  You may need to - if it was hastily produced he may have had to not consider so many of those 18,000 possibilities, or scrimped on testing.  He also supplies no guarantees at all.  £200k guy is top flight - his code is expensive, for sure, but he guarantees it, patches it for server updates, and writes beautifully structured code that a different future developer can understand and extend.

So which do you need?  Well that depends on what you’re doing.  Testing the waters?  Building up a massive online empire?  Making a car?  So ask lots of questions, ask for recommendations, look at their work, and talk to their current clients.

4. Have Reasonable Expectations

A £2,000 investment is unlikely to make you a multi-millionaire.  Internet fortunes were never made by the cheap or the lazy.  Accept this.  This isn’t the lottery - it’s real business, with real work in order to provide the real solutions that earn people money.  The easiest way to become an Internet millionaire is to become a developer - because then you can take shortcuts and get away with it.  When we develop for clients we can’t afford to take shortcuts :- you might sue us.

5. Don’t Expect Research for Free

If I already knew exactly what to do to make a fortune in your chosen business sector I’d already be doing it, so don’t expect a development company to be able to deliver instant answers.  If you don’t want to pay for research, do it yourself and take responsibility for it.

A story: I had two guys come in.  A little Jack-the-Lad in style, but fine enough.  They’d spent lots of money in online casinos and realised that it makes good money.  I’m sure it does - many are unregulated and many cheat their clients.  But hey, I’m not here to moralise.  So these chaps have made a bit of money in property and they want to make more in the exciting world of online gambling.

I need to make sure they’re serious, so the first thing I ask is have they done any research.  Well, apart from using the sites, no.  They claim knowledge of the regulatory requirements, so that’s something, but I can’t tell if it’s bluster or not.  Next I bring up the question of creating a proper requirements document, with analysis of approaches, software available, costs and so on.  That’ll be about a week’s work, won’t cover that much detail, and will cost around £2.5k.  This document may tell them that it’ll cost them £100k to develop a decent online casino, or it may even tell them not to bother.

The response was quite typical “What, we’ll pay you before you’ll even tell us how much it’ll cost?  Hah!”

I did try and point out that they weren’t buying a Ford Focus.  They left, and I very much doubt they ever got their online casino off the ground.  Alternatively they may well have been ripped off with a complete mess of a site.

Ultimately we’re not experts on everything.  But we have to become experts on what we design and code.  Think about what that means.  I couldn’t design an accounting system without a thorough understanding of accounting.  Researching and understanding stuff takes time and costs money.

6. A Mock-up is not a Design

It just shows us how you expect it to look.  It tells us nothing about how it’s going to behave.  What happens when someone presses a button?  What’s the security got to be like?  And so on.  And you’ve probably missed a ton of design elements that we’ll have to do ourselves anyway - the number of designs we get through which haven’t thought of how blockquotes, comments or even anchor colours will look is laughable.  Designing them for you, or having to think about those things, is going to cost you more.

7. No - We Can’t Just “Throw something together eh lads?”

It doesn’t work like that.  Well, it can, but only when we’re doing it for ourselves in an environment we know.  Ever watch Scrapheap Challenge?  That’s what thrown together cars and boats look like.  They’re dangerous and liable to take a layman’s finger off if he’s not careful.  Well it’s kind of the same with software, albeit without the missing fingers.  Unless it’s embedded software in your blender, in which case you never know….

8. We Don’t Know Why it’s Broken Until We Look at it

So don’t ask us how much it’ll cost to fix your pile of crappy, broken code.  Or even the pile of crappy, broken code we supplied.  It could easily be a one line change.  Unfortunately it’s buried in thousands of lines of hard to read code.  We’ll do our best, that’s all we can say.

9. Your Specification is Full of Holes

It is.  Which means that an unprofessional development company could produce exactly what you ask for, demand their money, and be entitled to it.  And you’d still have a rubbish lump of code that doesn’t work, falls apart under pressure, and sends your customer’s credit card information to a bicycle shop in Bangladesh.

A good developer will look at the holes and make sure they’re filled, keeping you in the loop as much as possible.  Some of those holes may result in an increased bill.  There’s a simple answer of course - create a specification with fewer holes in it….

It’s also one of the key reasons why offshoring to far-away, cheaper economies, can be a nightmare - communication is harder and so as a consequence those holes don’t get spotted, and yet you still have to pay for what was built.  Really you need to work closely with your developer.  8,000 miles distance doesn’t really help with that.

10. And Finally - Be Professional Yourself

Behave towards developers and web designers in a way that you’d appreciate your clients behaving towards you.  Calmly, carefully, with trust and without a need for constant justification.  What you do is hard and useful - that’s why people pay you a premium for it.

Summary

Yes, what I’ve written may appear a little ungracious towards to the people who pay our bills.  It’s not meant to be - really it’s aimed at helping all those who want to take part in this great adventure that is the Internet.  It’s a wonderful place, but like all frontiers it’s dangerous and there are conmen out there looking to fleece the gullible.

I hope the tips help you in your dealings with IT professionals.  I’d also love to hear any other tips…

You know that over-clocking experiment?

We had an interesting failure recently. The server for one of our larger clients, who have their own high-spec dedicated server arranged, went down. We got the alert by text, and swung into action.

Well, more accurately we had called the hosting providers and told them to fix it.

They gave no solid reason or explanation as to why the server had died, but within in an hour things were normal enough.

Or so we thought…

In fact, things in the background weren’t looking so great. The hosting provision is rather off-hand. Off the “here’s a box, now off you go lads!” variety. It came with just an OS and an SSH connection. Nothing, and I mean nothing was installed. No fancy control panels here. No web server even. Or ftp. You were expected to do it yourself. Right down to compiling code.

So really, when they brought the database back up I should have known better. They ran no checks. They simply loaded the service and closed the ticket.

Unfortunately a few days later we started getting support calls from the users:

We can’t see our categories or tags.

Publishing in advance never works.

And then more alarmingly:

One of the blogs has disappeared!

The latter was a worry. It was one of the most important blogs on this MU install. It needed to be restored.

What I found was alarming - any attempt to look at wp_x_options for that blog in the admin panel caused an error. PHP was throwing up errors everywhere. But when I queried the table it looked fine.

In the end it was connecting with mySQL Administrator, a wonderful tool, and trying to do a backup before starting anything technical that revealed the true extent of the troubles. And there it was - it couldn’t backup one table because it was completely corrupt. Do a repair on it and ‘Hey presto!’ fixed.

But that wasn’t the end of it. The other problems still existed. I thought that this rebuild would have been fine, but no. The Administrator app didn’t find anything obvious, and when I looked in the taxonomy tables to see what was wrong all seemed fine - if you did a select on just one table.

But if you ran a join, things fell apart and you received zero rows. This time I decided to run an extended check on the whole database and found that of the 116 tables, five had indexes with link problems. Now, if you don’t know, an index in a database is essentially a linked list - this is a fast way of allowing data to be added without having to shuffle things around too much. Break a link and that index falls apart - especially on joins that need to find everything on a table.

So a repair against all affected tables and we were done.

If you get this kind of weird behaviour, especially after a crash, it can be well worth looking through the tables for problems like this. Do make sure you know what you’re doing, however - mySQL Administrator is a powerful, quick and dangerous tool!

After weeks of hard work, I’ve finally finished it!  The WordPress 2.6 User Guide is ready for the world.

I’m not going to make it available directly from the blog any more, however, as we’ve decided to roll things like this up into our Spectacu.la WordPress Themes Club as a resource.  Non-members can download and use the pdf, and members get the Word document in case they want to rebrand it.

I guess it won’t be long before WordPress 2.7 turns up, but in the meantime this document represents a significant move ahead of the old.  Revised in many areas, it helps most beginners learn the ropes.  It doesn’t cover things like installation or problem solving, but for the vast majority of users it’s just fine.  We originally wrote it for our own clients, so that they could understand how to manage content on their site.  It’s also designed for printing out - sometimes people prefer it that way, and a website isn’t always the best approach.  At least this way you can choose.

One of our clients is the Georgia Energy Efficiency Programme with their website at http://energocredit.ge - and nice people they are too. Now, Georgia, in case you don’t know, is a small former USSR state between Turkey and Russia. Relations between Georgia and Russia have never been brilliant, and there’s a lot of complex politics going on which I won’t go into here.

Well, with the Olympics diverting the world’s attention, Russia stepped up hostilities. The attacks on the city of Gori aren’t really that far from where our clients are in the capital, Tbilisi. And it’s weird. We’ve worried about clients going bust (happened twice already in the company’s history) and we’ve worried about clients that are undergoing upheavals. But we’ve never worried about them being in danger of military actions. And that’s an altogether different feeling.

So here at Interconnect IT we’re wishing all the best to our Georgian friends, and following the blog of their British team leader Helene Ryding. It’s an interesting insight into what it is to be in a country that’s under attack.

Not. A. Lot.

Unless you’re:

1. An enterprise
2. Really keen that the annoying bugs are fixed
3. Want to download the third party applications that are now possible, but heavily controlled by Apple

Ultimately, the iPhone is now more or less where it should be.  I’m still annoyed that not just anyone can develop for it and release applications in the manner they see fit - you have to release through the iTunes download service.  It’s still got an appliance mindset about it that I think holds it back.

Of course, Apple’s approach is all about an easy user experience at the cost of reduced flexibility.  It’s neither bad nor good - I have a now unused WM5 device and it got some elements of its UI and features management terribly wrong.  Once set up it was really handy, but it was best suited to enterprise and expert configuration, not to consumers.

I was recently sitting quietly thinking about why so many great things appear to be happening right now.  Open Source projects, Wikis… an incredible amount is going on.  I see amazingly talented yet amateur photographers every day now, thanks to the internet.  Once upon a time I’d maybe see an amazing photo once a week… and I had to pay for the privilege of seeing something picked out by an editor who hopefully had similar tastes to mine.

And this article at herecomeseverybody.org gives one suggestion as to why this may be happening.  The numbers are startling.  Have we really been on a media driven bender for the past fifty years that we’re finally escaping from?  Fascinating reading.

One thing we talk a lot about is how important it is, for costs, to stick to problems which have already been solved. Get fancy and do something new, and your costs have rocketed away.

A developer has just done a nice little piece on spellchecking. In 1984 it was ferociously hard. In fact, if you wanted a decent spellchecker in your custom application you had to pay dearly for the priviledge. Today it can be accomplished in a few lines of code.

It means that what was once going to cost you £100k to add to an application is now a few pounds.

Similarly, when we develop we offer up lots of wonderful functionality at incredibly low cost, because we’re just pulling in something that’s already been done. But if someone asks us for something custom, the price leaps up. They don’t always get it.

So here’s how we do it:

Step 1

We don’t know if the problem’s been solved before, and we don’t know how long it’ll take us to solve it either, so we give what may be considered to be evasive responses. We need time to research. Someone has to pay for that. Depending how interesting this research is to our business model, we may subsidise it. Otherwise, the client pays.

Step 2

If we find the problem’s already been solved, we still need to test the solution to make sure it applies well to the client’s requirements.

Step 3

If all is well, and the solution is found quickly, the client gets a call to say “yup, no problem, it’ll take us x amount of hours.”

But if we found no solution, we have to estimate how long it’ll take to develop the solution. And that’s hard in a commercial sphere. People don’t expect to spend much on R&D - they just want solutions.

So we do spend a lot of time trying to get people to understand the difference between solutions, and development. Just like a DVD player is a £30 piece of kit if you buy one from Sanyo while it would cost millions if you tried to make one your own from first principles. It shocks folk, but it’s an important message to get across that all developers need to take on board and to pass on to clients, or they end up stressed and trying to do the impossible on very low budgets.

It’s hard to measure the cost of code.  Simple stuff can be ferociously time-consuming to develop, and bad coders often produce reams of poorly structured code.

But let’s assume you’re dealing with a typical, decent developer who doesn’t take the long route, or dangerous shortcuts.

There’s some nice research covering this, such as Boem, Abts Chulani [2000] which is worth reading if you’re interested by this kind of stuff.  But it’s heavy going, and doesn’t give a nice neat figure for lay people to understand.

So now I’m going to give the answer that many want to hear:

For each line of code produced in a 3GL non RAD environment the cost of your development is likely to come to around £20-£25 per line of new code.  And about £100 per hundred lines of re-used code.

Doesn’t sound too bad… that includes testing, development, refinement, code reviews and so on.  It’s based on the idea that most good developers can produce around 50-100 lines of code in a day if left alone and in peace.  Some produce reams of code, but it’s often poorly optimised and thought out and likely to bite back in years to come.  The cost also takes into account the design of that code before anyone touched a computer, and the various support staff required.  If a developer is working entirely alone and is self-supported with his PCs and the like, then his productivity drops so the project takes longer, but the cost shouldn’t change too much.

And don’t forget that cheap code is often bulkier than expensive code.  Which means nobody can look at a 1000 line program and actually say “Oh yeah, that’s £20k’s worth.”  Somebody needs to assess the quality of that code.

What we will say is that in general, if we’ve written you 1000 lines of fresh code (ie, no cut and pasting or reuse) it could well have cost you £25k by the time it’s fully tested and delivered.  A really big project, like, say, implementing a worldwide global payroll system for a major corporation may have five million lines of code and a final bill (including analysis) of around £125 million.  Not at all unreasonable, believe it or not.

So yes, code is expensive.  And that quick report you’d like us to knock up?  Maybe it’s not so quick.

To save costs it’s worthwhile looking at RAD (Rapid Application Development) methods, but in that you’ll end up with slower, more bloated code.  However, it can be a perfectly adequate approach and we use it all the time for simple data management back-ends and the like where performance isn’t that critical.  Sometimes we’ll generate 20,000 lines of code from a three hour job… but it gets the job done.  Albeit a little slowly!