How often is it that you can read something that’s extremely well written, agree with it in principle, and still want to walk up to the author, pull the middle finger out of your pocket (the old “I got something for you” bit) and tell him to fuck right the hell off?

I guess that’s why I like Joel.  Sometimes good, sometimes bad, his writing always makes me think, and it’s always well done.

But I take HUGE umbrage with his latest work, Hitting the High Notes.  Not the underlying thesis mind you.  I agree 100% in principle with something he has been selling since time began.  Hiring the best programmers makes a difference, and that there is a huge difference between top performers and the next tier.  Not only is that truth manifest in the time-to-release, but also in the quality of the end-product.  I have no beef with Joel on this philosophy.  We are on the same page.

No, my ire comes from a couple of statements he makes, off the cuff almost:

Is software really about artistic high notes? "Maybe some stuff is," you say, "but I work on accounts receivable user interfaces for the medical waste industry." Fair enough. This is a conversation about software companies, shrinkwrap software, where the company's success or failure is directly a result of the quality of their code.

And:

Sadly, this doesn't really apply in non-product software development. Internal, in-house software is rarely important enough to justify hiring rock stars. Nobody hires Dolly Parton to sing at weddings. That's why the most satisfying careers, if you're a software developer, are at actual software companies, not doing IT for some bank.

Sorry Joel, but I’m not going to let that one slide by.  As background, those of you who read my (unfinished…working on the next one) Growth of the Corporate Software Developer posts (Prologue, I, II, III) know that I am what Joel refers to as the second world, the internal software developer.  In this piece he makes some assumptions about the internal developer that lead me to believe that he speaks as someone looking in from out there, not someone with experience.  Not that I would begin to take a shot at Joel’s illustrious resume, and I don’t know his whole past, but I’m not going to sit here and let a guy who has clearly primarily been involved in “shrinkwrap” software (Excel, Fog Creek) tell me what it’s like in the dev department of your corporate IT shop.  I will not have my career’s work be painted as less than what it is.

Let’s take a look at something he says that is particularly annoying, that in-house software is not important enough to warrant hiring top talent and the implication that a company who doesn’t sell software isn’t going to live or die based on software.  Let me take a look back at my career:

• Internal development at a law firm.  Company lives and dies on its billing system, externally developed.  I administered the network more than coded, and my programming amounted to little more than Office automation.  Score one for Joel.  Any monkey could have done that job.
• Application development for city government.  Barely wrote a line of code they had their heads so far up their asses.  Another point for Joel.
• Application development for a startup healthcare company breaking into, and defining a new industry.  The software systems we were putting in place were a major selling point of the company’s services, and had they not been there, we certainly would have failed.  No we weren’t selling the software in boxes for direct revenue, but without the software, there would have been no services to sell.  I think this one is a point for my camp.
• LIMS development at a multinational biotech company.  I was barely a drop in the pond.  There’s another for Joel.
• Ecommerce development.  The whole company was the software that ran the web sites and operations.  No software, no company.  And we were selling services to resellers based on the software.  Not shrinkwrap, but directly revenue generating nonetheless.  I think this is mine.
• A job I won’t mention and have no idea why the guy even thought he needed a programmer…
• Current position.  I am not at liberty to discuss in depth, but suffice it to say that if my team fails at what we are developing, the company won’t necessarily fail, but will suffer major setbacks.

Almost half of the development jobs I have had were situations where the internal software was in fact a major player in the success or failure of the business.  3/7 (really 6 though, because one of them…sheesh).  That’s just one person’s relatively short 9 year career.  I’m sure I’m not the only corporate developer who has similar numbers.  So clearly there are instances where internal software is far more imporatnt than Joel gives it credit for.

My point is this:  in-house developers are not second-class citizens.  Shrinkwrap software is not the only place that top quality matters.  The point Joel seems to miss with these statements dismissing the corporate development world is that these companies have an in-house development staff for a reason:  differentiation.  Shrinkwrapware is by its very nature generic and abstract.  I does either one very specific thing or several things in a very broad way, and is not tailored to any particular company.  But a lot of companies occupy vertical markets where the slimmest of differentials between them and a competing service provider means clients or no clients.  And a lot of those companies use internally developed and controlled technology platforms to achieve and maintain that margin over the competition.  Building a better mousetrap indeed.  Nobody builds an internal AP/AR system unless they are stupid and cheap.  A good majority of your in-house IT developers are working on systems that, at least according to management, are hugely important to the success or failure of the business.

You see (and you know if you are an IT developer), the email client, office system, accounting software, and all that other “real software” is not the thing that will differentiate one service provider from another.  Our clients could not care less.  What our clients want is their service, turned around quickly, with pretty data at the end.  Well everyone provides that, so you start looking for ways to do it better.  And that’s where the in-house development staff comes in.  If you don’t think it’s a straight up war between you and your counterpart at your closest competitor, then you’re kidding yourself.  Because your CEO, or VP of Sales, or head of Marketing is going to come to both of you one day and say “hey, the other guys are doing x.  Can we do x++, y, and dynamically decide whether or not to do a, b, c, and g?”.  And the one of you that is able to say yes, and deliver on that yes is the one who’s company is going to be more successful.  And I dare Joel or anyone else to say that you don’t have an effect on the bottom line.

There is a major difference between my world and Joel’s that he often overlooks.  The way we have to operate.  Joel says it himself at the top of his latest essay:

The common belief is that when you're building a software company, the goal is to find a neat idea that solves some problem which hasn't been solved before, implement it, and make a fortune. We'll call this the build-a-better-mousetrap belief. But the real goal for software companies should be converting capital into software that works.

And there you have it.  Joel’s job is to turn capital into software that works.  He just has to make another one-off shrinkwrap package.  I mean, I hear that Fog Creek’s stuff is good, and I actually have really been wanting to try out FogBugz, so don’t take this as an attack.  But Content Management and Project Management?  Those are his products?  Color me wholly unimpressed. 

My job, however, is to find a way to say “yes” when the business development people come to me and say “can we do this, which will win us more clients?”.  And then I have to deliver on that promise.  And I have to do it with more constraints than are fair, at least from my point of view.  Developers like me are tasked with accomplishing far more than they should be able to with far fewer resources than they need.  Allow me to use Joel’s own words:

“Because the value of the development effort is spread over only one company, the amount of development resources that can be justified is significantly less. “ and “ To get a reasonable ROI you can't spend as much as you would on shrinkwrap. “ (ibid).

So, I’m going to jump way out on a limb here in response to those two statements.  I’m better and more valuable than Joel’s best programmer.

Nice hook eh?  Let me clarify.  I doubt that I am 1/8th as talented as Joel’s worst programmer.  I certainly don’t get paid as much.  So what did I mean?  I have already established in a very vague way that what I am currently doing, as well as projects I have done in the past, are critically important to the companies I worked for.  So, taking Joel’s statements as truth, which they pretty much are, that means that I have to make entire software systems – we are talking about enterprise architectures here, not just single-purpose shelfware – with inadequate capital and resources.  That means I have to be highly creative, highly resourceful, and highly talented at my particular thing that I do in order to pull it off and be successful.  LET ME just make a content management system for sale.  Fucking gladly.  You think it’s easy to be Atlas?  When you are an internal IT developer working on that enterprise system that everyone is pushing so hard for, that system that will make or break the company, that will push you ahead of the competition, you feel like the entire company is on your shoulders.  The systems that I have to create, sure they aren’t an iPod (for whatever reason Joel is so in love with the thing), but they are highly complex beasts of business rules and partner integrations and legacy data and and and and.  Meaning, quite simply,  the salient points of the systems I, and other developers just like me, have created can’t be described in bullet points on the back of a box.

But every day corporate development staffs are doing more with less, and doing it extremely well.  Sure Joel, you’re right, a lot of internally developed software sucks.  But there’s a reason why you’re right.  It’s back to talent.  The corporate development pool is saturated with the unwashed masses that learned beginner-level VB in the dotcom era and call themselves developers.  And the companies that get that “talent” end up with internally developed software that sucks.  But for this corporate development problem domain there are “rock stars” separate from the celebrity programmer types.  Guys like me that are good at building large, complex systems with little resources and high expectations, and that can deliver on those promises.

Over at StronglyTyped, Richard cites Joel and talks about the satifaction of delivering commercial software.  That’s fine if that’s what you’re into.  And you know what, I would love to work at an actual software company, making product, but what really revs my engine is knowing that what I’m doing is ridiculously important to a company trying to fight its way to the top of a market.  That’s my high.  When people around me are using what I made and it’s making their jobs easier and it’s making the clients happier, that’s when I actually feel like I’m serving a purpose.  And I get plenty of that as a second-class in-house unimportant sucky software writing corporate developer.  So Joel, you’re one of the great thinkers of our era in software, but your views on internal software and the developers that write it are misguided, uninformed, and harmful, and this time I have to respectfully disagree.