Mainframe Blog

Are You “Jumping the Shark” with that New Software Feature?

2 minute read
Mark Schettenhelm

Overview: Applications should be modified to stay current and live up to their original mission of solving a particular problem, not solely because they exist and have users. Have you “Jumped the Shark” with your new features?

You may be familiar with the term “Jumping the Shark.” If you aren’t, let me quickly explain. It is used for television shows that reach a point where they are in a rut, and to break out, they do something that is dramatic, but isn’t authentic. Something crazy the show never really recovers from. It came from a “Happy Days” episode where Fonzie actually jumped a shark… on water skis. Ever since that point long-running shows are watched for when they, too, “jump the shark” and never recover.

This concept is useful I feel in looking at application development. At what point do you have something that is perfectly good? Yes, you can add more, but should you? Where is the point you start adding features that don’t provide value?

Here are some questions to ask when considering adding a new feature:

  • Who is asking for this? We need to know where the request came from, so we have someone to speak with and gain an understanding of the request.
  • What problem does this solve? Getting an understanding of the need will help us in knowing how best to respond. This leads to three different questions with their own paths:
      • Is it still a problem? It may be that when discussing the problem, you find it is no longer an issue.
      • Is there another way to solve the problem? Are there existing features that can be used, if so, then why weren’t they used?
      • Is this a problem we should solve with the application? This is a very big question, but one that is rarely asked. You can acknowledge that it is a problem, but not one within the scope of this application to solve.
  • How does this affect the user? Is this a minor, occasional annoyance or a real blocker for them? If it’s minor and occasional, we may not want to add a lot to the application for something that is really of low value.
  • What is the total satisfaction with the application? What percentage of users are being well served by what we have? Will we be adding complexity for the sake of an additional percent or two? Is that worth it?
  • Does the proposed solution fit with our vision for the application, or is it actually something else we are trying to add on because of convenience? Will it add tech debt?

Applications need to start with a clearly defined of how it will solve an existing problem. They should be modified to stay current and to better serve this mission, not because they exist and have users. Have you “Jumped the Shark” with your new features?

These postings are my own and do not necessarily represent BMC's position, strategies, or opinion.

See an error or have a suggestion? Please let us know by emailing blogs@bmc.com.

BMC Brings the A-Game

BMC works with 86% of the Forbes Global 50 and customers and partners around the world to create their future. With our history of innovation, industry-leading automation, operations, and service management solutions, combined with unmatched flexibility, we help organizations free up time and space to become an Autonomous Digital Enterprise that conquers the opportunities ahead.
Learn more about BMC ›

About the author

Mark Schettenhelm

Senior Product Manager for BMC Compuware ISPW, Mark has more than 35 years of experience in the IT industry. In his 30+ years with Compuware, Mark has been instrumental in helping to bring mainframe solutions to the forefront of the industry.