posted today the gave to the Yale Computer Science Department on Nov. 28th.

In this part he talks about perils of internal software development at non-software shops.  Here's a glimpse,

... New York was the first place I got to see what most computer programmers do for a living. It’s this scary thing called “in house software.” It’s terrifying. You never want to do in house software.

You’re a programmer for a big corporation that makes, oh, I don’t know, aluminum cans, and there’s nothing quite available off the shelf which does the exact kind of aluminum can processing that they need, so they have these in-house programmers, or they hire companies like Accenture and IBM to send them overpriced programmers, to write this software.

And there are two reasons this is so frightening: one, because it’s not a very fulfilling career if you’re a programmer, for a list of reasons which I’ll enumerate in a moment, but two, it’s frightening because this is what probably 80% of programming jobs are like, and if you’re not very, very careful when you graduate, you might find yourself working on in-house software, by accident, and let me tell you, it can drain the life out of you.

If you have the time during lunch or later today, it's definitely worth the read since he does raise some pretty compelling arguments (specially the ones about management and product quality).

I find this interesting because that's one of the things I keep asking about their company: Are you a shop builds software or a shop that uses software?  As a company, If you employ developers to build on "your" software (whether it be for internal use or product), you are a software shop!  If you weren't then why in the hell do you have developers on your payroll?!!?!  A shop that uses does just that, uses the software!  They purchase product X install it on their machine and go on with their merry day doing what the do that makes them money.  The purchasing of the software is just another business expense...that's it, end of story.

I don't know how many projects I've been a part of or heard about that think they need to create a new ORM/programming language/transfer protocol as part of their solution.  All you're doing is adding scope and avoiding the actual solution to the problem.  Now, if you're job is actually to build the next ORM/programming language/transfer protocol, then your "cost" is justified.  If not, then stop what you're doing and start providing business value.