How Apple and Google ruined software development for the rest of us

Consumer companies such as Google and Apple have adopted increasingly rapid release cycles, and now corporate IT departments are faced with similar expectations. Here's how to adapt.


Once upon a time, serious IT leaders could sit in a conference room with their business and executive peers, and discuss software development and implementation cycles that stretched across a number of years. A major ERP implementation that spanned half a decade could be proposed without anyone raising an eyebrow, and timeframes in the 18-36 month range might even be considered quick implementations. Walk into a boardroom now and propose a five-year software project, and you'll likely be laughed out of the building.

The Google and Apple benchmarks

One of the defining technologies of the past decade was the consumerization of the smartphone and the associated rapid development and release cycles of smartphone hardware and software. Each year brings a parade of new and different devices, combined with OS revisions that present dramatic visual changes and hundreds of functional changes.

It may be an argument that makes technologists cringe, but we're increasingly hearing "If Google can develop three new hardware platforms and launch a completely revised mobile OS in eight months, why can't I get my CRM in a similar timeline?" Whether these comparisons are legitimate might make for an interesting discussion during happy hour, but the fact remains that corporate IT departments that propose massive, multi-year timelines are going to be compared with consumer development cycles.

Rapid innovation

One of the silver linings of more rapid development cycles in the consumer space is that most internal "consumers" of corporate IT are growing more accustomed to rapid, iterative development. Every employee who has owned a popular smartphone has seen a favorite function or a favorite app that's arrived on the scene with limited functionality or a collection of bugs, which then quickly evolves and improves. Some suggest this is a license to deliver poor quality software and fix it later, a tactic that should only be employed in the most dire situation. Rather than excusing quality, rapid innovation should allow you to take a "minimum viable product" approach to delivering functions.

In the past, huge implementations would take on large chunks of functionality and deliver a complete system over a long timeline. Due to changing expectations around time and functionality, it's now possible to deliver partial "chunks" of functionality that evolve and integrate over time.

While your users will accept a minimum viable product, they'll still demand a full-featured one, and it is incumbent on IT to carefully manage scope. All the careful work you've done shifting thinking from long, feature-rich releases to rapid releases with minimum functionality will be quickly undone once you start accepting additional scope.

Becoming Agile (carefully)

Agile, or one of the many similar rapid development approaches, is frequently cited as the panacea to demands for a more responsive IT organization, and it's certainly a component of the overall objective. Being successful with Agile requires far more than a few new tools and fancy words like scrum, and in the worst case Agile is the excuse for shoddy documentation and testing and an enabler for a poor end product. Even the best methodology will never save a poorly managed development organization, so if you're expected to produce quality code on a rapid cycle, ensure your people and vendors are all up to the task.

Opting out

One interesting and often viable approach to the increased expectations on internal IT is to opt out of the implementation business entirely, and transition all your IT to cloud-based services and external organizations. This approach is not possible for every organization, but increasingly even fairly large businesses have IT staff in the single digits and nary a data center or developer anywhere in the company. You may have decades-old custom code that can be transitioned to a cloud platform, or even transitioned to a vendor. Just ensure that the company absorbing your burdens is capable of delivering to your expectations, and has financial incentives and penalties in place to keep them honest.

Many in IT may miss the days of multi-year development and implementation projects, where massive infrastructure and functionality were built and eventually deployed to great fanfare. While these projects do still exist, most of IT's work is transitioning to rapid, iterative development. This transition is not new, but the increased prevalence of consumer devices that have major releases on a biannual or even quarterly basis has set the bar, and as IT leaders we need to adapt, or be forced to do so.

Also read


Patrick Gray works for a global Fortune 500 consulting and IT services company and is the author of Breakthrough IT: Supercharging Organizational Value through Technology as well as the companion e-book The Breakthrough CIO's Companion. He has spent ...

Venkatesh Jayaram
Venkatesh Jayaram

With hunger for technology, design complexities and time to market such challenges are expected. Whoz to be blamed for the situation???


1) Fast, cheap, good.  You only get two.  Same as it ever was...

2) Corporate consumers fail to even remotely understand the amount of infrastructure and other development resources Apple and Google have already sunk and how much they can throw at a project.  Something almost no corporate IT departments are allowed to do.

Julian White
Julian White

Christ if/when I get into manufacturing, I'm gonna come out with large releases that are backwards compatible and upgradable.


Getting pretty tired of hearing about Google and Apple. The most poignant sentence fragment in this entire article to me is "ensure your people and vendors are up to the task". Because until organizations are willing to commit the money and resources to building my development team and platform into the 1st Mechanized Army that Google and Apple have? I don't want to hear anything about major releasing on schedules that can be supported by Google and Apple.

M'kay? Let's see what those companies release when they have to fight tooth and nail for every development tool purchase they get, or when they have to spend half their time writing their way around a company accountant who won't pay for per seat or per device licensing and so forces the team to leverage single user copies of software on a server? Or how about what happens when their dev team members have to jump out of their development sessions to go crawl under some end user's desk to re-seat a video card or sit there showing users how to refresh a DNS cache or flush temporary files because the browser won't update page views. Huh? Then what?

I agree with this article and what it says things are moving towards. But as someone who just walked from a company that was too tight fisted and obstinate to invest in its infrastructure or development that now is watching a cloud services company learn that pride is a poor substitute for intelligence while nerfing its server stack, tripling our response time on service issues, and refusing to even discuss the continued development and maintenance of the company's internal codebase, I have to hope that someone else's company has the common sense to remember and apply Clint Eastwood's logic to themselves. "A man's got to know his limitations". CEOs are not exempt, and yes that DOES apply to dev release too.


GOOGLE is slowly but surely becoming the Gestapo of the internet.

YouTube is a perfect example of Google placing their foot on my neck...

...I had two videos up on youtube- the both got taken down by youtube

due to copyright issues.  Meanwhile, many other folks have tons of

full-length movies and episode series shows up on youtube!

Users must also have a gmail account in order to use youtube.

Upon signing up for gmail, you're automatically signed onto Google+

WITHOUT YOUR CONSENT. Google+ is a Facebook-wannabe.

Who owns youtube, gmail, and Google+? G O O G L E.  FK Google!

How much money does GOOGLE pay techrepubic

to edit and censor this comment, we'll soon see.



For THOSE kind of companies I have only two words: Code Spaces

Editor's Picks