3 Major Problems With the Software Industry

There are three prominent problems in the software industry that bothers me in particular at the moment. Being a part of that industry, I feel somewhat responsible to help shed some light on these problems. I list each problem below, with a proposed solution outlined.

broken

Problem 1. Foot-in-the-door Software

The recipe for creating foot-in-the-door software is really quite simple:

  1. Design a software that can do anything with “a little customization”.
  2. Make it hard to customize. Make every protocol and specification proprietary and hard to understand.
  3. Don’t go anywhere near any standards.
  4. Provide a horde of overpriced consultants to fix all of the above problems, and have them apply the “Ninja Technique (Problem 3)” so that they can stay on-site indefinitely.

Voilá! Now just wait for money to pour in from miserable customers.

Solution: Empower your customers through creating standards compliant API’s and plugin environments with open and commonly used technologies for which problem solvers can be found everywhere and anywhere. Even better, stop creating problems for your customers in the first place. Stop sticking your foot in the door, and focus on creating something that makes your customers the stronger one. They will rely on you all the more for it — and it will be a relationship based on trust, not desperation or despair.

Problem 2. The Green Lights Problem (Unchangeable Bloatware)

Players in the industry still build software that is close to impossible to change or make additions to. It can take months or years between releases, and they buffer up so much change that no-one ever dare (or can afford) to upgrade. This frightens the purchasing department. Big time. As a reflex to this problem, they have (understandably) rehearsed their spec writing to include everything but the kitchen sink — effectively forcing anyone that want to be a player in the industry to create bloatware from day one rendering the software hard or close to impossible to use, as well. A 100 page requirement is not that uncommon(!) 20% of the required features typically end up being used (*). The longer the spec the better, it seems. It means less risk of having to ask for a software change from a broken industry — let alone taking the risk of going through actually receiving it! Purchasing is happy though, they did their best to fight change by getting their little green lights on all checklist points in their gargantuan spec, and then they moved on never seeing the havoc in the wake.

This quote from It’s Learning shows just how bad it can get “We need not concern ourselves with the users, as long as we make money” Meaning that they’ll throw anything into their software to please purchasing, even though it makes the users miserable. (via Ida Aalen and google translate, original post in norwegian here)

Solution: Dear Industry, let’s at least start by creating usable (as in usability), modifiable and maintainable software, effectively showing the customers that we can please both the user and the purchasing department all at once: changes and additions to the spec is possible without a headache, which allow us to keep software functionality concise and to the point. Happy users and happy purhcasing = happy everyone. Even you. Look to lean and agile for your solutions embracing, not fighting change. It’s possible, you know. It just might lower costs and increase your overall software quality, as well.

Problem 3. The Ninja Distraction Technique  (using Tech Jargon)

Traffic ConesThe software industry has spent years (or maybe decades) educating their customers in tech jargon. It’s all a part of the ninja technique of distraction. It is. Really. The theory goes: Keep throwing words such as “Java, JBoss, Caching layers, Multi Tier Software Development Housing Fascilities Campus” at the customers, and you will not only sound very professional, but what’s even better, the customers will soon forget what they really were asking you for, so there’s less of a chance chance you have to deliver.

Imagine being the customer in this scenario: Here you were looking for a a) safe car with b) comfy seats, c) low fuel consumption, d) good stereo sound and a e) large trunk for all your groceries, and suddenly you had a car salesman giving you a primer in everything ranging from the new four layer varnish coating technology to the latest in air-pressured suspension theory and revolutions within the field of fuel injection and what not. You don’t want to hear about that, you want to know if it will hold your coffee cup steady while playing your Mozart in a perfect pitch.

Well, the industry seems to have distracted you from all that.

Solution: It’s about time the industry starts talking about the metrics that the customers can relate to and understand. And more notably, the ones that they need. Let’s talk about ease of use. Let’s talk about performance (can you handle 100 users registrations a second?). Let’s talk about modifiability (can you deliver a medium sized product feature change in 1 week, or less?). Let’s talk about reliability. Is your up-time average more than 99,97%? Will your software automatically restore upon any hardware problems? Can you upgrade our software frequently without involving our tech-department? What is your fix time for bugs?

There is no need to talk about technologies if you can reassure the customer on the real metrics. If you can deliver on these metrics (and deliver you can if you just stop with all the distractions), you would not need to apply your ninja techniques, and our software could be made by an aging brontosaurus for all they would care.

Let’s shift focus onto providing real software solving real problems for real users — injecting relief instead of frustration and hopelessness into this world. (**)

Please contribute with any experiences you have with the industry in relation to any of these problems. Or maybe you have a beef of your own with the industry. Bring it on! We (the players in the industry) desperately need to hear it in order to improve.

Footnotes

(*) This is my personal estimate, based on the pareto principle and experience. However, probably not an unfair estimate given the magnitude of this problem.

(**) Am I trying to convey that we’re perfect in this respect? No. We’re improving all the time.

Tune in to the fourth dimension using RSS or follow me on twitter.com/geirber