Seismic Shifts in Web Development

Tags: Knockout, pubsub, observer, MVC, jQuery, Ajax, EF, Validation, FluentValidation, Visual Studio 2010, ASP.NET, JSON, FullCalendar, Silverlight, Architecture, Vista, IIS, Generics, NHibernate, WCF, RIA Services, Visual Studio 2008, SQL, STORM!, Nullable, ChannelFactory, netTCPBinding, VSPAT, responsive, design, HTML5, CSS3, MVC WebAPI, MVC 4, WebAPI, JQuery Mobile, ScheduleWidget, recurring events, Ninject, Pluggable, CQRS DDD, Windows

Not really. But then again really. What I mean is the role of the web developer is changing fast and it's only been in recent months that I've looked up from my keyboard to see how the ground has shifted substantially. Some developer friends and I have often joked that the back end -- the database, object-relational mapping, domain model, business logic, and the controllers for the UI -- take us about a fraction of the time it takes us to get the UI right. We will sit for hours just to get the HTML right, float div tags, give up and go with the table tag, try again, move on, and so on and on. And now with awesome tools like EF and LINQ it's a breeze to do the sort of plumbing work that used to take weeks. 

I think those of us who consider ourselves to be web developers need to come around to a simple truth. Increasingly we are needed for front-end skills and not the back end stuff. For some that will be a blow to the ego. I went to school for this stuff! I'm an engineer not a designer! But the demand now and into the future is going to be for the kind of web developer that knows everything from soup to nuts. Those who know jQuery, JSON, Ajax, Knockout.js, CSS3, good design principles, and can make a web page look and feel gorgeous will be worth their weight in gold. This will be our primary selling point and the back end stuff that we take so much pride in now will be a skill that's assumed. I'm not talking about very complicated business domains here of course. I'm talking about simple to medium complexity projects, the bulk of them out there, where the customer does not want to pay for a designer. In fact, he resents your suggestion and wonders why you can't make a web page look decent to save your life. 

I used to be one of those developers who would surf for guidance on floating div tags only to run into yet another designer's blog who seemed more interested in showing off how clever, artistic, and utterly esoteric he could be rather than simply putting up clear and concise HTML markup. But I can't afford to sport that attitude any longer. The front end is changing fast and for the better with HTML5 and CSS3. I (and we) need to bridge the gap and move more into their camp. Right now if you call yourself a web developer you should read Ethan Marcotte's article entitled Responsive Web Design and other articles like it. This is where things are going. I've come to the conclusion that it's no longer enough to be a web developer who passes things off to a designer. We need to be designers as well.


  • Paul Chu said

    Hi James, Yeah, thanks for telling it like it is. Asp.Net WebForm Developers have always said that the Business Classes and backend Sql Database design, concurrency and transaction processing were the "bread and butter" skills with the pretty UI ( and Cross Browser headaches ) being a separate job. Well, with LinqToSql and now Entity Framework abstracting the Sql for us, we can concentrate on the front end where Javascript Libraries rule. Best, Paul ( LA Guy )

  • David said

    Hi James, it might be the way the *customer* is thinking, but it doesn't necessarily make it right ;-) It's possible to be adequate at many things in software development, but you cannot expect people to be masters of all. Many if not all of my recent clients are in fact businesses who have gone down the route of having a (rushed) product that looks pretty, might be wonderfully 'designed', but is badly 'engineered'. So further down the line they end up paying more in maintenance, upgrading and refactoring, as their business needs change, than they would have spent if they had done it properly in the first place. In addition to knowing how to architect an application, select and be proficient in the use of the numerous technologies that can be applied to the solution, deal with infrastructure decisions (often purchasing), gather business requirements correctly (the customer rarely knows what it is they really want), lead a team (sometimes hiring developers), train a team, document the architecture etc I am usually required to have industry specific knowledge of several years, oh and ideally be fluent in Dutch or German, while training myself in my free time. And those are not enterprise customers, they are the medium sized businesses who don't want to pay for two people. Personally I feel that's enough of a set of skills ;-) I trust my highly trained doctor to diagnose and prescribe the correct medication if I fall ill, but I don't then also expect him to make high quality medication for me - that's a role for another specialist. The software industry has been it's own worst enemy; skills which do take a lot of effort and time to learn, which need to be relearnt continuously as technology evolves, have been allowed to be treated as commodities by the end-clients. It's treated as a cost, not a benefit, even though every company is reliant on software when it looks deep enough. Hence the race to the bottom with offshoring etc. An example of this is the state of IT recruitment - I cannot remember the last time that I talked to an agent who understood anything that the client specification or my CV actually meant, yet these are the people who are responsible for placing a large proportion of software developers in contact with the potential employer of their services. In short, lets try to fix the lack of awareness of the importance - and yet complexity - of IT to non-IT people, not burn ourselves out trying to make up for it. Companies need to taught how to approach IT projects properly.

Comments have been disabled for this content.