Development cycles are spinning out of control
Software development used to be measured in months——now it is measured in weeks, days, even hours. This rapid acceleration has sparked some real tension between five different constituents with five different sets of objectives and expectations that no longer work in sync: software developers, customers, prospects, customer service and marketing. Note: I always leave sales out of these discussions. Why? Sales ALWAYS wants more functionality; they always have a white whale out there, one that would buy a million dollars worth of product TODAY if only we had “X” feature. (Not that there’s anything wrong with that. It’s Sales. And, like the scorpion that stung the frog carrying him across the river, this is something they can’t help themselves from doing. It’s their nature.)
Software developers are essentially a conservative lot that have been turned on their collective heads by market forces and ready access to massive compute power. Even as recently as the days of client/server computing, most software developers were reasonably conservative. They stuck with an operating system that they knew and understood (I’m looking at you, Windows XP) and they tried to pace out software releases along an annual release schedule.
They could do so because 1) the market did not demand a faster pace; and 2) they lacked the resources to move any faster. Sure, your large commercial software houses (Microsoft, Oracle, SAP) had access to test and Q/A platforms, as well as gobs and gobs of development computers. However, most in-house development teams lacked these specialized resources. So, they’d often be testing on their desktop computers and deploying directly to production. In such a world you had to be really careful about your software releases.
So, by necessity, you simply deployed less often.
Customers tended to be comfortable with this slower paced process. They had a devil of a time getting to a stable, working system, so they were more than happy to delay the pain of upgrading. The real enemy was the duopoly of Marketing and prospects.
Part of Marketing’s job is to stay ahead of the competition and to carve out a comfortable market segment for the company, as well as to create unique partnerships with the important vendors in your overall market. This means that Marketing is constantly on the hunt for new features and new platforms.
You are probably hearing this right now, as your marketing team insists that you need to get onto iOS 8 as fast as humanly possible in light of Apple’s newly announced iPhone 6.
Prospects operate in a similar fashion. Since they have not yet purchased your product, or gone through the pain of an implementation, they tend to be biased towards new features. Thus, in order to close the deal, they want developers to add a bunch of features, or make customizations that are unique to them. Unfortunately, if they are bringing enough dollars to the table, their voice is going to carry a lot of weight.
If you are software company in this spot, I’d suggest that you re-read “Crossing the Chasm” for a fulsome understanding of the long term risks of building new features across market segments.
So where does that leave us today? Marketing and prospects, the world is your oyster. Engineering, Customer Service and customers, well…
On the one hand, we now have ready access to tons of computing power, storage and networking. There is simply no excuse for an engineering team, no matter how small, not to have separate development, test, and production platforms at their disposal. This point probably deserves a discussion all its own. For now, let’s just all agree that it is much easier to get access to all of the computing power that you need at a relatively modest cost. This easy access to hardware has come at a great cost: the proliferation of platforms, databases, browsers, mobile operating systems, frameworks, libraries and languages. This causes massive instability for developers and customers. Developers have their hands full, juggling feature development for their own software with the demands generated by marketing, prospects and, to a lesser extent, customers.
Adding to this problem, every change by one of THEIR suppliers, as per the list above, requires code changes and feature changes (at least potentially). And those suppliers have their OWN pressures from marketing, prospects and customers.
So who suffers?
Developers, customers and Customer Service are the biggest losers in this game. The market is conspiring against them.
Platform instability can put massive pressure on developers. Customers get frustrated because things simply “stop working”. Sure, you can post a big sign on your web site that says that your software isn’t compatible with iOS 8. That’s not stopping your customers from updating. In fact, some OTHER product that they rely on might just REQUIRE them to upgrade. So they get angry and call Customer Service, who soon gets overwhelmed with similarly frustrated customers. And just how is customer service supposed to keep up? It’s a given that they need to thoroughly understand their own product, but just how many third-party components do they need to master in order to stay on top of customer problems? There simply aren’t enough hours in the day.
So what can we do?
Well, it take two to tango. And your dance card just filled up.
You need to be running the show. Bite the bullet and scale back the number of different platforms and features. Be realistic about your timelines. If you want to add something, then you’ve got to cut something from the project plan over a given block of time. Understand that you can’t just hire additional resources in the short-term and “jam it in.”
I know that you want use the latest and greatest NoSQL database for the new product. Take a deep breath and think about how you are going to support this from a platform and operations perspective. Simplify, boys and girls, simplify.
Take a hard look at the features and functions that you really need to be competitive. A/B testing works great with marketing campaigns, but it is a living hell for developers to add functionality that does not move the needle.
When you are pushing hard for that custom feature, remember: soon YOU will be the customer that is getting frustrated by changes that you didn’t ask for. Think hard about whether you REALLY need that customization.
The following piece of advice is going to irk you like mad: I don’t care.
Yes, you paid good money for a product that isn’t working. Yes, you are frustrated that customer service can’t magically diagnose and fix your problem. I get it. Now stop crying and get to work. If you want your problem solved then you are going to have to act like you are part of the team and do as much digging as you can to HELP customer service diagnose and fix your problem. Google it, for heaven’s sake. Take meaningful screen shots. And, if it’s all too much for you, then consider dropping the product and going with another vendor.
You have the toughest job. But if I can give you one simple piece of advice, this would be it: Try to understand your customer’s sophistication level. Don’t ask them if they tried rebooting if they come armed with screen shots and database traces when they call.
This is going to get worse before it gets better folks.