Ravi Mohan's Blog

Saturday, July 29, 2006

But Martin, Enterprise Software IS Boring

Martin Fowler writes about Customer Affinity, a factor he believes distinguishes a good enterprise developer from a bad one. So far,so good.

He says "I've often heard it said that enterprise software is boring, just shuffling data around, that people of talent will do "real" software that requires fancy algorithms, hardware hacks, or plenty of math."

This is almost exactly what I say.(Just remove the quotes around "real" ;-) ).

Martin goes on to disagree with this idea (which is fine) but then he says "I feel that this usually happens due to a lack of customer affinity." And this is where I disagree.

People who work on things like compilers and hardware hacks and "tough" algorithmic problems can have customers, just as the enterprise folks do. I know I have. The compiler I am writing now has a customer. The massively parallel neural network classifier framework I wrote a couple of years ago had a customer. The telecom fraud detection classifier cluster I worked on last year (along with some other talented programmers) is being used by a company which is very business (and customer) oriented. So the idea that a "customer" (and thus customer affinity) is restricted only to those folks who write database backed web apps is simply not true.

Math/algorithms/hardware hacks and the presence or absence of a "customer" (and thus, customer affinity) are orthogonal (you know, two axes at 90 degrees to each other) issues.

With the customer issue out of the way, let us examine the core issue - the notion that talented developers would prefer to do stuff like compilers and algorithms instead of a business app (by which I mean something like automating the loan disbursal processes of a bank).

The best way to get a sense of the truth is to examine the (desired) flow of people in both directions. I know dozens of people who are very very good at writing business software who yearn wistfully for a job doing "plumbing" like compilers and tcp/ip stacks, but I've never yet seen someone who is very very good at writing a compiler or operating system (and can make money doing so) desperately trying to get back to the world of banking software. A programmer might code enterprise apps for money, but at night, at home, he'll still hack on a compiler.

It's kind of a "Berlin Wall" effect. In the days of the cold war, to cut through the propoganda of whether Communism was better than Capitalism , all you had to do was to observe in which direction people were trying to breach the Berlin Wall. Hundreds of people risked their lives to cross from the East to the West but practically no one went the other way. Of course this could just mean that the folks didn't appreciate the virtues of people's power and the harangues of the comissars but I somehow doubt it.

To see whether living in India is better than living In Bangladesh (or whether living in the United States is better than living in India) look at who is trying to cross the barriers and in which direction.

Economic Theory suggests another way of finding an answer. Suppose you were offered say 10,000$ a month for say 2 years, to develop the best business app you can imagine and say, 8000 $ a month, for the same two years to work on the best systems/research project you can imagine. Which one would you choose? Now invert the payment for each type of work. Change the amounts till you can't decide one way or another and your preference for either job is equal. Finding this point of indifference (actually it is an "indifference curve") will teach you about your preference for "enterprise over systems". I believe that while individuals will choose many possible points as their "points of indifference" on that curve, a majority of the most talented debvelopers would prefer a lower pay for a good systems/research project in preference to an enterprise project, no matter how interesting. And to most developers, an enterprise project becomes interesting to the degree it needs "tough programming" skills (massively scalable databases say.. there is a good reason Amazon and Google emphasize algorithms , maths and other "plumbing" skills in their interviews and an equally good reason why a Wipro or a TCS doesn't bother testing for these skills).

The widespread (though not universal) preference of the very best software developers for "plumbing" over "enterprise" holds even inside Thoughtworks (where Martin works and where I once worked). I know dozens of Thoughtworkers who'd prefer to work in "core tech". While I was working for TW, the CEO,Roy Singham, periodically raised the idea of venturing into embedded and other non enterprise software and a large majority of developers (which invariably included most of the best devs) wanted this to happen. Sadly, this never actually came to pass.

A good number of thoughtworkers do business software to put bread on the table, or while working towards being good enough to write "plumbing", but in their heart, they yearn to hack a kernel or program a robot. (Another group of people dream about starting their own web appp companies). For most of these folks tomorrow never quite arrives, but some of the most "businessy" developers in Thoughtworks dream of writing game engines one day or learning deep math vodoo or earning an MS or PhD. And good people have left TW for all these reasons. And if this is the situation at arguably the best enterprise app development company (at least in the "consultants" subspace) one can imagine the situation in "lesser" companies.

The programmer who has the ability to develop business software and "plumbing" software and chooses to do business app development is so rare as to be almost non existent. Of course, most business app dev types are in no condition to even contemplate writing "hard stuff" but that is a topic for another day.

Paul Graham (admittedly a biased source) says (emphasis mine),

"It's pretty easy to say what kinds of problems are not interesting: those where instead of solving a few big, clear, problems, you have to solve a lot of nasty little ones....Another is when you have to customize something for an individual client's complex and ill-defined needs. To hackers these kinds of projects are the death of a thousand cuts.

The distinguishing feature of nasty little problems is that you don't learn anything from them. Writing a compiler is interesting because it teaches you what a compiler is. But writing an interface to a buggy piece of software doesn't teach you anything, because the bugs are random. [3] So it's not just fastidiousness that makes good hackers avoid nasty little problems. It's more a question of self-preservation. Working on nasty little problems makes you stupid. Good hackers avoid it for the same reason models avoid cheeseburgers."

Strangely enough, I heard Martin talk about the same concept (from a more positive view point, of course) when he last spoke in Bangalore. He explained how much of the complexity of business software is essentially arbitrary - how an arcane union regulation about paying overtime for one man going bear hunting on Thanksgiving can wreck the beauty of a software architecture. Martin said that this is what is fascinating about business software. But he and Paul essentially agree about business software being about arbitrariness. It is a strange sense of aesthetics that finds beauty in arbitrariness, but who am I to say it isn't valid?

Modulo these ideas, I agree with a lot of what Martin says in his blog post. The most significant sentence is

"The real intellectual challenge of business software is figuring out where what the real contribution of software can be to a business. You need both good technical and business knowledge to find that."

This is so true it needs repeating. And I have said this before.To write good banking sofwtare, for e.g. you need a deep knowledge of banking AND (say) the j2ee stack. Unfortunately the "projects and consultants" part of business software development doesn't quite work this way. I will go out on a limb here and say that software consulting companies *in general* (with the rare honorable exception blah blah ) have "business analysts" who are not quite good enough to be managers in the enterprises they consult for and "developers" who are not quite good enough to be "hackers" (in the Paul Graham sense).

Of course factoring in "outsourcing" makes the picture worse. By the time a typical business app project comes to India, most, if not all of the vital decisions have been made and the project moves offshore only to take advantage of low cost programmers, no matter what the company propoganda says about "worldwide talent", so at least in India this kind of "figuring out" is almost non existent and is replaced by an endless grind churning out jsp pages or database tables or whatever. It is hard to figure out the contribution of your software to people and businesses located half a world away, no matter how many "distributed agilists" or "offshore business analysts" you throw into the equation.

This is true for non businessy software also,though to a much lesser degree. The kind of work outsourced to India is still the non essential "grind" type (though often way less boring than their "enterprise" equivalents). The core of Oracle's database software for .e.g. is not designed or implemented in India. Neither is the core of Yahoo's multiple software offerings - the maintenance is, development is not. And contary to what many Indians say, this is NOT about the "greedy white man's" exploiting the cheap brown skins. You need to do hard things and prove yourself before you are taken seriously. Otherwise people WILL see you as cheap drone workers. That's just the way of the world).

And I say this as someone who is deeply interested in business. T'is not that I loved business less but I loved programming more :-).I'd rather read code than abusiness magazine but I prefer a business magazine to say, fashion news. I actually LIKE reading about new business models. I read every issue of The Harvard Business Review (thanks Mack) and have dozens of businessy books on my book shelf along with all the technical books. (I gave away all (300 + books) of my J2EE/dotNet/agile/enterpise dev type book collection , but that is a different story). I am working through books on finance and investing and logistics. I have friends who did their MBA in Corporate Strategy from Dartmouth or are studying in Harvard (or plan to do so). I have friends who work for McKinsey, and Bain and Co, and Booz and Allen, and Lehman Brothers. If I were 10 years younger (and thus had a few extra years to live), I'd probably do an MBA myself. And of course I have spent 10 years (too long, oh, too long) doing "enterprise" software. In my experience (which could turn out to be atypical),the "plumbing" software is way tougher and waaaaay more intellectually meaningful than enterprise software, even of the hardest kind. I might enjoy an MBA, but I will NEVER work in the outsourced business app development industry again even if I have to starve on the streets of Bangalore. I'll kill myself first. So, yeah I am prejudiced. :-). Take everything I say with appropriate dosages of salt.

And just so I am clear, I do NOT think Martin is deliberately obfuscating issues. I think Martin is the rare individual who actually chooses enterprise software over systems software and is lucky enough to consistently find himself working with the best minds and in a position to figure out the business impact of the code he writes. This is very different from the position of the average "coding body", especially when he is selected more for being cheap than because he knows anything useful ("worldwide talent", remember :-) ).

Btw, Martin's use of the word "plumbing" is not used in a derogatory sense (though I've seen some pseudo "hackers" take it that way, especially since the word makes a not-so-occasional appearnce in many of his speeches) but more in the sense of "infrastructure". If you are such a "hacker" offended by the use of the term, substitute "infrastructure" for "plumbing" in his article. That takes the blue collar imagery and sting out of that particular word, fwiw.

I think Martin has very many valuable things to say. I just think he is slightly off base in this blog post and so I respectfully disagree with some of his conclusions.

But then again, it could all be me being crazy. Maybe enterprise software is really as fascinating as systems software, and writing a banking or leasing or insurance app really as interesting as writing a compiler or operating system.(and Unicorns exist , and pigs can fly).

Hmmmm. Maybe. Meanwhile I'm halfway under the wall and have to come up on the other side before dawn. Back to digging.

23 comments:

Manoj Govindan said...

"Working on nasty little problems makes you stupid"

This is so true. When I recently left my enterprise programming job (read, mostly dumb projects "offshored" from the West) of six plus years I could see that I had learned very little *on the job*. The quantum of knowledge and skill required to keep the wheels turning in such projects is so low and the need/incentive to learn more so limited that I was merely "floating" after the first couple of years or so. 99% of the "tough" problems that I faced during my stint were only problems thanks to unnecessary human intervention.

Take for example projects that used ETL tools such as IBM (formerly Ascential) DataStage. What would have taken any reasonably competent team a week took forever just because someone had sold the idea of using an ETL tool to the client (Fowler himself has spoken about this phenomenon. He called such tools "Golf Club tools", but I digress) The first order of problem solving then became overcoming the idiosyncrasies of the tool rather than tackling the actual requirement (which was reasonably straightforward) of getting the data from point A to point B. It is a wonder that developers learn anything at all in spite of doing such work month after month, year after year.

Amit said...

Very informative
Right content

Vladimir Levin said...

But... I do think that many developers like things like compilers and framework type projects precisely because they can be creative and work on their own more instead of with a customer. Yes, you have customers for the more "hardcore" projects you've mentioned, but I have a feeling that the balance between the user-visible requirements and behind-the-scenes hacking tips toward the latter, no? My favourite thing to do at home is to build small pieces of code to do things that I think are nifty or to demonstrate a basic concept; it's much more interesting than working on a large application where you have to fill in all the details... But that tends to be why I get paid to do the latter :)

Ravi said...

Vladimir,

You make two excellent points.

1."Yes, you have customers for the more "hardcore" projects you've mentioned, but I have a feeling that the balance between the user-visible requirements and behind-the-scenes hacking tips toward the latter, no?"

Hmmm. I certainly can't think of how to demonstrate a compiler (say) to a "customer" in small pieces with advancing functionality, because the intermediate steps ("lexing works") mean nothing in terms of the customer's language. A compiler is very much an all or nothing project.



But other projects like AI classifiers *can* be demonstrated in pieces, handling tougher and tougher (and larger and distributed and fragmentary etc) sets of data for example.

So I am not sure good developers prefer such projects *because* you don't have to deliver in small pieces. I would think that mode of delivery is somewhat orthogonal to developer preference.

OTOH I think there is a difference in these sort of projects in that the "requirements" even when fragmentary map quite well onto technical terms.

e.g.: " I want greater fraud detection accuracy" can be *measured* in terms of the underlying classifier implementation and thus is more of a challenge than some incomprehensible business process which changes (from a developer's pov) arbitrarily.

So maybe it is a factor after all, but it looks like it maybe a bit more subtle than "customer goes away for a while". As a matter of fact maintaining a communication link with the customer seems even more important if you have to put your head down and hack for amonth or so before you have something you can show to the customer :-).


2. "It's much more interesting than working on a large application where you have to fill in all the details... But that tends to be why I get paid to do the latter :)"

Yes. The one good thing about the "enterprise" projects is that getting paid is never an issue.

If you are a halfway decent developer, it is quiet easy to get a decently paying job, even with not-so-great skills. You are constantly earning as you improve yourself.

Acquiring the skills to write an Operating System (say) requires large chunks of dedicated time. No one will pay you while you spend all those months learning hacking!

Even when one has acquired the ability to create "tough" programs, getting paid to do interesting work is not easy. It is even harder if one is in an "Outsourcing Destination" like Bangalore because of the typecasting as a "cheap" coding body incapable of writing serious programs.

You have to demonstrate your expertise before someone will pay you and that opens up the possibility of a frightening gap in the time line where there is no money coming in.


Good points. You have given me stuff to think about. :-)

Thank you for taking the time to comment.

jay said...

To me, enterprise software is information processing and infrastructure is data processing. I'll have explained what I mean by the end.

Infrastructure strikes me as a closed ended system. A TCP/IP stack must correctly implement the relevant RFC's. A compiler must be able to parse and compile the predefined language. As you mentioned, on the whole, they either work or they don't. The requirements are well defined.

Enterprise software to me means there are rules and processes, along with exceptions. These are determined by the domain. The requirements are loosely defined.

From this description, I think "enterprise software" is a completely empty phrase, primarily due to how it's been abused by some. (Think "enterprisey software.") I believe a more accurate and intuitive term is systems software:

"A system is an assemblage of inter-related elements comprising a unified whole. From the Latin and Greek, the term "system" meant to combine, to set up, to place together." (Wikipedia)

Its definition actually describes what we're talking about and it's so boring that nobody will try to buzzword it. Win/win.

It is this assemblage that I find so intriguing and challenging. The way the elements (or pipes if you're Martin) can be hooked up is near infinite. How they are assembled defines how the information is transformed to create the rules and processes needed to make the system work. They can be hooked up arbitrarily, resulting in a system that is not easily extensible or maintained. Or they can be hooked up intelligently that allows for easy changes and maintenance in the future. I consider this to be the difference between a programmer and a software engineer. I aim to achieve the later.

I think there are two sets of minds that lend themselves either to systems or infrastructure. I believe on the far left (systems) you have architects and on the far right you have researchers (data structures/algorithms/etc.). If I had to hazard a guess I'd say most would fit closer to the middle than to the poles.

To summarize, with data processing I visualize a stream of data that has little, if no, context around it--it's like a sorting algorithm. With information processing I visualize there being a context around the data that is required to turn it into information--the business rules and processes that wrap around the underlying data.

The line between these two worlds can probably be drawn at how far away from mathematics you are and how close to art you go.

Anonymous said...

There can be interesting things in enterprise-style development. A couple of years ago, I went to work at a very small company selling a heavily-customized packages to medium-sized organizations. It's not an exciting business per se, and even though they were successful their existing front end was running on Access, of all things.

I came in because I got the opportunity to do a clean rewrite in C#, which is the kind of project you don't get very often. We needed a lot of client-specific customization, and one of the ideas that was being kicked around was whether we eventully needed to be able to ship some of our development offshore to India. We also needed both a desktop client and a web client, which, due to porting, just emphasized the amount of boring code potentially in front of us.

Fortunately, I was given the latitude to go in a completely different direction. The system we've built uses a dynamic, database-driven approach to both business logic and user interface. So instead of building yet another CRUD form, we just built a bunch of cleverly-archtected code that lays out all the CRUD forms based on metadata. Then we built another thin layer that takes the same metadata and makes a web app out of it. We built a scripting system, so the programmers don't have to write all the mindnumbing logic exceptions.

So now, we have a bunch of highly client-focused project managers who are just technical enough to do the configuration and customization work. We don't need the army of cheapp Bangalore programmers, because virtually everything that our actual (tiny) dev team works on is hard enough to require real thought.

We may not be implementing thread-scheduling algorithms or something, but I did get to build a compiler for the scripting. We get challenging logic and architecture problems all the time, and our customers are project managers, not all the individual clients, so we don't get caught up in reordering the text boxes for the client until the project manager runs into something the toolset can't handle and we have to extend them.

It's still enterprise software, but it's a lot more fun than the run of the mill stuff.

casey said...

I have been working on applications that process large amounts of manufacturing data, so that we can optimize factory processes.

While the end deliverable has to solve real business problems, in the process of getting there, I've leveraged tuplespaces for distributed queueing, metaclasses for event-based object streaming, and put a front-end on it with Django. The system will eventually support clustering, regression, and statistical engines. I don't have to write all these, it is fun enough to put them together and see the whole thing work.

Maybe this is because I'm getting to enjoy the business side as much as the coding side, but maybe also because Python takes the suck out of enterprise?

Ravi said...

@anonymous,
you say

"We built a scripting system, so the programmers don't have to write all the mindnumbing logic exceptions."

resulting in

"we have a bunch of highly client-focused project managers who are just technical enough to do the configuration and customization work. We don't need the army of cheapp Bangalore programmers, because virtually everything that our actual (tiny) dev team works on is hard enough to require real thought."

It looks like you've been developing business/enterprise apps the way they should be. Good for you.
I've come to see that the degree of "deep thought" required to build a system is very indicative of its (un)outsourceability.
The fact that you are building a business specific toolset vs churning out n more jsp pages (say) is highly interesting and indicative , I believe of how business apps *should* be built.

@casey,
I believe using Python (vs say C#) could be an important factor in reducing "the suck" of many enterprise systems, as would "enjoying the business". But then your project is barely "enterprisey" and seems to be quite different from the typical entrprise project, especially the outsourced variety!

Thanks, both of you for your insightful comments.

Ryan Baker said...

Enterprisey software fits into a crossworlds far less specialized than building compilers or frameworks.

This duality is the primary source of discontent and many of the secondary sources as well. In the most simplistic of views, duality blurs the lines between goals and makes success far less obvious.

This applies to most jobs really. Once the classifications start to blur you no longer belong to a single group, which makes it far more difficult to gain the accolades and respect that most people desire, because it's difficult to be the best programmer, when your something else as well.

In truth your combined skills may be far more valuable, but it's hard to have that recognized because there is no group qualified to evaluate both sides of your personality and skills.

Underneath all of this there is an entire infrastructure based upon the mistaken assumption that those that span both sides aren't valuable that encourages specialization, and impedes the ability of those with dual skills to put them to maximum use.

Over the wall business analysis is one example, which is what Martin is railing on more or less. Rigid career paths, pay grades, and processes also contribute beneath the surface. It all builds up.

The worst part of all this is that those dual skills are extremely valuable. The quality of a product designed and developed by a developer, or group of developers who understand the business is incomparable (as long as they are good developers too).

When development goes from idea to keyboard, rather than 5 levels of indirection, it's obvious that fewer mistakes due to communication will occur, and efficiency will be much greater as well.

Ravi said...

@Ryan,
Interesting thoughts about the value of "dual skilling".

However I am not sure that good developers resent writing enterprise software (the banking app types) because it forces them to "dual skill" and thus lose recognition. Business is interesting if not particularly fascinating.


I personally hate the average "banking loan disbursal" type apps because the *thinking* required to do a good job is minimal. Unlike the folks who would automate everything they can so that any problems that come up would be "tough" ones (see the comment by "anonymous" above) most "enterprise" app projects, particularly the "outsourced to bangalore" variety has a lot of "grind" (not to speak of atrocious code bases) built into them. This is what makes them boring and life draining.

Ryan Baker said...

I don't think most developers consciously think of it this way, but the truth is that a lot of people want certain jobs, both inside tech and out, because they are sexy.

There plenty of things that go into whether a job is sexy or not, but duality has a tendency to push the sexiness of a job down.

Also, my point wasn't that developers don't want to dual skill. The point was that business and society aren't setup to give much benefit for doing it, even if it's really valuable.

Since it's takes work, and that work must come at the sacrifice of something else that has better benefits, like learning to write compilers, most developers do that.

That is, of course, assuming they stay developers at all, and don't take the management route where they abandon all technical ties (maybe not all at once, but usually eventually). The push works both ways and once over the line it's difficult to justify balancing upon it.

Mike said...

Ravi-

Excellent post. I posted a reply over in my blog in which I took a slightly different viewpoint.

I agree with your assessment in that most hardcore programmers would prefer to do system-level work, but think that the reason isn't because enterprise (or more appropriately, database-backed website) development is tedious. It has more to do with how programmers are motivated.

Anonymous said...

What I like least is the compatibility dance.

Two days of probing newsgroups and talking to coworkers and I find out: Well, ZongoLib 4.3A has to have SuperDuper.dll version 7.3 or above, and only rev 5.9.3.14 (build 903) of SocketSoup For Hysteria will work with these.

Great, I've learned nothing permanent except maybe a little bit about searching news groups.

And in three months it will be all different, when DoodleFoo VII is released. Yuk!

Ravi said...

@ryan
Thanks for the clarification. If by "sexiness" you mean that developers look for a language that would need them to do deep thinking and keep them interested, I agree. If by "sexy", you mean "other people think this is cool" (e.g a hollywood actor/racing car driver) I don't agree. I for one could care less what *other people*think about my job, as lonag as *I* love doing it and it challenges and satisfies me. I suspect you had the fromer meaning in mind.

@mike
Good post, though we seem to be speaking past each other a little bit. For one, I wasn't *attacking* "enterprise" software,(so no need ot *defend* it) just disputing (a little) the idea that "customer affinity" magically makes enterprise software *as interesting as * non enterprise software.

And where did I treat "enterprise" software and "database backed websites" as "one and the same"?

the only entence which could be interpreted that way is

"So the idea that a "customer" (and thus customer affinity) is restricted only to those folks who write database backed web apps is simply not true."

replace "database backed websites" with "enterprise sofwtare" and the meaning of the sentence (and the point being made) doesn't change.

you also say "When it comes down to it, Ravi is trying to answer the question, “what motivates software developers?”. "

No I am not :-) I am just *stating* that most enterprise software projects do not challenge a good developer in the same way as hacking on the linux kernel or developing a compiler would.

The challenges in enterprise sw development lie more in achieveing a deep understanding of the domain and frankly a lot of this complexity is "arbitrary complexity" driven by arcane rules derived from legislation and history more than anything else. PG makes this point much better than I can, so I'll desist. Anyway most of the people who work on enterprise software know jack all about banking or leasing or whatever the domain is and rarely keep up on the domain once the project is over.

So I guess I disagree on your notion that
"hardcore programmers would prefer to do system-level work, but I think that the reason isn't because enterprise (or more appropriately, database-backed website) development is tedious."

I *am* saying almost exactly that the reason *is* that enterprise developemnt is tedious. Let me go out on a limb here and say enterprise software development is a less *technically * challenging endeavor (and thus requiring lesser amounts of "deep *technical* thinking" /brainpower than non enterprise software.

Of course, that doesn't mean non ent. software is "better" then ent . software, just that it is more boring for a certain classof developers ("hackers" in the PG sense).

Thanks for your helping me clarify my thinking

Ravi said...

@mike

you say (in your blog entry)
"The fact of the matter is that there is a lower bar of entry to development now than at any time in the past; that is a good thing!"

agreed!

"There is plenty of space at the table for everyone."

oh, absolutely!

Anonymous said...

This needed to be said!

A was coding games up until February but left for a 30% pay rise doing enterprise software.

And I hate it as it's the most soul crushing work I've ever done!

I'm currently looking for a new job doing games, research or algorithms based coding and I'm willing to take a 30% pay cut to get it!

Anonymous said...

Mike said

(sorry Mike, I deleted your comment by mistake and blogger doesn't allow me (== Ravi) to undo changes)

Ravi-

Thank you for the thoughtful reply. :)

In rereading, I think the database-backed sentence you mentioned was the one that made me think you had grouped the two categories. You had referred much to "hard" programming problems, and I supposed that phrase stuck in my head as what you considered a "soft" challenge."

I do agree with much what you said, but I disagreed (and still do) with the idea that it is the technical difficulty of the task (let's say the "anti-tediousness") that makes developers flock to it.

Take compilers, an oft-mentioned category. Writing your own can be fun; you get to deal with lexers, parsers, and all other cool things that most developers don't get to play with. On the other hand, if I had to hack g++ for a living, I would lose my mind. What makes programming your own compiler interesting (for me anyway) would be the three items I mentioned, several of which are absent when working on an established project.

It isn't a matter of what the software does that results in satisfaction, but the way it gets written. I thought in your post that you were perhaps mincing this, calling things that were tedious (ie. didn't meet the three criteria I mentioned) as "enterprise." Confusing the situation in which bad things tend to happen as the reason for the bad things.

Hope this clarifies. I have had time to think about it more, so I think I may have been a little more on-point here than in the original post. I tend to meander in the first attempt. :)

-Mike

Ravi said...

@Mike(aka the "anonymous just above this comment :-) )

You say,
"but I disagreed (and still do) with the idea that it is the technical difficulty of the task (let's say the "anti-tediousness") that makes developers flock to it."


so far so good. Dis agreement between well meaning people is good for the intellect :-)

but then you say ..

"On the other hand, if I had to hack g++ for a living, I would lose my mind."

Hmm I am confused. I would have thought that the *tedium* of hacking gcc(relative to writing your own compiler) would be the exact factor that drives you nuts.

I guess deciding where "tedium" becomes "lack of control"/any of the three factors you identified) maybe splitting hairs.

Anyway that wasn't the point I was making. Supposed you were condemned to 6 months of tedium. You could either hack a new gcc backend or you could hack some humungously horrid enterprise code. What would you prefer?

Even working on gcc will teach you far more than working on yet another banking/leasing app and thus be preferred by the (PG style) hackers.

THAT was my point.

Thanks for taking the time to clarify.

"I tend to meander in the first attempt."

You are telling me brother :-) I meander on the nth attempt so you do a lot better than me :-)

Ryan Baker said...

@Ravi,

No, I did mean the latter definition of sexy. What I think is missing is the context, because you are interpreting it from your point of view.

My overall point is that most of what makes writing enterprise software not fun is outside of the programming problem itself, and has more to do with culture. This culture has arisen mostly because of some tendencies, and the lure of sexy jobs is one of them.

It doesn't matter if you, or I are chasing those jobs because they are sexy or not, the fact that a lot of people are distorts the culture. When HR directors and managers see 90% of the developers (or even 60%), trying to focus on hard core programming, they tend to setup for that. And when things are setup that way, and developers are partitioned off from the part of enterprise software which could make it interesting, it's won't be interesting.

I think a key semantic reminder here is some of us may be talking about "Can enterprise software be interesting?", and some are talking about "Is enterprise software (today) interesting?"

I think it can, but you have to break down some barriers, that today are usually up.

Ravi said...

@Ryan,
"I think a key semantic reminder here is some of us may be talking about "Can enterprise software be interesting?", and some are talking about "Is enterprise software (today) interesting?" "

Excellent!! This helps me clarify my thinking. Thanks.

I guess what *I* am saying (as distinct from your pov which is certainly valid)is that (a)enterprise sw development *can* be made more interesting. [iow I agree with you. Exploring the costs involved in doing so and the willingness of sw companies to pay those costs might prove fruitful.] and (b) I do not think enterprise sw development (however practised) will *ever* be as interesting as working on the linux kernel or the guts of
google's search engine or a 3D graphics engine a la John Carmack. Here we probably disagree.


"It doesn't matter if you, or I are chasing those jobs because they are sexy or not, the fact that a lot of people are distorts the culture"

I guess I disagree with the notion that a "lot" of people actively chase (vs daydream about) the programming jobs which *other people* find fascinating (your definition of "sexy").

Also wrt "HR directors and managers see 90% of the developers (or even 60%), trying to focus on hard core programming, they tend to setup for that. And when things are setup that way, and developers are partitioned off from the part of enterprise software which could make it interesting, it's won't be interesting."

I am not sure I can follow the cause effect logic here. I hope you'll take the time to write a blog entry explaining this in some detail.

Mike said...

Ravi-

It's funny; as I was walking to the office (right after I posted my response, of course) I started to see what you were saying. And you were right, we were talking at odds. :)

I was thrown off by the word "hard" in that I thought the argument was more between "hard" vs "soft" programming rather than "tedious" vs "natural" or "flowing." Your explanation was astute, and I apologize for my bull-in-the-china-shop routine. :)

I wonder to what extent "hard" programmers enjoy working on algorithms and compilers because of the different customer base. The consumers of those things are either a) computers or b) other developers, so the cognitive dissonance present when dealing with the irrational outside world doesn't really come into effect. Perhaps that is what Martin meant by Customer Affinity, ability to empathize with those whom we cannot understand. :)

Definitely an interesting topic!

-Mike

-Mike

Ravi said...

"The consumers of those things are either a) computers or b) other developers, so the cognitive dissonance present when dealing with the irrational outside world doesn't really come into effect."

not necessarily. I dispose of this argument in the first few paragraphs of my entry. Customer affinity is orthogoanl to systems vs enterprise. the folks who asked me to write a teleconm fraud detection classifier (for e.g) were hard headed businessmen (and very successful too). The idea that enterprise devs have some special skill of customer affinity does not hold water in my experience. It is just something they tell themselves to comforth themselves. Kinda like what teh folks woring onthe Y2K problems used to tell themselves - "What we do is damn cool coz it will stop the world from imploding...."

Jon said...

Nice article. Writing and support HR apps at Intel can be boring, but I find all the fun to be in understanding the problem as well as the infrastructure details such as IIS, app pools, com+ apps, impersonation, perfmon, etc.