We’re moving! Sort of…

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!

Open Source Isn’t for Everybody – a thought experiment

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.

If You Want to Hire a Professional, Act Like One

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.

WordPress Database Corruption and its Effects

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…

WordPress 2.6 User Guide

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.

Clients in a Warzone

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.

What Does The iPhone 2.0 Upgrade Mean For 95% Of iPhone 1 Users?

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.

Why So Much is Happening

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.

What Used to be Hard, Becomes Easy

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.

How Much Does Code Cost?

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!