Fragmented Development

Before 2000, developing a website was pretty cutting edge. In fact, you were hard pressed to find anything that might look like a framework. I remember learning how to code in perl and writing some thoroughly incomprehensible scripts to produce HTML table based dynamic web pages for a company. There was no designer involved, or testing, or frameworks or consistency or anything. There was some version control (remember cvs anyone?) but it wasn’t used well.

Then along came the early versions of the web specific languages and frameworks like PHP and also other things like ColdFusion (remember that?). Added to that, the marketing agencies started realising that they needed to “get in on the act” and started doing websites from a visual point of view. So the industry started to get organised and “doing a website” meant “getting a designer to design in photoshop and getting a web developer to make the website look like the design”.

Since then, marketing agencies haven’t moved on very far (in my view — I could be wrong) because actually, this approach works. Add on to it the addition of QA and testing, better management processes (various versions of agile primarily) and more consistency in web frameworks, we’re at a point where developing for the web is becoming much simpler.

Apps

The addition of the mobile app and then the mobile website added complexity, which has caused issues for the above approach. I’m still seeing briefs where clients expect that their “photoshop” version of the site is what they expect on every platform. However, the inconsistency of interfaces now means that even responsive designs are an imperfect response to the brief (but probably the best option we have). Add to that the need for multiple different skills to deliver this kind of content, then you are moving away from the current settled skillsets of development into something new.

Future

I think the future holds something interesting. Instead of the axis of development being the PM (product/project manager) to the dev (front and back end) and design teams, we’re moving to a scenario where the axis will move from the PM to the API team, who then liaises with the front end, and the back end teams.

The API I think will become all important. Purely because companies are starting to see that while the interface that they develop is often beautiful it is often also only a fragment of their interface requirements.

We’re looking at a world in the future where a “website” will move towards being a “resource”. Semantic web enthusiasts rejoice… sort of!

The key as I see it is that developing a website will soon not be about whether the actual website looks good, but whether it provides the required resources. The agility that comes with an API approach will make developing extra “interfaces” much more simple.

However, this comes at a complexity cost. To develop this infrastructure will require fragmentation of development at some level. Instead of front end (HTML/JS/CSS etc) developers and back end (server framework/rdbms/nosql) we’ll need:

• API developers delivering both API architecture and probably maintaining SDKs
• Front End interface developers including mobile apps, web developers
• Designers who can design “guidelines” for the above (not just photoshop a web page!) that work across multiple interfaces including non-visual (!)
• Server developers who will be closely aligned with API developers, but in the future more likely to work with message queues and asynchronous information rather than HTTP calls
• Data developers (scientists?) who work to provide the right information around all of this

As I see it, these people already exist, but are often siloed away from the product somewhere other than where they need to be. It seems to me that the back end will become increasingly more important, whereas the front end will increasingly become about fragmented UX experiences.

Some might say we’re already there, but I think we’re not quite there yet. Mainly because I think the PMs haven’t quite got their heads around it yet.

The forward thinking CTOs are already there I think, but I think there is a subtle restructure coming to development that might catch a few people by surprise.