Who Really Needs Developers, Anyway?

Either you have too many application developers on staff, or not enough. It's time to reconsider your developer staffing practices, because it's quite likely you've got it wrong.

Do you need a large, dedicated, in-house development team? Or do you need to ax your development team entirely? There are good arguments to be made for both choices, and the correct answer really depends upon what type of organization you're trying to run.

On one hand, you've got a place like Quirky, which has an IT team comprised almost entirely of developers. Quirky is a "social product development" Website that enables regular Joes to become successful inventors by providing them a way to submit invention ideas, collaborate with other users on product design, and maybe get the product manufactured and sold. We recently talked about the developers' role with Nathan Smith, Quirky's Head of Technology, during a live video event about supporting innovation. He said:

The only time we really use third parties is when we have a piece that somebody does really, really, well already and has a proven system and there's no point in us reinventing the wheel. I think the argument for not having an ongoing outsource development program when it comes to the software you're actually going to push out to your end users or use internally day to day is you just sort of have misaligned incentives.

If you have someone that's getting paid hourly and they're done with the project when it's done, they're going to write the code as quickly as possible and get it to you, and then they're gonna wash their hands of it and move onto the next project -- which, sometimes, is fine. But, a lot of times if you're making a really complex system, like our platform, it makes more sense to have someone who's going to take ownership of it.

Then again, you don't want a developer to take too much ownership of an application. In another recent live video event, we spoke to Richard Stiennon, Research Analyst for IT-Harvest. When I asked him for his main piece of advice for any CIOs who want to improve and simply information sharing, he said: "Webify. Don't have proprietary applications for accessing particular pieces of information... You don't necessarily have to make an app for every single device, just let them access it over the Web."

I asked Stiennon if a CIO who adopts that kind of attitude lacks faith in internal developers. "Well, we should," he said. "We should question when internal developers say 'oh no. we have to use this framework or this type of presentation.' You have to really push back and question them on that... At the end of the day, the developers really have you over a barrel. You can't fire them, you can't replace them, you can't outsource it to India, because they're the specialist on their little tool."

Stiennon's main argument was not that developers are greedy, crafty people who will hold their organization captive. His main point was simply that most organizations don't actually need in-house developers -- too much customization is wasteful and counterproductive, especially when you need to be more efficient with less resources.

For now, it seems CIOs are moving towards the "more developers" model. A recent InformationWeek Reports survey discovered that there is an increasing demand for, and an increasing budget for, in-house application developers. As Michael Endler described it in an Oct. 17 InformationWeek story:

What's more, the survey projects this trend will accelerate over the next two years, by which point nearly three-quarters of app developers are expected to be in-house employees. The responses suggest contractors will compromise most of the remainder, with outsourcing left largely on the outside looking in. Businesses, it seems, want not only apps but fairly direct control over their development.

If you are going to have developers on staff, don't waste their time and talent. Don't make them build custom applications if an equally effective alternative is already available for purchase. Don't overload them with so many administrative, keeping-the-lights-on type of tasks that they never have time to actually flex their developer muscles and create the exciting, innovative applications you hired them to make.

A company like Quirky needs in-house developers to build a Web platform and write applications because, ultimately, the company's defining mission is to provide a unique Web platform with unique applications. The company needs the manpower necessary to carry out the iterative development process that's crucial to the business. If providing unique IT services to customers is not your company's modus operandi, then maybe you don't need in-house developers at all. Use existing applications and services, avoid needless customization efforts, hire contractors on an as-needed basis, and keep your IT staff lean and mean.

What side are you on -- more in-house developers, or none at all? What kind of team are you running now, and do you think it's the ideal set-up for your organization?

Outsourcing and regulations require fast turnaround on data, instant notification of security breaches, and impose heavy fines for abusive or neglectful companies. As more companies embed technology into an expanding range of products, new IT jobs in their product development organizations are also being created.

I really liked this part "Don't overload them with so many administrative, keeping-the-lights-on type of tasks that they never have time to actually flex their developer muscles and create the exciting, innovative applications you hired them to make."

I agree that it depends on the size of the enterprise we are talking, for small ones where they need a special job outside of their current staff it will be a good idea to hire contract developers while large enterprise they will use their in house staff, I haven't taken part in the decision process as well, I will like to know what they think.

@Sara - I presume much has to do with the legacy environments and the applications thereof. With today's market driven applications managed outside the organization, that removes overhead. Sure it takes some control away from the enterprise, but with the advent of SaaS, IaaS, and others, they make things very appealing to the decision makers. My two cents.

@Damian I'm hoping for more feedback from people who make staffing decisions too. You mentioned "the removal of some custom applications" -- why are organizations moving away from custom applications, do you think?

I personally haven't been involved in any decision making process regarding in-house developers, but I am seeing a shift in my own organization with respect to system analysts. With the removal of some custom applications and the introduction of some outsourced applications, the need certainly decreases. It seems its becoming more cost effective in some circles to simply pay for, say, a SaaS, than to have an entire team focusing on customization. I'll be intrested in reading some more comments from other individuals who have in fact been involved in the decision making process.

The blogs and comments posted on EnterpriseEfficiency.com do not reflect the views of TechWeb, EnterpriseEfficiency.com, or its sponsors. EnterpriseEfficiency.com, TechWeb, and its sponsors do not assume responsibility for any comments, claims, or opinions made by authors and bloggers. They are no substitute for your own research and should not be relied upon for trading or any other purpose.

Enterprise Efficiency is looking for engaged readers to moderate the message boards on this site. Engage in high-IQ conversations with IT industry leaders; earn kudos and perks. Interested? E-mail: moderators@enterpriseefficiency.com

Dell's Efficiency Modeling ToolThe major problem facing the CIO is how to measure the effectiveness of the IT department. Learn how Dell’s Efficiency Modeling Tool gives the CIO two clear, powerful numbers: Efficiency Quotient and Impact Quotient. These numbers can be transforma¬tive not only to the department, but to the entire enterprise. Read the full report

Now that TGen has broken new ground in genomic research by using Dell's storage, cloud, and high-performance computing solutions, the company discusses what will come next for it and for personalized medicine.

The Translational Genomics Research Institute wanted to save lives, but its efforts were hobbled by immense computing challenges related to collecting, processing, sharing, and storing enormous amounts of data.

Office and personal productivity tools come in a first-class and coach flavor set, but what makes the difference is primarily little things that most users won't encounter. What's the big issue in using something other than Office, and can you get around it?

We really don't want an "Internet of Everything" but even building an Internet of Everythinguseful means setting some ground rules to insure there's value in the process and that costs and risks are minimized.

Google's Chrome OS has a lot of potential value and a lot of recent press, but it still needs something to make it more than a thin client. It needs cloud integration, it needs extended APIs via web services, and it needs to suck it up and support a hard drive.

On a recent African trip I saw examples of the value of the cloud in developing nations, for educational and community development programs. We could build on this, but not only in developing economies, because these same programs are often under-supported even in first-world countries.

VMware's debate with Cisco on SDN might finally create a fusion between an SDN view that's all about software and another that's all about network equipment. That would be good for every enterprise considering the cloud and SDN.

Wearing a bulky, oversized watch is good training for the next phase in wristwatches: the Internet-enabled, connected watch. Why the smartphone-tethered connected watch makes sense, plus Ivan demos an entirely new concept for the "smart watch."

Cloud storage costs are determined primarily by the rate at which files are changed and the possibility of concurrent access/update. If you can structure your storage use to optimize these factors you can cut costs, perhaps to zero.

The Internet has evolved into a machine for drumming up a chorus of "Happy Birthday" messages, from family, friends, friends of friends who you added on Facebook, random people that you circled on G+, and increasingly, automated bots. Enough already.