(I wrote this in 2011 as a draft and then forgot about it. It still reads OK, so here it is, basically unchanged, and without the extra sections I’d probably originally planned to add.)
Even though big web sites use lots of so-called “enterprise” technology, and big companies and government departments create browser-based applications, there’s still a huge chasm between web developers and enterprise developers.
We’ve been flooded with clichés and stereotypes about both sides — enterprise developers do everything the hard way, web developers don’t understand security and reliability, etc. — but it’s best not to take that too seriously. A lot of my consulting work and personal projects straddle the line between Enterprise and Web, so I’ve had a decade and a half to observe people and processes on both sides.
I’ll post more about this later, but here are two differences that strike me right away:
- Enterprise does a lot of integration
- Enterprise doesn’t have many rock stars
Enterprise does a lot of integration
Enterprise IT projects are always about integration. We’re not talking about fun integration with a REST API on the web, but nasty, ugly integration with legacy systems as old as your parents, using custom data formats and unpronounceable character encodings out of the Mad Men era, like EBCDIC (if you’re lucky).
In web dev, whether you’re using SQL or a noSQL approach, you almost certainly own and manage your application’s data (unless you’re building one of those doomed Twitter or Facebook mashups). In an enterprise project, most of your data is coming from somewhere else (the 1970s mainframe at the Oakland data centre, the 1995 PowerBuilder app used by 350 analysts in Hong Kong, etc.). It comes veeeeery slooooowly, and it’s unreliable, and it’s almost guaranteed to be out of sync with the data you’re receiving from other sources (so forget about strict referential integrity). There’s nothing you can do about that, because huge parts of the enterprise are based around those legacy systems, and there’s no one left alive who knows how to change them anyway. Your whole $50M system might depend on data sent as a CSV email attachment every Tuesday night, and rejected 55% of the time because it’s malformed.
There’s a lot of snake oil out there that promises to “fix” this problem — ESB products, ETL products, WS-* products, etc. — but these all address the easy parts, near the middle, not the hard parts, at the edges (and sometimes they make even the middle more difficult than it needs to be).
The benefit of all this mess, though, is that an enterprise application designer is always thinking about distributed data, something that web developers talk about don’t always really get. It’s hard to imagine a CMS like Drupal or WordPress — that naively assumes it can keep all the information that it presents in its own (preferably MySQL) database — coming out of the enterprise.
Enterprise doesn’t have many rock stars
Really, it’s true. Developers working for government, or Fortune 500 companies, on average, aren’t very good. Of course, there must be some real talent hiding here and there, but on balance, coding for most enterprise employees (as opposed to outside contractors) is a 9–5 drudge job that they’re happy to leave at the end of the day. They’re nice people, but they’re not passionate about IT the way you and I are, and they’re not interested in becoming so.
This talent deficit has pretty serious implications for building projects in-house and for maintaining projects from any source — it means that enterprises micro-manage their developers in a way that a hotshot web developer would never tolerate. Part of that is just the overhead of working in a big team — even web companies do code reviews and write detailed requirements when they get big enough — but a lot of it is just a matter of not trusting developers to do the right thing on their own. There are huge numbers of tools out there to count, manage, audit, poke, prod, and otherwise abuse enterprise developers, and those tools are more widely-available in Java than in any other environment, hence the enterprise’s love of Java.
It’s hard to know where the fault is here: would good developers work for enterprise if the working conditions were better, or would they still run off to small startups or consulting for the variety and adrenaline rush? Would bad enterprise developers grow into average or even good ones if they were given more trust and autonomy? In any case, if you’re designing an application for enterprise, don’t expect things that seem trivially simple to you to seem simple to the developers.
The result of all this is that, even if you have a hotshot team of consultants and developers initially building an enterprise system, you have to design it so that mediocre technicians and developers can maintain it for the 10-30 years after you all leave. The enterprise has to be able to hire people with (generally useless) certifications as “Sharepoint specialist,” “Oracle DBA”, or whatever, and the system has to contain few surprises for them. Nothing cutting-edge, please, because they probably didn’t cover it in their certification courses.
Quoderat 
Oh. When I saw the headline in Feedly I thought this was about Star Trek. Oops.
Anyway, some of us passionate enthusiasts do work for enterprises, usually in small niches as I do now. Sometimes it’s good to be the beard (or belong to the little department of beards). My detour through Google, which feels much more enterprise on the inside than it portrays itself as, was a costly mistake.
Agreed, John. The greybeards (literal or figurative) are an important exception: consider not just yourself, but people like James Gosling at Sun, Brian Kernighan at Bell Labs, or Charles Goldfarb at IBM. Unfortunately, the greybeards rarely have big roles in major operational IT projects.
Pingback: 10 Tech Stories To Read This Week – May 21 Edition | iRomin
Heh, nice.
I heard someone say that enterprise software sucks because they use consultants a lot and they only care about getting the job done, not about maintaining the software afterwards.
One thing I found is that there can be sooooo much friking code required that there’s no budget left for quality. Literally, a handful of developers need to write mountains of code, so productive sustainability in this environment means mediocre quality – good enough to be (at least in part) sustainable.
A consumer web page might have a single input field with two buttons, “Search” and “I feel lucky”, from which they build a several hundred billion dollar business.
An enterprise site on the other hand has 100 pages with 5 grids each, complex business rules and the users prefer using codes for things rather than human-readable descriptions. Enterprise developers run the fine line of being flexible enough to meet all the needs of the complex business and having so much metadata the thing’s a set-up nightmare. Not sure if that’s a fine line or a big yawning pit of despair.
Jason wrote “Not sure if that’s a fine line or a big yawning pit of despair.”
Yes, that’s about it. It would be interesting to see if the enterprise could break itself down into a collection of simple, interoperable, single-purpose apps equivalent to Google search (which you mention) or Twitter. The challenge, I think, is that there would be so many of those apps that the coordination overhead would swamp the individual component savings.
The other problem is that you sometimes have unwilling users in the enterprise — on the web, almost no one starts using Twitter (for example) unless she wants to use Twitter, so a new user is generally willing to train herself through trial-and-error and to seek out help from peers. In the enterprise, on the other hand, users are often unwilling or even hostile, so they will use any new software as a tool for obstruction unless you swamp them with training, documentation, helpdesk support, etc.
Hello, David!
About that enterprise components thing, I don’t really see that coming — I think that’s the type of reuse-in-the-large that is talked about in that neat little book “Facts and Fallacies of Software Engineering”: they are too damn hard to do properly!
Domain specific languages are a better bet, this idea it is slowingly getting more acceptance in the enterprise.
This would be very interesting to see. I like to imagine that some newer ‘enterprise’ operations such as Google are like this on the inside. A sparse set of services with well defined API’s for interaction.
I think the challenge is the mind set in the enterprise which I’ve found to be more about synchronisation of duplicated data rather than querying over duplication.
Also cost. I guess a lot of companies are focused on their business, and will put into IT resources based on the short term gain in efficiencies, not that extra cost for a gain in long term scalability or maintainability.
I take offence at this load of opinion and generalisation. I am an enterprise developer and I dare say I probably know more about IT than you could dream of learning. I am passionate about software development. My day to day job is working with Java and various middle wares, but I am also proficient in low level C, C++ firmware development (I am an expert in USB protocols), Python, Groovy, C#, Javascript.
Developers like you, Emert, are the reason that enterprise limps along at all. Do you work for an exceptional enterprise that attracts and keeps a lot of good talent, or do you find that you have to carry/cover for a lot of your co-workers?
I am a mediocre enterprise developer and I agree with all of what you say here. Halfway through I was planning to forward it to my team, but it then it devolved into unnecessary condescension that neuters the message, at least for half of the audience. This seems more of an “ain’t we great” message for frustrated wunderkinds feeling unfairly stuck in an enterprise environment. There are valid reasons why enterprise development focuses more on supportability than rock-star innovations, and it isn’t because enterprise developers lack passion or intellect . . . we just have to temper our egos enough to adapt to the legacy environments and avoid cutting-edge technologies that might fall flat in two years.
Agree with Karl here — you make an excellent ,well-written point, but that point is potentially marred by the time you get to the end.
There are absolutely “clock puncher” developers and systems adminsitrators that are not interested in cutting-edge tech, but perhaps that’s because they’ve witnessed the hot-then-not nature of such things, or their personal fulfillment isn’t measured by how terse their code is.
Something external consultants working on enterprise projects should absolutely consider is that what is trending today will often “carbon date” a solution. Today’s Flat-UI will appear “chunky and old” within a few years… and saying “a few years” for a given version of any enterprise project is often drastically underestimating the time that version of a project will be used by the employees of said enterprise.
I would encourage all consulting developers and systems administrators to look to the individual skillset and capabilities of the employees of the given enterprise, and adjust your tactic according to what best fits the in-house dynamic. It’s *our* job to give the customer a solution that will work long-term in that specific enterprise. Code/architecture readability, simplistic design, and standards will beat out l33t h4x0r-ing any day, and will ultimately lead to a happier customer.
Could you be any more condescending than “They’re nice people, but they’re not passionate about IT the way you and I are, and they’re not interested in becoming so.” if you tried? Well, at least we’re nice. It’s too bad we could not possibly be as passionate about our craft as you and the rest of your non-enterprise readers are. Alas.
I wonder, what position in the enterprise sector do you hold that you have such clear and final vision of all enterprise developers?
For those in enterprise IT whining about lack of respect and understanding of your challenges, the reality is enterprise IT doesn’t have many happy customers. I have been in consulting, start-ups, and enterprise. If you are in the first two and don’t have happy customers, you go out of business; but in the enterprise everyone picks up a check even if the results are less than mediocre. After all, the business guys aren’t always trying to bring in outside solutions and consultants because they believe they have a crackerjack team of developers in house that can reliably deliver great results.
Karl Minor wrote ” it devolved into unnecessary condescension that neuters the message”
I think you’re right, Karl — if I were writing this from scratch now, I’d probably phrase the second part a lot differently. It’s not that there aren’t talented people in enterprise, so much as that enterprise (perhaps unconsciously) hates talent, because talent is hard to control. It wants software developers to be interchangeable pieces, like computer boards, that you can buy according to spec on a pre-ordained salary scale and replace whenever you need to: “At least 5 years experience with X language, worked on Y kind of system, has Z certification.”
If you’re an enthusiastic, talented developer actually creating software in enterprise, you’re probably doing it despite the enterprise instead of because of it. Maybe you have the energy to keep fighting the system for the next 10-15 years — if so, good for you! — but I think the more-likely outcome within 3 years is one of the following:
1. Your coding talent gets noticed in a positive way, so you get promoted to a management position where you don’t get to code any more (per the Peter Principle) or to a greybeard pundit position, where you work mainly on your personal coding projects outside the main dev teams.
2. Your coding talent gets noticed in a negative way, so you leave in frustration and take up a job as an independent or a a startup employee, where you might make less money, but you don’t hate going to work every morning.
3. You give up and join the system as a clock puncher, thinking of work only as the way to pay for the other parts of your life that you do enjoy (new deck, kids’ education, family vacations, rock climbing, sailboat, or whatever).
Chris Toohey wrote “I would encourage all consulting developers and systems administrators to look to the individual skillset and capabilities of the employees of the given enterprise, and adjust your tactic according to what best fits the in-house dynamic. It’s *our* job to give the customer a solution that will work long-term in that specific enterprise. Code/architecture readability, simplistic design, and standards will beat out l33t h4x0r-ing any day, and will ultimately lead to a happier customer.”
I couldn’t agree more.
I think you’ve confused “different” with “shit”. You spend too much time talking about what’s wrong with enterprise development that you forget to point out what’s different. Which is different. I’m assuming this is an exercise in self-validation.
My biggest surprise is that, while I’ve heard some (sometimes well-deserved) complaints about overgeneralization from the enterprise developers, the web developers haven’t complained at all about my claim that they don’t really get integration — that’s where I expected most of the negative feedback, since, because of the Web 2.0 thing, they tend to think they’re good at integration (they’re usually not, unless you count adding a Facebook iframe widget to a page or reading a bit of JSON from a Twitter API).
As an independent, I’m neither a web dev or an enterprise dev, but I’ve spent about equal amounts of time working with each over the past 15 years. Most of the time, they really don’t get each-other’s worlds.
To overgeneralize again (both groups contain many exceptions), web devs complain that they can’t just use Rails and Mongo, release something simple next week, and sort out bugs later (not such a great idea if you’re the government or a big corp, and might leak 1M users’ personal information and credit cards, or generate $10M in incorrect purchase orders), and enterprise devs complain that there’s not an existing module in WebSphere or SharePoint to do the work for them (even when configuring and integrating that module might take 10x as long, with a higher sustainability burden, than simply writing, documenting, and maintaining a couple of hundred lines of custom code).
Wow, the condescending pats on the head about all those passionless, unenthusiastic developers in enterprise just doing the best they can in their 9-to-5, waiting to dash for the exits could not be more insulting if you tried.
I hate to tell you this but simply by the laws of statistics, most developers will be mediocre, no matter the company. They’re about 80% of the bell curve, so the idea that as an independent or as a start-up, you’re going to have all this unbridled passion and expertise that’s heads above enterprise development is going to be wrong 8 times out of ten.
Why doesn’t enterprise have many rock stars? What field is littered with rock stars? If there was an organization of nothing but rock stars, I haven’t seen it, and most likely it would be torn apart by big egos of hotshots who all think they know better. Again, that 80% of the bell curve is working against you…
One of the biggest things that enterprise offers is breadth. You may be working with everything from integrating with a mainframe, to writing RESTful services with JSON APIs means to manage data in a cloud you just built. And if you follow Agile and XP, odds are, you’ll get exposure to all of this in one form or another. Projects in which you get to rule your little fiefdom and write everything from scratch will not teach you this, so lets not bash the skill set of an enterprise consultant or full time dev because of the size of the teams.
PS: I often find that people who say that a certain group in the profession doesn’t get something, proceed to dismiss certain tools for integration (though you really dismissed communication protocols/formats, a design pattern, and a data warehousing process in the same breath with no differentiation) with no detail as to why they’re bad, rarely inspire confidence in their abilities. It’s one thing to have a different opinion about a complex topic, but here you didn’t even try.
Ok, you don’t grok statistics. Both MIT and University of Florida, one of the top party schools int the country, have students that belong to bell curves, but they are independent bell curves. The %80 of “average” MIT students are all ahead of the %80 “average” UF students. The better point, but one which the author already conceded, is that with ten’s of thousands of students UF does have some brilliant students on campus doing very good work.
I don’t think you can unilaterally make the evaluation of how good the average UF student is compared to the average MIT student without hard metrics. Likewise, you’re comparing who attends what college (a matter of prestige and often self-selection) to a job or a contract. This is comparing apples to tangerines.
As I can’t directly reply to your reply, I will put this here. First, statistical information about the quality of students is publicly available, and you can go check it out just like I did this past year as my son applied to college. Second, nothing is more self-selecting than employment, and that’s the point; do you really think the “average” Google employee represents the “average” enterprise IT employee?
“…but on balance, coding for most enterprise employees (as opposed to outside contractors) is a 9–5 drudge job that they’re happy to leave at the end of the day…”
Way to keep the stereotype going…
Im only happy to leave at 5 because I have better things to do with my life, like play with the kids, read books, and complain on blogs.
Henry Ford figured out over 80 years ago that working more than 40 hours a week is a waste of time for the average person. Personally, its been my experience that I’ll figure out solutions to problems more often during “off hours” while doing something completely different then sitting around staring at a screen full of code.
If a “dedicated” and “passionate” engineer has to spend 12+ hours a day and work weekends to accomplish anything, that just tells me they fuck up a lot.
I think “dedicated and passionate” has been confused with scoring high in the ass-in-the-chair metric…
As an enterprise developer I take offense at some of the generalizations made in this article. I work at a large academic institution with dozens of decentralized development groups in addition to a few large centralized IT and data groups. The bit about consumer-oriented developers not understanding data integration as practiced in enterprise rings true, but not for the right reasons. The system I developed/maintained accesses data from at least 6 different sources, mostly relational, some non, and others through web services. This isn’t legacy data at all, its real data being generated by other systems that I must interact with.
Like jniehus said above, I choose to not work after hours or on into the night because I have a wife and two small kids and my life is not solely about being a developer. I am highly productive and get a lot done and don’t feel compelled to work until midnight jacked up on mountain dew hacking out the most awesomest code.
The bit about there not being any good developers in enterprise is an absurd generalization. There are A players here, but there are a lot of B and C players too. I find enterprise is slow to adopt bleeding edge technologies (we are only now getting away from IE7) and so the speed at which things move forward is slow. As a consequence enterprise developers are often not as interested in learning and self-educating in their craft. The B and C players more often come with a certain set of skills and never evolve. But you are mistaken if you don’t think there are A players in enterprise that are churning out great code and even better ideas.
Bottom line is the set of problems enterprise developers are solving are quite different, and it requires different focus. Some of us prefer the security of employment in a large, stable organization rather than the unsure nature of indie start ups and consumer oriented/social/e-commerce work.
Some day when i ride off into the sunset with my retirement account fully funded, I may develop independently, but that’s after the kids are through college and I have other arrangements for health care, etc. etc. Until then I am making good money being an A player in enterprise.
I would also add that some of the problems enterprise developers are solving are fantastically complex and would blow your mind. I cannot possibly explain some of the complex work flows that I’ve seen translated into reliable and clever applications by A players at my institution. Enterprise is about more than shopping carts and css3, you are solving unique problems that don’t have established design patterns. You don’t get a lot of credit either, since most enterprise developers either cannot (confidentiality) or prefer not to bear their developer souls on a blog or some such.
A lot of the comments are unwittingly duplicating the same point that I made in the first half of the post (about web developers not getting integration and complex environments). I’ll take the fact that people are repeating what I wrote (in different words) as a complement. 🙂
The work-life balance issue that a few comments have brought up is also similar to what I wrote in the second half (though perhaps with too much condescension). The difference between a typical enterprise dev and a typical web dev is that the (stereotypical, overgeneralized) enterprise dev sees coding itself as work, while the (stereotypical, overgeneralized) does not. When this archetypal web dev gets home from “work”, she curls up with a new book on NodeJS instead of a spy novel, because that’s what she’s been looking forward to all day — that’s not work for her; it’s relaxation. Think of the airline pilot who rushes home on non-duty days to fly his Piper Cub instead of heading for the golf course — it’s the same idea.
Of course, there are people like that in enterprise, too, but it’s hard for them to last, because the enterprise can really wear down your soul and make you hate coding (simply because big organizations, public or private, have such a high transaction overhead). I’m at the end of deep involvement in a complex, high-visibility, 3+-year enterprise project right now, and it’s going to take a couple of months before I actually like coding again. At this moment, I more resemble the enterprise developer in my posting than I do the web developer.
Yet you insist on continuing to over generalize….
“Of course, there are people like that in enterprise, too, but it’s hard for them to last, because the enterprise can really wear down your soul and make you hate coding.”
This may be your experience but that doesn’t make it everyone’s experience. Are you saying that non-enterprise devs never get worn down? Really? At best you can say this is a more common occurrence for developers in any large scale organization. That would be reasonable.
This article was clearly posted before being well thought out, and you’re paying the price in the comments section. You get kudos for encouraging the discussion.
Would be fantastic if this post took the occasion to look at the different focuses of the two camps and what each can learn from the other. As it reads, its simply passing blanket judgement on an entire tier of developers, which is patently unfair. If you’re going to back down from the generalizations, then stop making more of them. If you find yourself in a hole, stop digging.
chrishhr wrote: “As it reads, its simply passing blanket judgement on an entire tier of developers”
Actually, it passes blanket judgement on two entire tiers of developers. It’s just as harsh on web devs as it is on enterprise devs, though the web devs haven’t been the ones reacting in comments (probably because they haven’t discovered the posting).
Perhaps some more perspective would be helpful. I’m writing this from the POV of an architect designing systems. While I deal with individual developers, I can’t design for them individually, because developers change jobs; instead, I have to design for the organisation. That means that I have to have a mental model of the kinds of people who will be building, maintaining, and operating the system.
With that in mind, I have to design for a hypothetical average developer in both camps. Of course, averages are unfair to individuals — someone (I’m too lazy to look it up) once wrote that the “average” person has one breast and one testicle — but over and over again, I’ve found that I have to adjust my designs for the two worlds to avoid disaster:
Two different kinds of audiences == two different kinds of design. Of course, there are many individual web devs who are good communicators, and many individual enterprise devs who are hotshot coders, but when I’m designing a system that might be in use for 10+ years, I can’t design for the outliers.
Well, I’m just finishing up a stint at a large bank firmly in the Enterprise camp and before that I was with startup (software vendor). I think you’ve nailed it in terms of characterizing the main concerns of the Enterprise dev. A lot of it is about integration. “No surprises” is key because it needs to be robust and battle hardened.
One thing I would add is that while there is a lot of focus on getting maximum efficiencies out of the devs, there isn’t as strong portfolio management. We are good at building stuff predictably, but is it the right thing to be building? It is exacerbated with the project funding process which starts mid-year. You effectively are asking $x for a project that won’t start until 15 months away. Can you really quantify the value and effort for something that far out?
One idea I’ve heard of that I’d love to experiment with, is to have cross functional teams lobby for funding much as a start-up would pitch to an Angel investor. Projects would be funded based on a business case, but only enough to get to MVP and you have to be able to demonstrate value in 3 months max. Kind of a lean intrapreneur model.
Unfortunately, I’ll never get the chance to experiment because I have resigned to go back to a startup…
Gavin: excellent point about portfolio management — if you don’t mind, I’m going to steal that term to make me sound smarter than I really am.
In principle, the portfolio of apps is the responsibility of the Enterprise Architect, but I fear that the enterprise-architecture field isn’t really getting a practical grip on it yet (other than drawing diagrams and trademarking new process names). What have you observed?
My responsibility was the architecture, and it was my first exposure to enterprise level concerns. You had to understand the domain very thoroughly to be effective and it was more about functionality and “maximizing global investment” than pushing out edicts encapsulated in TOGAF diagrams. I was working at a regional location so most of our build involved connecting to the various “utilities”, and helping the Ops guys do their stuff more efficiently through automation.
My mandate was basically to avoid building anything locally if you can, but if you did then the guidance from the high priests was a bit or miss. In one case they insisted using an Model Driven Development approach complete with ESB for a simple ETL problem. That turned out to be a bit of a train wreck (drawing software instead of writing it has never turned out well for me) and it ended up being a franken-architecture that will live on as my legacy unfortunately (sorry guys!). On other occasions we were able to do things really well because of the organisations ability to focus investment (they have a great reporting solution used across multiple lines of business).
To answer your question, yes I agree this is a difficult thing to get your head around as an enterprise and I am surprised how well it works sometimes to be honest. In terms of a practical approach I like what Neal Ford has been saying about evolutionary architecture (http://www.ibm.com/developerworks/library/j-eaed1/), but I think the tricky part is spotting the accidental complexity when you are flying at low oxygen levels.
Thanks again, Gavin. I’ve only just started reading the IBM series on evolutionary architecture and emergent design. One challenge for evolutionary architecture in the enterprise — and especially the public sector — can be long hiring and procurement cycles. It’s tough to discover pain indicating the need for a new component and dev team during iteration 3, then wait 3-6 months for a new hire or for an RFP to go out (with luck, you’ll have them by iteration 30).
I’m sure that’s a problem that can be solved — needs to be solved, in fact — but again, it’s very different from the startup/web world, and I think it’s one reason that the Big Design Up Front has such staying power in the enterprise, even though it’s almost always wrong: the BDUF at least ensures that you start out with a lot of resources, which you can later reshuffle as the architecture evolves.
Why didn’t you do the same thing for the web developers? The good and the bad.
Good: Up to date on the latest tech. Passionate about technology.
Bad: Get bored if things don’t work in the first 30 minutes. Have no idea what would happen to their business if all their clients’ credit card numbers were pilfered by a SQL Injection attack. Or don’t have a business because they’d rather make it look cool than provide actual value.
The above doesn’t apply to everyone of course, but the article appears biased, especially as it starts off with claims to have straddled the fence and therefore bring a balanced viewpoint.
Joshua: here’s my (very harsh) criticism of web developers from the original posting:
“The benefit of all this mess, though, is that an enterprise application designer is always thinking about distributed data, something that web developers talk about don’t always really get. It’s hard to imagine a CMS like Drupal or WordPress — that naively assumes it can keep all the information that it presents in its own (preferably MySQL) database — coming out of the enterprise.”
So basically, I’m saying (again, overgeneralizing) that web developers are completely clueless about data and integration.
One huge difference is simply age. Web developers tend to be in their mid-to-late 20s. Enterprise tends to be at least ten years older. There’s a lot of past-tech-experience there, people who’ve lived through many good and awful trends and been burned by fast changes. They also have a different lifestyle and goals that are simply the result of growing up and wanting to step back, slow down, and appreciate the bigger picture. As we get more experience, we tend to think more of systems rather than atomic parts, and start to realize how important things like change management really are.*
Enterprise selects for older, more staid individuals who have that specific perspective. Web definitely does not; there’s no consequences in web for becoming obsolete — except winning a new contract to build something new that isn’t. Websites and apps have an average turnaround of about three years (for agency work, anyway.) People who are looking to break barriers and find the newest thing are rewarded in web. They are anathema to enterprise.
* I’m an early-30s web developer in an old enterprise environment. I consult outside to keep up on the trendzz. I often chafe at the pace of the work inside, but am starting to understand why it’s so. Sometimes it’s for dumb reasons; but sometimes it’s very necessary, and it’s as much about people as it is about technology. Which isn’t a bad goal for technology.
Nicely put.