The Wrong Reason To Hire More Developers - InformationWeek

InformationWeek is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

IoT
IoT
IT Leadership // Team Building & Staffing
Commentary
12/11/2014
09:28 AM
Connect Directly
LinkedIn
Google+
Twitter
RSS
100%
0%

The Wrong Reason To Hire More Developers

Leaders confuse the need to use software to advance their businesses with a mandate to have an internal core development competency.

It's almost gospel: Software is eating the world, so of course your company needs a large internal development staff, and you need to give them a high level of autonomy and responsibility. Right?

Wrong. Most companies delegate far too much responsibility to software developers, who often have little knowledge of -- and less concern for -- the needs of the business.

Many executives, non-technical and technical alike, make the essential mistake of believing that the innovation benefits of software can be realized by hiring rock star developers. The reality is that the quality range of software produced by developers is immense, and the spread gets even vaster as the code gets more complicated and updates pile up over time.

[What's the best way for an aspiring programmer to learn? Read The Right Training Tech For A Tech Career.]

This quality delta is compounded a thousandfold by two factors. First, best case, it is incredibly difficult to identify excellent developers in the hiring process; it is essentially impossible for non-technical hiring managers to identify them, even with so-called "expert" recruiters. Second, almost no one can tell whether software is excellent or not until it has been used in the wild for a decent amount of time. Even with agile development practices, which get software into the wild more quickly, an organization has essentially committed a massive amount of resources to its development staffers before it knows whether they're capable of building anything better than a mediocre product.

There are many examples in the news of this phenomenon making or breaking companies, but the press never identifies the core issue. Take Netflix: The "smart" money was on Netflix-as-middleman getting crushed by content producers. But what investors failed to understand was that Netflix had excellent software strategists, architects, and developers, whereas the content producers did not. And so Netflix was able to deliver good software across an enormous number of platforms (unlike the content providers). As a result it won for long enough to become a content producer itself.

The takeaway from Netflix should not be, "Oh, we should get awesome software guys like Netflix has, and then we'll win." The takeaway from Netflix should be, "Wow, those content providers had a ton of money, influence, and executive talent, and they still couldn't build the right software. Maybe we should be worried about the software we're trying to write internally."

Businesses are paying handsomely for this uncertainty. The 1,117 IT staffers and 889 IT managers in the 2014 InformationWeek Salary Survey with a primary job function of application development demand compensation solidly above that of the typical IT professional. Their base salaries were up for the third year in a row. Make no mistake, we are in the middle of an arms race for developers. Silicon Valley firms and venture capitalists are spending enormous amounts of money to scoop up the best talent, and top software developers are increasingly starting their own companies. The aspiration for developers is to work in Silicon Valley, and for an elite company there.

A miniscule 2% of 528 respondents to the  2015 App Dev Priorities Survey outsource software development.
A miniscule 2% of 528 respondents to the 2015 App Dev Priorities Survey outsource software development.

It has never been more difficult for the average US firm to hire excellent developers, and yet I can't think of a major company that isn't continuing to mindlessly add new dev staff in a doomed quest to build a core competency in development.

The solution is fairly simple. Companies absolutely need a core competency in maintaining, supporting, and making at least minor updates to the software they use internally and provide externally to their customers. They also need strong product expertise, and, specifically, strong technical product expertise, so that they can make sure that their software is excellent.

But they don't need a core competency in developing "greenfield" software. It is much more difficult and risky to build software from scratch versus maintaining well-written code. My advice? First, try to find existing software that comes close to serving your needs, perhaps from the growing library of open source software, and customize it. Failing that, outsource greenfield development to experts.

Get rid of the mindset that software is such a differentiator that you need to code in-house. At one time, it was common for companies to maintain their own power plants, because power was critical to their operations, and they didn't trust anyone to provide it. Some companies still push back against cloud, as if where VMs reside is going to make or break the business. That's clearly wrongheaded, and at some point soon, companies that insist on maintaining their own data centers will be at a competitive disadvantage.

One day, we'll look back to this period of in-house greenfield software development the same way.

Our latest survey shows growing demand, fixed budgets, and good reasons why resellers and vendors must fight to remain relevant. One thing's for sure: The data center is poised for a wild ride, and no one wants to be left behind. Get the Research: 2014 State Of The Data Center report today. (Free registration required.)

Joe Emison is a serial technical cofounder, most recently with BuildFax, the nation's premier aggregator and supplier of property condition information to insurers, appraisers, and real estate agents. After BuildFax was acquired by DMGT, Joe worked with DMGT's portfolio ... View Full Bio
We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Page 1 / 3   >   >>
jemison288
50%
50%
jemison288,
User Rank: Ninja
12/18/2014 | 8:39:51 AM
Re: New home builder vs handyman
@SaneIT -- are you saying that programmers are essentially interchangeable with equal skills, and the differentiator between great greenfield development and mediocre greenfield development is mostly connected to the management of those developers?

I certainly don't mean to say that management is irrelevant (and I think product management is the main thing that screws up greenfield development, not necessarily engineering management, especially since the architecture is rarely done by tech management now).
SaneIT
50%
50%
SaneIT,
User Rank: Ninja
12/18/2014 | 8:32:41 AM
Re: New home builder vs handyman
@JoeEmison, in regard to the specialization I don't think it's so much down to the programmer level that you need to be aware of the specialties.  You need good leaders who can take a team that could either be building yet another company directory or be building the next Netflix and direct their efforts.  I know a lot of brilliant programmers who work on very mundane projects not because they can't do more but because that is what they are paid to do.  You can't just stand in front of them and say "make something awesome" you leadership with the vision and understanding of what they want so that the developers can do what they are best at.
JoeEmison
50%
50%
JoeEmison,
User Rank: Strategist
12/17/2014 | 7:24:15 AM
New home builder vs handyman
An analogy: in construction, we recognize specialties, like the new-home builder, the remodeler of historic homes, and the handyman. We hire the person with the most relevant experience / specialty. But in software development, we tend to make no such distinctions. Organizations routinely take developers who were in charge of maintaining (bug fixes, features) existing software and put them in charge of designing a new system (application, databases, caching) from scratch, considering all of it "software development". My point in this column is to suggest that at the very least, we should recognize the significant experience and skill it takes to build great, maintainable systems from scratch, and because we tend to do that infrequently, outsource those tasks to top-tier talent with relevant experience.
JoeEmison
50%
50%
JoeEmison,
User Rank: Strategist
12/17/2014 | 7:16:08 AM
Re: Devs in the house
I work "in house", and I certainly respect myself. It is in no way true that I have no respect for people who work "in house". You are doing what far too many people in comments sections do: failing to recognize any kind of nuance or distinction, and instead only seeing the world in broad, sweeping generalizations. As I said in the column and in these comments, it is easier to outsource to get top-tier talent than to hire it. I don't think this is a contentious point; just look at the market. And you will get better results with greenfield development (which has the broadest range of possible results) with better talent.
TerryB
50%
50%
TerryB,
User Rank: Ninja
12/15/2014 | 2:19:27 PM
Re: Devs in the house
You seem to have very little respect for the skills of anyone that would want to work "in house". If internal IT skills are so lacking that you can't choose a decent programming framework, just exactly how would would you evaluate a vendor who says they have such skills?

Besides, as far as delivering a quality application, it doesn't matter whether you use Ext JS or Angular. It might matter to the OUTSOURCER, because all their skills might be in one place or another. But either can deliver a quality product if done by a skilled developer.

I get your point about scope of deployment. If I was creating an app that allowed consumers to buy Big Mac's at McDonalds with your phone and I wanted to monetize, I'd certainly bring in help that had done it before. But even what Vail Resorts did was not "business critical" with that app. If they wrote inhouse and app flopped, I think just as many people would still go skiing in Vail. Doubtful they had anyone at that point who had ever written a mobile app in their life. And they had no way to make sure they could hire that skill either. So having outsourcing do that app was only practical approach for them.

The interesting part of Vail Resorts is the decision to staff internally now, what exactly did that mean? Is that just one guy with some experience in mobile, who could easily look at existing solution and run with it? Or are talking about a staff of 10-20 with Project Managers, Testers, Coders, etc. Doubtful a ski resort had much of an IT staff to begin with, at least from developer point of view.

You can paint contracted help anyway you want but the fact remains it is expensive compared to what you pay internal people. That's why your discussion branches into areas like finding and hiring internal people, and quality of final delivery. Without those type of (potential) softer/hidden costs, it is no comparison at all.
JoeEmison
50%
50%
JoeEmison,
User Rank: Strategist
12/13/2014 | 7:50:23 AM
Re: In other words...
I've never known an organization in the US in which it was easier to terminate an employee (even for cause) than to terminate a work-for-hire contract. You don't sound as if you've ever had to terminate an employee; employment lawyers have far better grounds in an employee relationship than a contractor relationship. Just ask a lawyer.
jries921
50%
50%
jries921,
User Rank: Ninja
12/12/2014 | 11:08:59 PM
Re: In other words...
If it's easier to fire a contractor (who can afford lawyers and might well be in a position to make the occasional sweetheart deal) than it is to fire one's own employees, then the organization has bigger problems than outsourcing can possibly solve.

And i've already noted that in at least some cases, outsourcing will be more economical than doing one's own hiring; but I doubt it will happen nearly as often as its boosters claim (from whom one might get the impression that the optimal personnel policy is to outsource everything but management).

 
JoeEmison
50%
50%
JoeEmison,
User Rank: Strategist
12/12/2014 | 8:28:32 PM
Re: In other words...
You assume that by keeping development in-house, you'll have good technical oversight, but by outsourcing, you won't. That's a straw man; whether or not you have good technical oversight is a separate situation than whether you outsource. And from my experience, it's easier to have good technical supervision when outsourcing, because it's easier to fire your outsourced development firm than it is to fire through HR. I also strongly disagree that a good criteria for creating a new position is whether or not it's enough work for a full-time position. This again privileges in-house over outsourced for no logical business reason, and again, that has significant opportunity costs and significantly impacts a company's ability to focus and execute efficiently.
ChrisMurphy
50%
50%
ChrisMurphy,
User Rank: Author
12/12/2014 | 7:56:32 PM
Re: Devs in the house
I can see that, gets back to the earlier discussion of what's maintenance versus dev. The greenfield distinction is the key. Thought provoking piece, Joe. 
JoeEmison
50%
50%
JoeEmison,
User Rank: Strategist
12/12/2014 | 7:39:52 PM
Re: Devs in the house
Chris-- I would argue that Vail did exactly what I'm suggesting: outsource greenfield development, and then in-house the maintenance of the application on an ongoing basis.
Page 1 / 3   >   >>
Slideshows
Top-Paying U.S. Cities for Data Scientists and Data Analysts
Cynthia Harvey, Freelance Journalist, InformationWeek,  11/5/2019
Slideshows
10 Strategic Technology Trends for 2020
Jessica Davis, Senior Editor, Enterprise Apps,  11/1/2019
Commentary
Is the Computer Science Degree Dead?
Guest Commentary, Guest Commentary,  11/6/2019
White Papers
Register for InformationWeek Newsletters
Video
Current Issue
Getting Started With Emerging Technologies
Looking to help your enterprise IT team ease the stress of putting new/emerging technologies such as AI, machine learning and IoT to work for their organizations? There are a few ways to get off on the right foot. In this report we share some expert advice on how to approach some of these seemingly daunting tech challenges.
Slideshows
Flash Poll