Interface Developers have to be available from start to end in a project (and work with real live code)
Having had a number of jobs and from being a consultant, getting the opportunity to see how a lot of companies and clients work over the years, I’m way too often surprised how underestimated cooperation and keeping a competence available throughout a project really is.
There are two main reasons why this happens:
Interface Developers don’t want to get dirty
I’ve met a fair number of Interface Developers in my day who are just into creating raw HTML, CSS and maybe some JavaScript, and that’s it. While I can understand them, if they ever want to truly deliver, to produce a working live web site, they have to step up.
Really, how hard is it to code a perfect HTML prototype without taking real life problems and obstacles into account? When you’re sitting there, completely shielded off from the rest of the world, few things will ruin your world but at the same time, your world will never meet the real world.
Interface Developers have to get their hands dirty; learn source code control (Subversion etc), start working in “real” code environments (meaning JSP. ASP.NET, Ruby on Rails etc) and adapt your code generated content controlled by a server-side language. Throw in a quirky CMS and content texts with real words instead of Latin (oh dear), and you’ve got yourself a challenge.
Poor work methodologies
While the above can cause these sorts of problems, by far the biggest problem is when Interface Developers aren’t allowed to take part in an entire project and make sure their code holds up till launch date. Common scenarios are:
- One company does design and HTML coding, while another does actual system integration.
- Instead of working an agile manner, where people with different competences constantly cooperate, a waterfall model is applied where the design team delivers to the HTML people, who in turn leave their code off to System Developers breaking it down.
Why either of these are so dangerous is because, as any good Interface Developer knows, developing a front end for a web site, ensuring cross-browser and cross-platform functionality, is a never-ending work of fine-tuning and knowing the ins and outs of the major web browsers out there.
To instead dump the results of an Interface Developer’s craft, a person dedicating his professional life to coding web interfaces, into the hands of a jaded and tired System Developer who isn’t interested nor cares about the actual code output to the end user when he is finished filling it with real live content, seems insane to me!
I have a firm belief that you should always, always use the right person for the right job. Why would you force something such as splitting a HTML document into reusable and optimized components onto a System Developer who is skilled in so many other areas but this particular one? If you have a person who has a) created the code to begin with and b) will create the end result faster and more correct, why the hell wouldn’t you assign that task to him/her?
And what’s even more ridiculous is that it should be so extremely evident that if a Designer leaves his code to an Interface Developer, and completely cuts off the ties (due from being from another company or getting other new tasks to work with), and the Interface Developer in turn leaves the code to a System Developer and never sees it again till it’s in test, or, worse, is released live, is that the result is almost obliged to become sub-par.
The Designer usually doesn’t even recognize his design, and the Interface Developer wonders how in God’s name his perfect validating code has ended up in nestled P elements and H1 elements closed multiple times in a row (just to really make sure it’s closed…) just because some glitch in the server-side code, which never got a quality check.
People will think the design sucks, and the Interface Developers will get a lot of shit for invalid code which is both inaccessible, bad for SEO and takes forever to load. And here you have a majority of the roles in a project being responsible for parts someone else messed up, and they weren’t even allowed to be there to make sure it didn’t happen. Does that sound fair to you?
Or, more importantly, does that seem like a good business investment?
What I propose
The way I suggest people work, and how I myself work in the projects I’m involved in, is that every competence in a project, especially the ones in producing roles such as Designers, Interface Developers and System Developers, work side-by-side the entire project, preferably sitting so close to each other so they can just turn around and discuss something as it comes up.
Every represented skill set doesn’t necessarily have to be there full time, but rather consistently from the day work is begun till it reaches its deadline and is released. Some people would argue that there might be a cost increase with this approach, but compare that to the badwill and costs of redoing and fixing something already released over and over again, just since things weren’t properly discussed when they surfaced, and the people with the wrong skills were used for the wrong job.
Let’s put a stop to poor web sites being released due to lack of working together, assigning tasks to the wrong team member and neglecting to see that it always has been, and always will be, completely vital to collaborate to become genuinely successful.
