Project Management

Why traditionalists should take Web developers seriously

Justin James urges traditionalists to drop their prejudice against Web developers. He says that Web developers have the skills that even traditional applications will use in the future.

There used to be a sharp distinction between application developers and Web developers. This made sense when technologies such as Perl/CGI, classic ASP, standard JSP, and PHP ruled the Web development roost. But this distinction is becoming less relevant with the demise of Perl/CGI, the replacement of ASP with ASP.NET, JSP getting the full Java Beans treatment, and PHP being moved to an increasingly niche market and PHP playing an increasingly specialized role. Sadly, recruiters and hiring managers do not quite see it this way -- and neither do many developers.

In the TechRepublic forums, many Web developers say they are often not taken seriously by people involved in more traditional development models. I think this attitude comes from the way many Web applications are architected. In reality, these applications are probably not true Web applications but rather dynamic Web sites. The dynamic Web site systems are written in a way that makes traditional developers shudder. These systems are not traditional, and it would be a mess to write a desktop application or server-side service the way these programs are written.

This is changing quickly. Over the course of the last year, I reviewed hundreds of resumes and interviewed dozens of applicants. I found that applicants who had not necessarily worked with Web applications were still a great fit for our positions -- as long as they were starting in the middle tier and data access layers of the application. Out of the 10 or so developers we hired, only one is especially experienced in the presentation end of Web applications (HTML, CSS, JavaScript), and some of the others have "drag 'n drop" level experience within Visual Studio. This mix of experience is working out just fine.

Web applications are "icebergs" just like more traditional applications -- only a small fraction of the actual code results in something visible to the end users. Anything below the presentation layer in a Web application is almost identical to a traditional application. The challenges are the same -- the differences lie in how they are resolved. For example, in a Web application, the Web/application server automatically handles the multiplexing of incoming connections; the consequence is that you need to learn and work with the assumptions that the Web/application server performs that multiplexing. (Concurrent access to session data immediately comes to mind as an example.)

The presentation layers are getting more and more similar. The WPF replacement for Windows Forms in .NET brings the declarative markup language syntax to desktop applications (for better or worse). Silverlight makes the XAML syntax work for Web applications, which unifies the presentation layer for Windows and the Web. Frameworks and techniques like OpenLaszlo, Adobe AIR, and AJAX are trying very hard to allow Web applications to look, feel, and behave like traditional desktop applications. I believe that trying to put that type of functionality on top of the HTTP protocol is a bad kludge at best, but my opinion seems to be in the minority.

I think these systems are train wrecks, and TechRepublic readers seem to agree with me based on their feedback. Even if you're not a big fan of things like this, Web services are here to stay. As a result, even if these systems do not gain much traction, the trend towards RPC-type functionality over the HTTP protocol is only getting bigger. This means that even traditional developers are dealing with Web services and that they often replace their proprietary communications between client and server with Web services. The end result is that, even where the presentation layer relies upon native GUI API calls, the architecture is (for all intents and purposes) an N - 1 tiered application.

Traditionalists need to drop their prejudice against Web developers because Web developers have the skills that even traditional applications will be using in the future. As we head towards the point of inflection between client/servers applications and Web applications, shops that rule out Web developers as second rate will find themselves increasingly unable to hire talent or even compete.

J.Ja

About

Justin James is the Lead Architect for Conigent.

36 comments
eftpotrm
eftpotrm

I started working with web apps, and now do client-server PC development. Hand on heart, no question, the later work we did in web apps was far more sophisticated, better architected and more maintainable than anything I've come across since I crossed over. A more structured code base, consistent naming conventions, separation of presentation from operational code, far better use of library code. Easier to reconfigure, better security, developers who understood about things like SQL injection and coded to protect. Big, monster apps with hundreds of screens and big thick user guides. And in classic ASP, too! I've no doubt there's plenty of good Windows coding out there, but I know a team of web devs who could consistently churn out top quality, sophisticated applications that I'd hire over pretty much all of the Windows devs I've worked with since.

Tony Hopkinson
Tony Hopkinson

Nah, traditionalist vs cookie cutter, solution provider, MBA who once did a macro is the real split. The fact that cookie cutting tends to be considered more approachable in 'web applications' read collection of dynamic web pages, is disguising the real problem. I've seen poor code/design in just about every environment, had naff all to do whether it was web based or not. In fact traditionalist is a bit of a misnomer, the distinction I'd make is programmer, vs person familliar with a programming language / environment.

kpthottam
kpthottam

Here is why I go one step further and state web development is far more complex than traditional n tier thick client development - 1) Most web applications are truly 5 tier applications tier 1 - User Interface - HTML , javascript, CSS , XML (page driven) or Ajax ( state driven) Tier 2 - Presentation interface - decides remotely the right html etc or state. Tier 3 - application logic Tier 4 -data access interface ( ORM type stuff) Tier 5 -- the data layer 2) Most web development effort must build presentation layers that communicate with a client over a protocol that wasn't intended to be robust. 3) QoS work is far more complex with the web. IP sprayer , web farms , etc 4) security considerations -- DDOS , SQL injection - would love to see traditional apps that address SQL injection :). Not to mention PKI , digital signatures , SSL , the most secure traditional app didn't require asymmetric cryptography because there was always an 'out of band' key exchange. For independence from the major desk top vendor , web development has become the most complex beast ... while Netscape is dead it's vision has sure tripled complexity...

Jaqui
Jaqui

"As we head towards the point of inflection between client/servers applications and Web applications" Look at it realistically, any dynamic website is, and always has been, a client / server application. The client software is a web browser instead of a purpose built gui. The data processing to give the client the data needed is all server work. A common web app, a discussion form is a client/server/server app. The browser and (x)html/javascript/flash/activex + css code creating the UI, the web server and server side code processing what needs to be done, and sending it on to a second server, the data base engine, where the real work is done, then the db engine ends the results back to the webever, which formats it into the ui code and sends it back to the client. The early guestbooks on static html websites were the beginning of the web as a true client/server environment.

jseller
jseller

Isn't this much like saying that Automobile Engineers should take Mechanics seriously? Of course, they should, as it's in each parties best intersts to do so. Both work on the same technology, just on a different level; so both parties need each other to succeed. Software is so new that these lines aren't as well defined as established technologies, but it exists; as does the third level, the 'hobbyist'. They deserve respect for just being interested at all. "Web Developer", "Network-aware Programming"; whatever you want to call it, we are all web developers now.

rclark
rclark

The infusion of so many that use MS Office/FrontPage as a web development IDE and call themselves WebDesigners has me a little leary of taking that title at face value. My 11 year old does this for her homework and produces web pages. But I would not call her a developer. But if they can use data access, and actually have a clue about client/server, I'm willing to look at their work. I don't make distinctions between Classic and DotNet ASP. Programming is programming, even if you use gwbasic. One of the most critical programs I've done in the last few years was a gwbasic interpreter for a chemistry analyzer result stream. I didn't choose the language, the interface hardware dictated it. So I'm agnostic on languages, and mostly on platforms. The test in my book is does the application work, does it fulfill the need, is it maintainable, and can you reproduce the result on the next project. At that point, you evaluate the work produced against the cost of the employee and make an employment decision.

jreddy
jreddy

"I think this attitude comes from the way many Web applications are architected." I guess you could say I am a traditional 10 year plus business-object-oriented developer. I think (what you call) a traditionalist will build an application and stick a web front end on it. A "web developer" will build a web application, period and continue to not get much respect.

mattohare
mattohare

I was in the last wave of this transition. The application cusmtomiser. A lot of IT shops would not consider people that used MS-Office VBA, or Visual Basic in general, to be 'real developers.' Many of us did some of our formal training in regular computer science classes. (I took Pascal in my Intro to Computing.) The rest of it we would top-up with reading the texts. Where the lack of classroom/lecture assistance would hurt, our hands-on would help. I think with each new wave of developer, the old school equate new wave/old wave with no skill/high skill. Each new wave of development does add something to the mix. Anyone remember how OOP developers were slagged off?

Tony Hopkinson
Tony Hopkinson

Simply compiling javascript only removes the overhead of interpreting each time it's executed. As for compiling a statically typed language to javascript, that would be a translation and an inherrently problematic one at that. Leaving aside all the compile time type checking you get from a statically typed language, the way you write code in differently typed langauges is different and any translation between the two would have to be an interpretation, i.e. a guess. The differences between Int anumber = Int32.Parse(astring) * 32 and int anumber = astring * 32 and anumber = astring * 32 are huge. Not saying wrong or write, better or worse, but not easily coped with on a one for one translation basis.

Tony Hopkinson
Tony Hopkinson

web devs and windows devs, no such thing. You are either a dev or your not. Not's abound in nearly all environments where high level tools are available. The tools might have been developed to improve the productivity of trained devs, but now they've been used in a cheap ass , misguided attempt to replace them. There are a lot of tools for web based development, because they are easier tow write. Not really a windows thing either, a lot of the truly terrible stuff is PHP on linux boxes.

Absolutely
Absolutely

[i]Nah, traditionalist vs cookie cutter, solution provider, MBA who once did a macro is the real split.[/i] I agree, from my programming experience, but don't you also see the perception that web developer == FrontPage user, "cookie cutter, solution provider, MBA who once did a macro." among HR personnel, and other MBA's? The Dot-Com bust was an unprecedented orgy of speculative investment since the Great Depression. Don't try to tell me that after that, "web developer" doesn't carry the same stigma as "plastics guy" in Capra's [i]It's a Wonderful Life[/i]. http://www.imdb.com/title/tt0038650/

IT.Consultant
IT.Consultant

I wholeheartedly agree, but would like to add a few more points! Web application development is a specialized type of application development that targets one medium: Web. But, the Web is far more flexible than the desktop, as it gives much of the choice and control that traditional developers enjoy over to the users. 1) In general, public Web applications will not restrict who may view or use them. Even some private Web applications may need to support many browsers. Therefore, developers may need to understand their target market / intended audience, and only implement interfaces (e.g. layout, features) that suit them. 2) Differences in the performance of Internet connections and clients force application developers to balance competing concerns such as scalability, usability and security. 3) Because the Web is asynchronous, application developers need to worry more about thread safety, especially with Web services and singleton classes. And I think that the marketplace is definitely noticing the difference. I would go so far as to say that Web application developers who can't or don't develop "traditionally" are really just Web designers and will find it increasingly difficult to get application development jobs.

jreddy
jreddy

What you described is a typical application with a web front end. Developers developing software like you described will always get respect. However, a large, very very large, number of web developers create single-tier applications where recordsets or resultsets are returned to code that loops through them and displays data. Input that gets wrap up in SQL statements in the same one layer of code and stored in a database. A separation of concerns is thrown out the window. A mistake might be to assume that all web development is being done like I described here. However, for a long time is seems like it was. I think enough "traditional" developers have gotten into web development and hopefully have slowed down that sad trend.

Justin James
Justin James

All great points. A client/server app, particularly one using native code and network protocols designed for RPC type stuff, is a heck of a lot easier to write in many areas than trying to replicate things like statefullness, RPC, and so on over HTTP. Even when using an application server or framework, it is often required to understand the low-level internal behavior to make the application work right. And for things in which concurrency issues (like double clicking "Submit") can cause problems, it is a LOT easier to prevent that from happening in a native application. The very fact that the entire Web application presentation layer is written in a declaritive way subject to the client's interpretation causes problems! J.Ja

Justin James
Justin James

Jaqui - Anything capable of I/O over a network wire could be considered to be "client/server" by the way you've presented it. But in comon usage, there is a fairly well understood (if loose and imprecise) definition of it. Static HTML posting back to a server definitely does not cut it. AJAX-y type sites or Flash come a lot closer. A "client/server" application specifically uses code and logic running on the client, as opposed to the interpretation of a document for display. In other words, I can't tell you what it is, but I know it when I see it. :) J.Ja

Justin James
Justin James

Your analogy is flawed. To even call them "different levels" is to denigrate one or the other (you haven't specified which is which). Web developers and traditional developers are laterally seperated, not vertically seperated as you imply, and *neither* are anywhere near the "hobbyist" level. A much better analogy would be comparing a municipal police officer and a county sherriff. J.Ja

kehill50
kehill50

I just refuse to comment on this one. But I will... I wish there were "IDEs" which allowed me to gracefully "build" my C-Programming Language application code. Oh yeah, I sure would like an Automated Test Environment where I did not have to do such tasks as build my code, check the Makefiles, find unresolved symbols, change permissions, load my data, run my test on the development machine to watch it die horribly. Oh yeah.....Segmentation Fault....whats up with that....??? Also, runing sequential debugs, looking at the logfiles for hope of a clue to why my application died. Figuring it out why the "printf" did not. I know, I,ll just "Download" a pluging from the Web. No need to use the Books and Manuals on my desk. Oh Geez, thats right, We have Websense on our network....Software Downloads are not Authorized... Here is my point. Web development is cool, hipsy and artsy fartsy and intense. It covers network layers protocols EI-ei-O. Yeah, a 11 year old can do it. As well as someone who does it at the Enterprise level. But you have to understand the "traditionalist" mindset. If my application just died, and the world as we know it is coming to an end, I personally would go break the Glass on the "Gandalf Chamber", get the old UNIX Guru's and Assembler guys, and offer up sacrifices, while they automagically made the Universe a safer place. In my experience, I have never known the "web-guys" to get the 2:00am call on Friday night about an application that has died, or even show up in the lab while the rest of us were doing the "Walk of the Dead". Now, before the "non-traditionalists" go all gaa-gaa I am NOT downgrading the Web folks, again I admire the stuff they do. I wish I had all those "neat gizmos" they use to do what they do.But I guess thats why I like being a "traditionalist" of sorts, the pain and suffering factor always makes for an interesting conversation, especially at 3:00 in the morning....:-) But I think we may be falling in to the "Apples" vs "Oranges" thing again. We are the same but very different. Again, I have no ill will towards our Web Brethern....can someone tell me why this "*!@$%%!???@" Sementation Fault won't go away......????? Later....

dtec
dtec

Now if only your thought process can propagate through the minds of other managers making the hiring decisions, we would all be a lot better off.

Justin James
Justin James

"I think (what you call) a traditionalist will build an application and stick a web front end on it. A "web developer" will build a web application, period and continue to not get much respect." I was thinking more in terms of the was a lot of "Web applications" are a bunch of unrelated (within the code) pieces of code that all call common libraries and write to a common data store like a SQL server or a session system provided by the application server. This is the typical "page view model" and while it closely relates to the HTTP protocol and the HTML document specification, if I wrote a desktop or client/server application like this, I would be laughed at. Imagine writing a seperate DLL for each button instance on the screen; no one would keep you employed. You are right though, what I've seen is that "traditionalists" get the backend nailed down really well, as you say, they build an application, put API hooks of some variety on it, and then lay a Web front end on top of that application using those hooks. More and more Web developers are doing similar things with the N-tiered architecture, using XML and Web services as the API, so "Web applications" finally look like an "application" from the architecture standpoint, not a collection of code files. J.Ja

groon
groon

... that still doesn't make "architected" a word. I find I get more respect when I use plain English rather than jargon. "Built" or "written", even "constructed" would be fine here. "Architected" makes as little sense as "carpentered" or "teachered".

Justin James
Justin James

You're right, I remember that perception as well. A few years ago I was doing that, and it was very difficult to show people that working with MS Office & VBA was just as hard as any other kind of development. It's like being a coach for a Pee Wee league football team, sure they may not play with high levels of skill, but just try to get 5 year old kids to even understand the rules, it is just as hard as coaching a pro team. VBA and other app customization schemes may not be as full featured as C++, but just try working with collections that do not support an "Exists()" method... J.Ja

Tony Hopkinson
Tony Hopkinson

is a very valuable skill, it would be nice to see more of it going on. It's not application development though, any more than UI specialist is. It's not unknown for a designer to come up with something that would be impossible or at least impractical to achieve, almost as often an application devloper comes up with something that looks and feels awful. It's people confusing the two skill domains that cause a real problem.

Justin James
Justin James

You said in 2 sentences what took me probably around 1,000 words to say. :) Yes, "Web development" originally was exclusively like that, and still is much of the time (what I call "dynamic Web sites", seperate from a "Web application") which is where the bad rep comes from. Unfortunately, that bad rep still taints the "Web developer" job title, and improperly sets off red flags for certainly people. For example, my mother hated "The Hobbit", and as a result, she refuses to read any book in the "fantasy" genre, regardless of how unlike "The Hobbit" it may be. Another (probably bad) analogy. :) J.Ja Edit: added a bit more

Jaqui
Jaqui

for web apps, any clientside processing needs to be redone on the server side, to protect the server from exploitation. So the traditional definition for client/server needs to alter to remove the client side processing from it as a requirement. I'm not arguing against the idea that web apps are the wave of the future, but your "Anything capable of I/O over a network wire could be considered to be client/server" sounds like a better definition for client/server because of the trend that spawned the blog post. It's a more "basic" ( sic ) definition.

jseller
jseller

There is nothing wrong with being at a 'different' level. I like to work on my car on the weekend; in the car world, I'm a hobbyist. What's wrong with that? I don't feel denigrated. Someone who only uses software but likes to keep up with industry is a hobbyist as well. Again, there is nothing wrong with that. Any technology has the hobbyists, the trademen and technicians, and the professionals. This isn't a class structure; people just end up having different levels of involvement.

Justin James
Justin James

That was mostly pretty funny, and I feel your pain. I have to take exception to part of it, though: "In my experience, I have never known the "web-guys" to get the 2:00am call on Friday night about an application that has died, or even show up in the lab while the rest of us were doing the "Walk of the Dead"." Many Web folks get this, and some get it a LOT. Remember, the Web introduced a much wider audience (and group of developers) to "24/7 computing" and the need to start counting the number of nines in their uptime. I know plenty of Web developers who get the 2 AM call. J.Ja

Justin James
Justin James

Yeah, there ARE a lot of people running around calling themselves "Web developers" when really they are "people who can install WordPress, install a different, free theme, and type content in", or "people who can use DreamWeaver". That is one reason why I've been such a hardcase about resumes, and ended up interviewing (at least phone interviews) a relatively high portion of people, to find out if "designed and developed custom Web pages" means "Web developer" or "FrontPage user". J.Ja

Justin James
Justin James

Microsoft Word is more than happy to take the word "architected", but strangely enough, no definition. In fact, I cannot find a dictionary definition for "architected" anywhere. That being said, this isn't some bizarre usage of a common word or even "jargon". In the software industry, there is a very specific difference between "architecting" software and "building", "writing" and "constructing" software. "Architecting" software is what happens BEFORE all of that; it is creating the "architecture", the overall design and blueprint of the solution. That is hardly "jargon", it is a word (and usage) that I hear and read all of the time. Even giving all of that, the verbification of nouns is an honored tradition within the development community (http://www.catb.org/~esr/jargon/html/overgeneralization.html). In fact, the word "verbification" is a selfreferencing example. :) J.Ja J.Ja

SnoopDougEDoug
SnoopDougEDoug

Dude, I think I understand the point you are trying to make, but your argument is woefully weak. Spending an afternoon a week working with children is vastly less difficult than 80 hour weeks for 10 months of the year. Please don't use this lame analogy to bolster your argument. I would put anyone into a developer slot provided they: Use source control Write their own unit tests Document their code Use naming conventions I'm sure there are other criteria, but these typically separate the dilettantes from the professionals, regardless of the platform or language. doug

Absolutely
Absolutely

I agree, Justin, the word "level" seemed goofy to me. I guess I might have just learned the nomenclature from a weirdo, but the jargon I use to describe these types of parts of an application is "presentation layer" = web GUI, "application layer" = processing of users' intentions to SQL, and database layer is SQL [& friends]. "Layer" is understood as neutral to both web developers & real programmers [kidding!] to refer to different parts of a project involving 2+ languages, 1+ for the user and 1+ for the server, and is typically used in [b]exactly[/b] the same context as what's-his-name used "levels." I don't see what that term adds, and I had the same reaction, because there is already a more common term for that, which does not have hierarchical implications.

Justin James
Justin James

... sure made it sound like you meant a class structure, like Web developers were the kid brothers of "real developers" or something. this was the sentence that primarily raised my ire: "Both work on the same technology, just on a different level; so both parties need each other to succeed." App developers and Web developers *don't* work with the same technology on a different level. They work on the same technology at the same level for much of the work, and different technology at the same level for the rest of their work. That's the entire point of my post. :) J.Ja

kehill50
kehill50

I can understand your exception. However, I try to bring a little levity on interesting, and at times, controvserial issues. . . . . . . . . . . . . . . . * * * . . . . . . K . . . . . . . . . . . K . . . . . . . * . . . . * . . . . . . . . . * . E . . . . . . . . . @ . . . . . . . . YOU ARE CLOAKED... STARBASE SHEILDS PROTECTING ENTERPRISE... MR.SCOTT:Captain, I CANNOT LOWER THE SHIELDS, 404-Error, WEB PAGE NOT FOUND...

groon
groon

The title of the blog piece was "Why traditionalists should take Web developers seriously". There are plenty of "honored traditions" within the development community which are obstacles to taking them seriously. If you have to explain to me what your word means, you're using the wrong word.

Tony Hopkinson
Tony Hopkinson

and say that a 'real' developer is one who understands how constraints affect implementation and the impact design compromises have on robustness, performance and extensibility. We'll all make choices other's think are 'erm ill-advised :D , but the real key is understanding there was a choice and why the hell you made it.

Justin James
Justin James

Yeah, I should have been a bit clearer with that analogy... maybe even skipped it. It was actually a last minute replacement for a much more accurate one, but the more accurate one involved religion, so it is off limits. I think that two of your criteria are not all inapplicable for a large portion of people out there who are most certainly developers. Those "application customizers" are a great example. You can't do unit tests (as far as I know) on VBA script within a Word document, but I can tell you from personal experience that it is indeed development work. Much "real code" out there is COMPLETELY indeterministic, rendering unit testing extremely difficult, if not impossible. On top of that, unit testing as a widely supported technique, integrated into the toolsets and such is fairly new. Many developers do not have access to unit testing tools on their platforms/languages depending on the toolsets that their employer purchased. In fact, it could be even further argued (by some) that unit testing in and of itself is in the realm of the QA team, not the development team. That is a matter of organizational culture though. Finally, some developers work on "short order chef" type projects, in which unit testing simply is not justifiable. I had a job for about 18 months in which the longest project I worked on, from the time we had the initial "what are your needs?" conversation to "we're live!" was 3 weeks. It was extremely rare to see a codebase larger than 500 SLOC for the projects, unit testing was simply not appropriate. But it definitely was "development" and we certainly were professional about it. I am not arguing against unit testing by any means. But I am saying that I would not say that someone is not a "professional" just because they don't do it. I would need to know the circumstances. Source control is the sign of a professional development shop, not a professional developer. Many real, professional developers do not work in shops where version control is more than a directory tree with stuff like "2008_1_24_backup" in it. In fact, over the course of my career, about 50% of the places I have worked at did not have version control. They all talked about putting it in place, but they weren't using it. It's sad, and it's a great measure of a good shop, but it is simply outside of the individual developer's control. I agree that code documentation of some variety, whether it be truly self-documenting code, code comments, a user manual, an API guide, or whatever is appropriate to the situation is a great criteria to seperate the "shake 'n bakers" from the pros. Ditto for the use of naming conventions. J.Ja

Editor's Picks