The Internet has been around for a long time. At least 15 years. Over half a lifetime if you are a twenty-something dotcom millionaire. For the rest of us with an interest in the web it is certainly long enough for a few different ‘eras’ of web development to have come and gone with a few useful lessons along the way.
One of the eras that had it’s heyday in the early to mid-noughties, and which has thankfully fallen well out of favour with savvy decision makers, is ‘in-house development’. Now don’t get me wrong, there are plenty of talented web designers, webmasters, website administrators and DBAs embedded within a non-software company’s ‘IT team’.
That might be fine for running a content-based website and manually pulling custom management reports, but ambitious firms that want to move chunks of their business online are playing a different game. Confusing ‘simple web design’ with ‘advanced web development’ used to be a common mistake and the business landscape is littered with ugly, half-working hulks of web-code that are an embarrassment to staff, clients and partners alike.
Most of these projects started out in a blaze of glorious vision and genuine confidence for all parties, so how do so many end up in tatters? Let’s look at some of the fundamentals:
Most people who use your company app will spend hours a day on Google, LinkedIn, Facebook and other world-class systems and will (subconsciously) expect your app to have the same billion-dollar look-and-feel. We can rationalise the link between functionality and budget but the look-and-feel of the app is an emotional channel which is harder to overlook.
The best professional web teams will continually scan the shifting landscape of 3rd-party plug-ins, themes, widgets, and galleries that enable us to mimic the slick feel of the big sites at a fraction of the cost. It’s understandably harder for your in-house team to look ahead when they have a myriad other priorities, but that creates a real risk with the emotional engagement of your users.
We’ve all seen how it works with any in-house department: the team have their morning meeting, discuss the priorities, carefully plan the week… and then the MD sticks his head around the door.
MD – “Why don’t we have a section on the website about our advisory service?” (Techies heads shrink into shoulders, Head of IT gamely stands up)
IT – “Er, I thought we didn’t need that until April?”
MD – “Did I say that? Well, Sam from Wotsit Client is coming over on Friday and we really need to send him some stuff before then. Can you get something up for us this week?”
In our experience, in-house IT Teams don’t tend to argue the strategic priorities with the MD so that’s another week gone when the strategic web development is pushed back. And guess what, next Monday there’s another short-term priority, and another, and then disillusion sets in.
It might be a romantic idea that Facebook was hacked together by a bunch of cool college kids who wrote code ad-hoc between the pool party and the next drinking binge but mere-mortals need a method to the madness.
I’m sure there is an in-house IT team somewhere that manages to run an effective Agile process but judging by the Agile meet-ups that we’ve attended, getting a good methodology accepted by the wider organisation is one of the biggest frustrations of the in-house guys. In-house teams are just too vulnerable to the next urgent priority – the constant interruptions that disrupt strategic, methodical development.
4. Team Roles
In-house teams tend to be infrastructure-led. The team started out because the organisation needed someone to setup workstations and keep the network running. At some point, a ‘programmer’ was recruited because the head of IT recommended it. Now we can build a world-class web portal, right?
Er, well there are rock-star developers who can design and build world-class systems on their own, or with one or two others, but they are hard to find, hard to keep, easily bored, and let’s say they can have ‘challenging’ personalities.
A professional web development team will take a completely different approach to hiring based on expertise, cultural fit and group function. Yes, everyone can do a bit of everything in the best Agile teams, but there is always a workflow which predictably gets results: analysis, designers, developers, testers, quality assurance and project management.
These are the essential roles to create quality product reliably, every time. In our experience it is very unusual to find an understanding of these roles in an in-house team, let alone the right individuals to perform them… and the product development suffers.
5. Knowledge Preservation
Have a think about the in-house tools you are currently using. You probably know of an Excel spreadsheet somewhere in your organisation that was created by Eric, a few years ago. Everyone agreed that Eric was an IT-whiz and he wrote some amazing macros that pulled those reports much faster than the old manual way.
Where is Eric now? On holiday? On sabbatical? Left for that other firm? Emigrated? Died? Hey, but that Excel spreadsheet is still working, well some of it. You’ve been meaning to convert it into a web app for a long time but the 83 worksheets going back to 2004 would need to be moved over and life’s too short…
In-house web development means going down the same road. Times Ten. Good web development is harder than Excel macros and a lot more costly. There is a reason why government software projects get written off with billion pound losses: the effort required to remedy problems grows exponentially with each day that passes. Web development must be setup properly from day one and kept on track every day thereafter.
If these words of warning save one organisation from ‘bad-app hell’ then this post is worth writing. Web development should be a joyous experience and should be done properly by passionate, inspiring professionals. Be sure to put your company app in good hands, for the long-term.
Find out more about our development process on our website