I didn't expect many people to agree with me on the issue of
web application development walking the plank.
Why?
For one, if I'm right, it's something which no one wants to hear. Further, if what I said is correct, and it's a novel concept, most people will not yet be of that opinion. Backlash would occur naturally. On top of that, there's always the possibility that what I said is completely asinine.
Despite my expectations of imminent flaming, however, the people who responded raised some excellent points, which I'd like to address here, taking the opportunity they presented to clarify my initial thoughts.
First, it would be helpful to answer the question, "what do I mean when I say 'mostly fairly trivial?'"
Mostly: Most web applications.
Fairly: For each web application included in "mostly," it is trivial
to a reasonable degree.
Put together, I would say "most parts of of most web applications are trivial."
I must have spent too much effort putting the focus on application generation, because by far, the biggest objections were there:
Barry Whitley noted,
The be-all end-all self building framework/generator has been the holy grail of software development since its inception, and it isn't really much closer to achieving that now than it was 20 years ago.
Along those same lines,
Mike Rankin brought up CASE tools:
Anybody remember CASE (Computer Aided Software Engineering)? It was sold as the end of software development. To build an application, a layperson would just drag and drop computer generated components onto a "whiteboard" and connect them up by drawing lines. CASE was THE buzzword in the late eighties. 20 years later, it's nowhere to be found.
Software development will become a complete commodity the moment business decides to stop using their systems as a way to gain a competitive advantage.
To be clear, although I believe
some applications can be entirely generated, I don't pretend that anywhere near most of them can. However, I do think that most parts of most web applications fall into that category.
Getting back to programming-by-wizard, at one point (very early) in (what you might call) my career, I programmed in
G. This consisted mostly of connecting icons in what amounted to creating ridiculously complex flowcharts.
I think that's close to what many people envision as the "programmer killer" when they hear someone saying there will be one. But having used that style for a couple of months, I can issue my assurances that won't be it.
In fact,
as Mike said, since competitive advantage dictates businesses will continue innovating processes that will need to be codified in software, it's guaranteed there will always be software to write.
It's not a question of whether there will be software to write - it's a question of how much of it is there to go around for how many programmers, what skill-level those programmers need to be at, and what those applications will look like and run on.
Whereas a decade ago a team of programmers might have built an application over several months, we're at a point now where a single programmer can build applications of similar scope in days to weeks. We've even got time to add all the bells and whistles nowadays.
Within
an application, we need fewer programmers than we did in the past. To stay employed, you need to learn how to use the tools that abstract the accidental complexity away, in addition to learning new types of things to do.
Barry puts it well:
As for the skills required, I'd actually argue that the workplace is demanding people with MORE skills than ever before. There is a lot of crap work for sure, and that market is dying out. For companies that want to be serious players, though, the demands are higher than they've ever been.
Indeed. That's what I'm talking about.
The repetitive tedious stuff is going to be generated and outsourced. But there are shitloads of people still doing the tedious stuff. And there are shitloads of capable programmers who can glue the rest of it together.
We don't even need to get into the discussion of what will supplant the web and the number of jobs that will need to move around. The marketplace won't support us all at our high salaries. To be around in the future, you're going to need to do a better job of coping with change than the mainframe and green-screen programmers who
won't find a job now. You're going to need to be capable of picking up new technologies, and the knowing the principles behind them will help you do it. Knowing how to build and design complex systems to solve complex problems is where you'll need to be. This is in contrast to being given specs and translating them into the newest fad-language. That's what professor Dewar was getting at, and that's what I'm getting at.
I don't expect most of the readers here will need to worry. Not because of anything I've done, necessarily, but because it seems like most of you embrace change.
I'm just sayin', that's all.
Any other thoughts? I'd love to hear them.
Hey! Why don't you make your life easier and subscribe to the full post
or short blurb RSS feed? I'm so confident you'll love my smelly pasta plate
wisdom that I'm offering a no-strings-attached, lifetime money back guarantee!
Leave a comment
Sam, if you smoked stogies, or drank Scotch, and we were in the same town, maybe at the same conference, I'd buy all night just for using that diagram in your post. An instant classic, for folk of my (our?) generation.
To your point, I find myself lately WANTing the tedious development to be outsourced. I spend most of my time on the backend, and while i enjoy the front-end work, particularly the new whizbang stuff, I get so bored so quickly solving the same old problems. Mike and I worked together for a while, and I bet he feels the same way I do!
Often, though -- and maybe this is exclusive to where I work but I doubt it -- I find that the reason they keep the work in house instead of outsourcing it doesn't have much to do with the work as described at the beginning of any project. It's with how that work morphs through multiple iterations with the client. Call it scope creep. Call it requirements refining. Call it clients bending you over to see what they can get out of you for free. Call it simply clients discovering what they want. I don't know what it is. But it seems that even in some of the simpler things I observe in my company, our value isn't in the nuts and bolts, it's in the ability to continually adapt to the changes. Adaptation, unlike mere technical skill (put this form field here, save to this db table), requires something different. Maybe it's proximity, or strong teamwork, or strong leaders, or all of that. Whatever "it" is, it ain't so easily outsourced.
As always, great post!
Posted by
marc esher
on Aug 04, 2008 at 08:45 PM UTC - 6 hrs
@Marc,
You're right - it isn't easily outsourced which is where the problems with outsourcing come in. They assume you can find out requirements, throw them over the wall to programmers and get back the app you need. In practice this doesn't work.
However, while it isn't easily outsurcable, it is fairly straightforward to raise the level of abstraction and generate or interpret model driven code for the majority of the functionality (and the majority of the changes) for most web apps. I actually sat down to write a web app by hand the other day and pretty much gave up after a morning realizing that it'd take days and days to write any non-trivial app. I'm used to generating most everything in a morning and then just filling in the aps in a couple of days at the end, and anyone who is writing repetitive code by hand - crud queries, list methods in service classes, admin screens, form processors - is not going to get paid to do that forever.
Posted by
Peter Bell
on Aug 05, 2008 at 09:29 AM UTC - 6 hrs
@Marc - Thanks! I was looking for a flowchart and just happened to find that one from
http://xkcd.com, which is often brilliant but like you - an instant classic is what I thought of for my generation.
I think you (and Peter) are right (at least for a lot of people's situations).
However, I know people who are actively working around that. The adaptation isn't there for 3rd party customers, but it seems to work fine (at least, that's what I was told) for working in the business IT department. Also, for larger applications where you can work around the customer, it may not even be noticeable.
I wish I could recall the specifics of the conversation, but the general idea is what stuck with me. He was a business guy, from Shell if I recall correctly. The other part is personal experience.
In any case, I don't have any hard data to offer as evidence, only trends of things I hear and experience.
From what I can tell, a lot of programmers are doing CRUD apps manually, and people telling them that ORM is slow only reinforces the reasoning they feel about why they use it. They're probably only developing for one stack (which isn't horrible, except in combination with all of the other flaws).
I don't know if they're people who can be reached. Certainly relatively few of them I would expect read blogs. Even fewer would read this one =). But there's enough of them out there, maybe someone read this and thought "you know, I do stuff like that. I better get on the ball and learn something new."
I know at least one programmer who got stuck in his ways, and ended up rotting (not just professionally) because of it. Went the way of the dinosaur as far as career prospects - a Cobolasaurus if you will. Young enough to not be able to retire, but old enough not to keep up with everything, I guess.
Posted by
Sammy Larbi
on Aug 05, 2008 at 03:47 PM UTC - 6 hrs
Great post! I just stumbled upon your blog but I'll definitely be checking back more often :o) I agree with you completely. I am just starting out in my career and feel that in order to be able to continue doing what I love I will have to keep my fingers in as many things as I can. I can't put blinders on and put all of my energy in to learning about whichever technology my boss happened to read about in some magazine on an airplane. I don't write mission critical software... eventually that airplane magazine is going to mention a technology that can replace ME and I need to be able to combat that.
I get so frustrated when I try talking to my colleagues about technologies outside the scope of our 9 - 5 job and they have absolutely no interest. Frequently I tell my colleagues about things I'm trying to learn and I hear "Why? We're not going to use that here."
Posted by Tina
on Aug 06, 2008 at 09:07 AM UTC - 6 hrs
@Tina, I understand the frustration. You might want to think of it as an opportunity though - the less they learn, the easier it is for you to become the smartest person in the room.
That said, a good rule of thumb for learning something is to be the dumbest person in a room full of really smart people. You might want to consider keeping your eye out for companies that have an exceptional team and may want to bring you on and train you up. Generally (though not universally) the best teams will also be committed to test first, continuous integration, agile style methodologies and some or all of the XP engineering practices such as pairing. Generally though if a good chunk of the team present at conferences and the rest at least attend, it's probably a team worth joining and for finding such positions, programming conferences are usually a great starting point - even if your employer won't pay for them. I'm a fan of ooPSLA (in Nashville this October) and have heard great things about JAOO, QCon and the No Fluff Just Stuff conferences.
Posted by
Peter Bell
on Aug 06, 2008 at 09:13 AM UTC - 6 hrs
@Peter, I agree with the "be the dumbest person in a room full of really smart people" sentiment. I don't ever want to be the smartest person in the room. I think ideally I would be somewhere in the middle... I want to be knowledgeable about SOMETHING so I can contribute fairly to my team and teach the people around me but I'd like to also be around people who are willing/able to share their knowledge with me.
Thank you so much for the advice and conference suggestions! I appreciate getting tips from someone so involved in/important to the CF community. I agree that conferences are great resources... I've been to a couple and always come home with a laundry list of things I'd like to learn about. Being around smart, passionate developers is so motivating. It looks like No Fluff Just Stuff posts podcasts of some of their lectures... I'll definitely download those.
Posted by Tina
on Aug 06, 2008 at 10:01 AM UTC - 6 hrs
@Tina, Great. And if you're a CF developer (I'm never sure with Sam's blog - he has a varied readership), cf_objective() is still the best conference, although CF United is great and is the biggest.
Posted by
Peter Bell
on Aug 06, 2008 at 10:12 AM UTC - 6 hrs
@Tina - Thanks for taking the time to leave a comment. I'm lucky enough to be on a team that understands the importance of being broad and deep in our skills, so while not everyone is learning new stuff *all* the time (we have to work too!), we at least can chat about new things we're learning, and how we might be able to apply them to our current projects, or future ones.
I'm also lucky enough to be on a(nother) team where I'm certainly one of the dumbest people in the room. I'm learning a lot, and learning fast.
As for the conferences, I can definitely vouch for NFJS - great all around experience, and great presentations from a lot of great minds. Although the conference in Java based, the speakers are always into languages, platforms, and paradigms.
Hope you'll stick around.
@Peter (and Tina) - Don't forget the value in being the smartest person in the room as well! When people come to you for advice, you get to vet and cement knowledge you have, keep yourself sharp, and learn new things that people ask you about for which you have no answer yet!
Posted by
Sammy Larbi
on Aug 06, 2008 at 04:10 PM UTC - 6 hrs
