SmoothSpan Blog

ba·lo·ney 2 also bo·lo·ney (b -l n ) Slang. n. Nonsense. interj. Used to express disagreement or exasperation.

Recently, I was doing something on LinkedIn, and it asked me to endorse various people’s skills like it often does.  One face in particular popped out at me:  Anders Hejlsberg.  I’ve known Anders for many years, so I immediately had to check what it was about.  In this case they wanted me to endorse that Anders knows something about Software Engineering.  Unfortunately, it was a simple Endorse/Don’t Endorse interaction, because I would like to have said that Anders knows about as much about Software Engineering as the Pope knows about Catholicism.  You see, Anders is a Technical Fellow at Microsoft.  But beyond that, he is one of the most brilliant Software Engineers I’ve ever known.  I met him when I was VP of Engineering at Borland and he was the guy that built Delphi, or Turbo Pascal as it was known when I first came to Borland.  He went on to do C# and a whole lot more for Microsoft after leaving Borland in 1996.  Not only is he a brilliant Software Engineer, he is also one heck of a nice guy.

By now you’re wondering, “What does Anders Hejlsberg have to do with Overseas Development Teams anyway?”

Let’s start with why I even bring up the overseas subject.  To put it simply, I needed to pen a rebuttal to Jason Lempkin’s Wall Street Journal article which says essentially that all SaaS companies are probably going to have to have an overseas dev team because its just too hard to hire talented Software Engineers.  In fairness to Jason, he did say “probably”, but he said it so softly it’s clear he doesn’t mean it.  I disagree violently with the conclusion, to put it mildly.

The thing is, most software companies go about developing software all wrong.  They get pushed in all sorts of directions when people who don’t know much of anything about Software Engineering (i.e. non-technical CEO’s, VC’s, and the like) insist things be done a certain way because someone else they’re familiar with did it that way and succeeded.  There may be limited correlation, but there is absolutely no causality.  It’s not like we technical types have a monopoly on that stuff, I’m sure there’s plenty of Technical CEO’s telling their sales and marketing people similarly poorly informed things.  But the thing is, it happens a LOT more often to the technical types.  Plus, we techies often don’t have the backbone and interpersonal skills to stand up very well when a CEO or Board Member gets up a good head of steam about some issue.  Sometimes having technical leads who can’t stand up and disagree is intentional.  I would say that in over half the VP of Engineering jobs I’ve ever interviewed for they were looking for someone who would demurely take stone tablets from some other source–product management, sales, the CEO, or some “visionary”–and just get it done on time and one budget.  And by the way, do it quietly and without disturbing the other functions.  Needless to say, I was “over qualified” for those positions.

A lot of companies do a lot of things wrong, but Software Development is different.  It takes longer to build software.  It’s harder to change direction at the last minute.  And by the way, did you notice?  They’re called “Software” companies.  They’re not called “Sales” companies, “Marketing” companies, or “CEO’s best notion of the moment” companies.  It’s important that you actually be competent at building software in order to have a real “Software” company.

I was recently reading over a list of startup advice (you know how those numbered lists grab the eyeballs) a VC had put forward on Facebook as being excellent.  I got as far as #8:

8) Should you have a technical co-founder if you are not technical? No. If  you don’t already have a technical cofounder you can always outsource  technology and not give up equity.

I quit reading in disgust so I could go on to see just exactly what sort of software this guy builds.  Mostly, he seems to have parlayed a pretty basic web site into a sale to TheStreet.com.  From there, he’s mostly in the business of telling everyone else how to succeed.  There are so many of these Dale Carnegie types out there these days.  He does not appear to be a Software Engineer, though perhaps he has played one on a TV show somewhere.  This stuff makes me nuts.  Companies that think software is easy to build.  A venture ecosystem that needs to invest in lightweight products because the founders have to pay to get it built on their nickel.  CEO’s that couldn’t care less about building something that can actually change the world, they just want to throw something out there as cheaply as possible so they can spend more on this month’s lead generation.  Bubble riding, in other words.

Whatever happened to the days when people actually had to build something of note?  Something that might change the world, even a little bit, and not yet another eyeball aggregator?

Let’s put that rant aside and get back to the question of whether you will have to have an overseas dev team to scale.  I will put my stake in the ground thus:

You have a choice for your software company:  you can either choose to be excellent at building outstanding software or you can choose to build adequate software cheaply.  The latter path will ultimately be even more expensive than the former, but you’ll be left holding junk instead of a real product.

I’ll warn you I’m being very polite when I talk about software being “adequate.”  Software is hard.  It is the most complex stuff we humans build, at least until we start building organisms from scratch by tinkering with DNA.  Many things that people say are harder are basically software, things like CPU chips.  There’s this little problem in the software world–we don’t know how to get lots of Software Engineers to be able to work effectively together.  There are entire disciplines such as Agile Programming that try to deal with this problem.  We’ve known about the problem almost from the beginning of software.  It was well articulated in the relatively ancient Brooks classic, “The Mythical Man Month.”  It turns out, we’re only good at getting 7 to 10 developers working smoothly together.  Any more than that and you’d better be able to break the software down into modules that are very independent.

If that’s the fundamental limit, how do you build great software?  Here’s a hint:  you can’t do it by hiring more people onto the team.   Instead, you must focus on building great software with fewer better Software Engineers.  You must focus on breaking down the software into modules that work and play well together, something that is also very hard to do and can’t be offshored.  That’s hard core architecture that takes brilliant Software Engineers communicating well with all the groups.  I have never seen a product module that couldn’t be built with about 10 engineers provided they’re the right 10 engineers, they’re well managed, and they’re operating in a culture that supports their needs.

Anders, back in the day, built the Pascal software he is famous for almost by himself.  He had a little help, but surely not a giant team half of which was located overseas.  I have done the same with every product built over my career.

When I took over the VP of Engineering job at Borland, it was the darling of the software world.  We had our share of problems, and one of them was profitability.  I was directed to make cuts.  It didn’t take me long.  I zapped all the consultants I could find and reduced the maximum team size to 10 developers or so.  Not one single product slipped schedule as a result of it.

So what’s the deal with this big overseas software push?

In exchange for making the acknowledged weakest link in software development (communication) much worse, we get to hire lots more people.  At one point, Oracle would trade 2 open reqs overseas for 1 open req here on our shores (Redwood Shores to be exact).  They discovered over time what a bad idea that was and ended the practice some time ago.

Companies the size Jason suggests must go overseas, $3 to 4M in ARR, are still way too small to need to go overseas.  They’re still finalizing fundamental architectural underpinnings.

I can already hear the refrain, “That’s nice, Bob.  But I can’t hire enough good Software Engineers, what else can I do but go overseas?”

If you can’t hire, and I don’t doubt there are companies that can’t, you need to look much closer to home to find the problem:

–  Perhaps your company doesn’t value developers and act like the “Software” in Software Company matters.

–  Perhaps the head of your engineering group is not an inspiring figure.  Will walk-on-water developers follow her or not?  Does she know lots of walk-on-water developers who she can bring on?  Why not?

–  Perhaps your product vision is just not interesting to walk on water developers.

I’ve seen all of these problems in varying degrees at various places I have visited.  I went to a video ad company one time that was proud of the density it could pack developers into.  They had long benches and developers were literally shoulder to shoulder.  There was a strong “no telecommuting” policy in place on top of that.  Sales and marketing had conventional cubes, by contrast.  I wonder if management in that company was aware that software development requires intense concentration and focus?  In the heyday of Borland, each developer had their own private office.  Close the door and you could get some serious work done.

By the way, amidst all the hand wringing about there not being enough visas (more evidence we can’t hire enough developers and we must go overseas!), there is more than one study out that says it’s all a sham.  We are graduating more STEM graduates than we can even put to work.  Most of them don’t stay in their field and wages have been stagnant since 2000.  Does that really sound like a market where you can’t hire developers?

I have interviewed at companies where the developers begged me to come on board and save them from Sales and Product Management.  They wanted to be released from dealing with one unrealistic deadline and shoot for the moon set of specs after the other, because they were failing at every single one.  They had no voice in setting any of it up.  I wonder if the VP of Sales turned CEO set his sales quotas up to be unachievable time after time?  If he was, Sales was no doubt failing there too.

Too many customer demands to keep up with?  Hogwash (time for a word other than “Baloney”).  Build an architecture that’s intended to keep up with customer demands.  Build one that is customizable at the outset.  Salesforce did.   I ran engineering for Callidus Software through their IPO.  That companies processes sales compensation for the biggest companies in the world.  If you don’t think sales constantly fiddles with comp plans and that every company does it differently, you don’t know that market.  Our differentiator was that we had the only product that could deal with those customer demands and still scale to the levels giant companies like Sprint and Allstate needed.

Let’s wrap this up.  We will probably agree to disagree, but I want to summarize.

Good software is not expensive to build nor is a good software team hard to hire for.  The reason is simple–you only need 10 really good people to do almost anything.  Once those 10 are working well, start thinking about how to modularize your software for the next 10 person team.  You can start to get real business-changing things done with a lot less than 10 too, that’s just the maximum.

If you have any doubts, try tearing apart the financials for Salesforce.com.  They have managed to build the world’s most successful SaaS company with relatively few developers.  Fewer than their peers according to the numbers: the percentage of expenses that go to R&D is small compared to many other SaaS companies.  The architecture of their product is rich and sophisticated.  That didn’t happen by accident, it happened because they understand what I’ve been trying to say here.  They hired for quality, not quantity.

Bad software, on the other hand, is very expensive.  It is expensive because you’re throwing a wall of bodies at a problem that cannot be solved by a wall of bodies.  They will build something that is ultimately unsatisfying and unmaintainable.  They will not produce good architecture or good user experience.  They will not produce sustainable competitive advantage in one of the few areas software companies can have such advantages.  They will fail and your customers will be unhappy.  Your competition will love it.