Finding The Sweet Spot.
The term the sweet spot has its roots in sports. As legends go, each bat, club, mallet, or racket had ever so slightly different mass distributions, which gave each one a slightly different center of mass. If the athlete could find the exact location of that center of mass, more energy would transfer to the ball for a cleaner hit. So, if the athlete found that perfect bat that fit with their swing, they had an almost mythical advantage. It wasn’t easy to make this almost magic connection, so when they found their special bat, they were very territorial. Some even going so far as to name their bat and not let others use it.
Most players (presumably) focused on aiming the bat more accurately. The “by the book” ball players focused on working their muscles and hand eye coordination to the point of perfection. They would rapidly iterate from unaltered bat to the next unaltered bat as needed. Hunting for that one special bat that fit their swing. However, other crafty players altered the bat by shaving off some of the “extra” weight, or adding a little “missing” weight, thus showing there is always more than one way to address a problem.
Awesome…Thanks for the Sports Legends, I Guess?
Now that I am done thrilling you all with the near totality of my sports knowledge, you might be asking: “What does this have to do with software or operations projects?”
Well in a agile software build with a lot of rapid iterations, it’s easy to build up a lot of useless mass on a project. As customers and users get rapid ideas and their new tiny features get built on top of the MVP(Minimum Viable Product), some of the added features can fall by the way side and become unused. They end up by all appearances as vestigial organs. In a few recent projects the DevSecOps teams ran into that very problem. We noticed as we were continually integrating changes into the system that there were many previous features out there that looked like they were no longer needed. We had great line of sight on the users, and we could see the data. So, we got a pretty solid idea on what was and was not being used. Unlike baseball, it’s not against the rules to remove extra mass from software applications or projects. Its rather encouraged; so, we decided to do some experimenting.
The “by the book” developer might leave the extra mass alone and just work with the application as it is. They would focus on training and making the users better at avoiding the seemingly vestigial features. This would be analogous to “working on their swing” they would focus on making sure the features they personally needed were up and running. That focus is something we can use to benefit everyone. Training and giving the users additional skills is a great and well tread plan and, one we execute regularly. It does not however, help us remove the extra mass, so it isn’t the right tool for the job. Some “by the book” developers/mangers might treat these unused features as a major code change, and try and schedule user interviews, planning sessions, and the like before removing them. In our case, the work load is just too small to warrant a large scale investigation. We started a few small investigations and reached out to a few trusted users. Quickly it became apparent that avenue wouldn’t bare guidance.
When our team started asking the customers’ users about the vestigial features, we didn’t get a clear answer. It’s a bit cliché, but true; often times engineers didn’t want to be the one on record saying “yes: turn that feature off,” when someone else might use it. Thinking about the problem we talked amongst ourselves and concluded that turning off these features would have almost no impact. The data would still be stored (even though it appeared no one stored any data in these records). We figured out that turning on and off any of the features in question was significantly less than an hour effort each. One of the benefits of doing small iterations is, if one fails (or gets turned off) it’s not a huge loss of effort. In this way it benefited us, too. So, we decided to go ahead and start turning off the features.
Throwing Off the Light Switches
We started turning off the features a few at a time, waiting a day or so between flicking off the next set of switches, starting with the features we were the most sure were vestigial proceeding into ones we were less sure no one was using. We knew the “by the book” users would be constantly monitoring the core features. Farther down the line, when we turn off a feature and a regular user said “Hey, I am using that were did that go?” we instantly turn that feature back on and leave the remain suspects alone, as we found the project’s sweet spot. The by the book users had done their job they let us know when our fat trimmed effect the actively used section of the project.
We very quickly trimmed a ton of fat out of the project. This made future upkeep easier, along with making future training sessions shorter due to less avenues for derailment during use. All around a better tool was made.
It’s an interesting experiment to do, and a lot lower impacting that you would think. Especially if you do a good job of identifying what is likely extra mass. Obviously, this tactic isn’t for every project, no plan is a complete panacea. So, I would be uncomfortable doing this experiment in a project where I didn’t have a great line of sight on the users. I also wouldn’t use this tactic for any major program surgery, keep the light switches small. It also likely would fit into the later stages of development. The application or project needs to be active and already used for you to really have any idea what is or isn’t useful to the user. Under the right conditions its very effective at making a better “bat” for all the players.
