tl;cr: great frontend development is not trivial, and requires a lot of power to make decisions.

There are an interesting article about how important the role of great frontend software developers is in creating great user experience. They even go so far as suggesting to move frontend developers out of the engineering department and plant them into the UX department.

I’m not sure if this advice can or should be universally applied. The reason of this move is apparently inherent priority differences between engineering and UX dept. Just like creating fixed formal software processes, this is often a hint that there might be some inter-human issue, which is better to be solved between the corresponding humans. As for me, I don’t see a reason for an engineering department to exist if they don’t put user experience over any internal technical software quality metrics. At least when we are speaking about companies producing web software. It is because the cleanness of software architecture and correctness of the source code is only important for the second and all subsequent generations, while UX is important from the very beginning on. Without an absolutely awesome UX, many startups wouldn’t even have a chance to make a second iteration.

On the other hand, frontend developers, being remote from the engineering team practices and processes, would tend to produce dirtier source code and less reasonable architecture, which would mean slower, buggier and more expensive implementation of second generation UX.

Yet another consideration is that by dividing the team in “we” and “they”, you can almost force backend developers to be if not openly hostile, then just indifferent towards UX goals and needs. This is never a good idea. All the frontend can show is the content coming from the backend, and the content (and its quality and real-time-ness) constitutes often more than 99% of a great UX.

Perhaps one would be better off by organizing the hiring practices in the company so that every single creative person would care about UX of the product. But this would create yet another set of problems – for example, how to handle the strong opinions some backend developer might have against UX decisions made by the people primarily responsible for it. And there is no simple answer to that.

What I would like to support and to elaborate in this article, is that the frontend development as an activity is very distinct from, say, backend, services or database development. You also need a very different skillset as a frontend developer. And by saying this I don’t mean that JavaScript is so much different than PHP, Java or C#. And I don’t mean you have to have a very special mind to be able to understand how to make CSS3 work for you (in every browser). Of course, these differences are indeed present, at least if you develop in HTML. But even iOS, Android or Silverlight developers, who enjoy more reasonable (as in: clean and modern) languages and tools, are very different. Let me give you an example.

The story is to program a media player (that is, an area playing video and showing some player controls as overlay above it). The first task is to program the button that would start the playback. All the visuals are already created by the designers, and by using Silverlight, they are already automatically coded, so that you don’t need to cut them from a Photoshop file and write the trivial code of placing widgets on the canvas. Basically, you can start writing the event hander of the play button. What is your first thought?

Now, an unexperienced frontend developer would think something like this: okay, so I need to fetch the documentation about the player engine we’re using, find out how to create an instance of the player, and I would expect this object will have a method play(url) or something like this, and I will call the backend service to get the url from CMS, pass it to the player, and we’ll be all done.

A great frontend developer would think: shit!.. There are so many ways to fail! What if some moron would place the player in the CMS onto the web page, but will forget to configure any movie for it? Are we going to display an error message in this case? And which one? “Thank you for helping us to fire a moron that has forgot to configure the movie for your pleasure”? Well, perhaps in this case, we shouldn’t even show the player at all, and fill its space on the page with something else. So I gotta go check this out with the web page developer, and with the UX designer, and yes, perhaps it is a good idea to go talk with the CMS guys, perhaps they can build some sort of pre-publish check or so.

But ok, even with this check, there are another ways to fail. What if the url of the media file is invalid? Something didn’t work out with uploading the movie to the server, or somebody has used characters in the url that are not allowed, or the streaming server is just down? Well, perhaps we should make a web request to the media file url as soon as possible, even before we have displayed any UI, and in case of an error, display something else? This would mean, the web page will have to be able to re-layout itself dynamically on the client side. Wow. This looks like a bigger feature request. But we don’t want to waste screen space by a big black box showing an error message “Something went terribly wrong with our streaming server”! Do we?

Still exporing the ways to fail, what will happen if we start to play, and only then will know it is not possible? The streaming server might go down a millisecond before the user pushed the play button. Or something went wrong in the media publishing so that a corrupted media file has been produced. Or our media player has some requirements on the running environment, and not every device that will run our app will be able to comply? Or the user will leave the WiFi zone and fall back to 3G? Oh my gosh, there are a lot of issues here. So, OK, I’m going to write all of them down, and then go one by one and decide how am I going to handle them…

And he will do this, and will finally realize how huge this task is, because it will include changes in the page rendering, in the backend services (because he will want backend to save the latest watched play time before the player stopped working), in the CMS publishing process, and even in the media publishing and transcoding process (because he will check how their responsive design works and how the player looks when scaled down or up, and therefore will demand additional media sources to be transcoded in various screen sizes).