Reduce waste in software

The truth is that most software sucks. It is hard to use. It frequently takes longer to build than originally budgeted. And it rarely meets the business objectives. In fact, over 70% of Digital Transformation efforts fail. Considering that 7.3 trillion dollars are expected to be spent on digital transformation over the next 2 years, that’s a lot of money wasted. That’s compounded by user frustration, missed outcomes, and annoyed colleagues.

This is a big reason why the majority of businesses fail in their first 5 years and 90% of Fortune 500 businesses from 50 years ago either don’t exist today or have fallen off the list.

It all boils down to this: there is a **lot of waste** in software today.

Software waste falls into three primary buckets:

1. Wasted Features
2. Wasted Time
3. Wasted Code

Wasted Features

A Standish Group Study highlighted that 64% of features in enterprise software are never or rarely used. Shockingly, only 7% of features are always used.

That’s bonkers.

By the time something big has been built, the launch is very, very unlikely to be permanently rolled back no matter what the metrics say.” – Carson Forster, Data Scientist Twitch.

This quote is at the heart of a lot of feature bloat. Once something has launched – even if the data shows no one uses it – it is likely to stay alive.

This is why it is critical to figure out what is necessary early in the design cycle with real user feedback, as opposed to waiting until a feature is launched and hoping for the best.

There are many negative effects of launching features no one uses.

It takes time to build said feature. That time costs money. As well as the lost opportunity cost.

It takes time and energy to maintain. The more features that are added, the more complex the code base. This introduces the risk of bugs, hurts team morale, and increases the cost of maintenance.

And last, but not least, it adds a visual tax on users. More features means a more complex system – no matter how good the overall user experience is. And if like most enterprise products, the inclusion of new features is tacked on rather than thoughtfully added to the User Interface, this can be seriously damaging. A pre-eminent UX designer, Jared Spool, calls this the Experience Rot.

Running lightweight experiments to test and validate potential solutions early in the process will root out many of these issues before they become set in (code) stone.

Wasted Time

Building things that no one wants is expensive to the business and taxing on the end users, but it also has a negative effect on the team building the software.
People want to make things that have an impact.

They want their software to be used and loved. No one gets up to build mediocre software.

Launching lots and lots of features, but dealing with a mountain of bugs and low engagement is not a recipe for maker happiness.

And if there’s one topic dominating the business headlines of the last year it is “the Great Resignation.”

Over 4 million Americans a month are leaving their job voluntarily and over 55% of workers plan to leave their job this year. 

Now, more than ever, talent is critical and hard to come by. And a big part of this is creating a meaningful impact.

Another thing to look out for is the work environment that your team exists in. Makers want to make it! Can you limit the meetings? Can you limit the unnecessary tools and overhead?

Wasting the people who build the software’s time will result in more staff leaving. Plus it will be difficult to recruit and retain quality talent, of course, this is a significant cost to the business. All while having a software product that may not actually lead to business results.

Wasted Code

Features that aren’t used result in team members’ time being wasted, all resulting in higher costs and worse business outcomes. Another area that can increase cost without improving the top line is wasting code – a very common issue that plagues software projects.

Many talented engineers over-optimize code for things that don’t need to be built in the first place.

This is not to say we should be writing horrible code. No, that is a big issue for maintainability, but there is a big difference between over-optimizing something and writing easy-to-maintain software. 

Plus, you can always optimize code once the feature is validated. You should not be spending multiple days or weeks perfecting the optimization if you don’t even know the feature is going to be used.

—

This is why at InfoBeans we focus on reducing waste in software through rapid experimentation.

We have worked with hundreds of companies to deliver quality software that exceeds user goals and business expectations. And we’ve done that in timelines that astonish our clients.

How do we do this?

It starts with our process Experiment Driven Design. We take your big digital ideas and break them down into smaller experiments. In each experiment, we test our work by interviewing real people that match your target user base. We infuse this user feedback into the product. This means we only invest more after we have increased our confidence based on feedback from users, not just stakeholders.

Take for example a major South American Petrochemical company that was beginning its digital transformation effort. We had only 8 weeks to launch a customer-facing dashboard that needed to solve multiple user pain points. To do this, we strategically prioritized our features and were thoughtful about our integrations. For example, instead of costly and time-intensive SAP integration, we were able to connect our pilot system to SAP through automated emails that our code read, took out the relevant data, and inserted into our system’s database. Once validated, future sprints would enable an automated system to be built.

We are here to reduce waste for your organization. Check out our work with software pilots and if you’re interested, drop us a line.