Fix the Switch!
Fix the Switch!
After noticing a switch taped in the ''on'' position, a Zone Leader cites examples of how we need to fix those metaphorical switches in our applications.
Join the DZone community and get the full member experience.Join For Free
Engineers build business. See why software teams at Atlassian, PayPal, TripAdvisor, Adobe, and more use GitPrime to be more data-driven. Request a demo today.
While attending an all-day session with a client, I noticed the following switch located on the wall:
If you can't figure out what is going on, the switch is taped into the upright position and the attached label reads: "Please leave on at all times."
If I would have seen this before I wrote my, "Things I Still Don't Quite Understand" article, I certainly would have included it back in June. However, this image has inspired me to address things we should always focus on fixing now...instead of patching now and/or addressing later.
In the example above, whatever requires that power be enabled 100% of the time should be placed on a circuit that does not require an on/off switch. After all, this was found inside a corporate office — which certainly should have the necessary means to correct this situation.
My hope is that switch wasn't tied to the master power source to their Data Center.
Q4 Goals — Employee Retention
At a prior job, I was invited to one of those company-wide meetings where they would share the goals for the entire year. I think these events can provide insurmountable value, as technical staff can often feel like misguided sheep if they are not provided updates from the C-suite staff leading the corporation.
During the session, the presentation featured company goals for the year. It was the start of the year, so we were just in the first of four quarters. Each quarter occupied a quadrant of a simple table and animations were used to reveal the goals for the quarter as the executive presented them to the group. I found myself nodding my head when the first two quarters of goals were presented. I nodded a little less when quarter three was announced, since it felt like an eternity both in time and the amount of work required to reach such goals.
Then, the fourth quarter goals were discussed. The first one was titled "Employee retention" and talked about how the corporation was going to make it a goal to improve employee retention in the fourth quarter.
I was shocked.
I could not understand that if there are known issues with employee retention, why would these items be tabled for nearly a year before they are addressed? I left that job not too long after the presentation and from checking with others, a significant amount of people departed before the fourth quarter, too.
I have to wonder the difference that could have happened if that fourth quarter goal was moved to the first quarter of that same year. In other words, fix the switch now instead of waiting until later.
Avoiding the Situation Led To Something Far Worse
Learning lessons from past experiences is a wonderful ability we maintain as human beings. Our minds allow us to understand what did not work well and make sure we avoid making the same mistake twice. However, there are times when you try so hard to avoid making the same mistake that you end up with a situation that is far worse than what you were aiming to avoid in the first place.
A few years ago, I was working on a project team that wanted to make sure that the disruptions to the business are minimized since we ran into some minor issues when trying to implement minor fixes and enhancements to an application. As a result, the Product Owner opted to hold off performing releases until they achieved a solid set of functionality to deliver to their end-users.
This scenario was noted in my "The True Value of the Product Owner" article and I felt like it was worth including in this post, as well. In this case, the fear of upsetting users by introducing new features on a periodic basis was replaced with the idea that one big release would be performed when everything was ready. In doing so, the ability to troubleshoot issues from a major release is not as easy — since the scope of the feature list is far more involved and complicated to diagnose. At the same time, all the features will be submitted to true production usage at once, which can expose uncaught issues quickly.
While the fix is to make improvements to correct the issues related to the small deployments, another mindset is to have an understanding that new features will be delivered periodically. This fear of upsetting the customer should be cast aside and replaced with an opportunity to communicate the new features as improvements that will make the customer's job easier.
So, the switch here is to fix the problem in a way that shows the end user that the new "switch" will yield improved functionality.
It is important to recognize those cases where a metaphorical switch is taped into the "on" position and a warning label is attached to prevent incorrect usage.
While it might be easy to take a band-aid approach, the long-term impact of not addressing the issues can have significant impacts.
In the example with employee retention, there are only a handful of IT staff still working at that company — most leaving before the 4th quarter arrived. While I am not certain moving the employee retention fixes earlier in the schedule would have made a difference, leaving the task nearly a year out certainly did not help.
Learning lessons are important for any project or organization. However, when the recommendation from a lesson learned has an impact on the underlying methodology used to deploy software, the decision may not be the best decision. Another review of the situation might be in order to see if better alternatives exist.
The image of the taped light switch with a printed label provides a glimpse into that corporation’s mindset. It is important for us, as IT professionals, to find and fix these issues now rather than pushing them off to some task down the road.
Have a really great day!
Opinions expressed by DZone contributors are their own.