The idea seems so innocent: a feature is no longer needed or is obsoleted, but what’s the harm in leaving it? For a visual of this, consider any of the “Hoarders” episodes on YouTube. What is the harm in keeping this old cuckoo clock? How about this old skateboard? Mcdonalds bag?
The years go by quickly and soon no one has any recollection of why that feature ever had merit. But then, there may be some customer that has some odd requirement that needs this feature – we think. (And, for sure, Junior will be stopping by to pick up his skateboard.) There hasn’t been a bug recorded against this, so it can’t be broken, can it? (The cuckoo clock hasn’t worked in years, but no one complains.)
Unfortunately with software there is a cost to this old junk. The cost is repeated re-learning what this does, coding around it, and occasionally designing & testing it. A great feature would be documented; a good feature would be obvious to end-users and pretty plain to see in the code; the rest is probably junk. What’s the old rule of thumb? 20% of the code fulfills 80% of the need?
From a security perspective, code adds “attack surfaces”. The more code, the more opportunity for bad things to happen. The opportunities for what can go wrong can get sizable very quickly.
Let’s revisit the hoarder’s analogy for a moment. After some time, a new, sleek hot-shot feature is incorporated into the product. Kinda like a new modern, contemporary house being built next to said hoarder’s house. What is the value of the new house? Has the hoarders dump reduced the net gain? From the customers perspective, why would it be any different?
Let’s keep our code (product) lean & trim!
Working on new code is fundamentally different than maintenance. When one is buried in maintenance, it’s easy to loose site of what it means to have no design constraints, other than the best for your situation.
When doing new code, you have to think about best structures, algorithms, classes, interfaces, etc. Take this mindset back to the maintenance side of the house and what happens? You’re stunned at what is in front of you. It looks like hubris. But now you know what is possible and can re-define success.
For this reason alone, it is intellectually refreshing and important to take on small projects. Like a Raspberry Pi, for example.
Last year our garden had weeds growing between the boxes. A thick covering of shredded trees (wood chips) looked good, but didn’t do a thing for keeping the weeds under control. It’s just nice to have no weeds, but wedding the walk-ways seems too much.
As it came to be, a shed needed new shingles. This generates waste – the old shingles! Rather than just toss these out, how about roofing the garden or walk-ways?
Last years wood chips were pulled aside, the old shingles laid down, and the chips et al back on top. This should keep the weeds down and make the garden look much better, without more weeding for a long time.
Technical debt is frequently thought of as being a code or executables. If so, is this hard to fix? What drives technical debt?
A leading candidate as the source of technical debt would be bad processes. Let’s say your team conflates “estimates” to be “commitments”. Clearly this worse case scenario can easily drive many bad hurried decisions across many facets: requirement definition & approvals, design of architecture, classes, system/database/messaging interactions, documentation, installation practices, and so on. These are the easy ones to deal with as most are under developer team control or influence.
If you consider the greater organization, the problem become much, much harder to correct. It can take weeks to get executive, sales, marketing, support, legal, or operations teams to come together just for a meeting! Getting everyone to agree on the definition & substance of changes just increases the solution timeline even further.
At the end of the day, the delivery team is left holding the bag. We have to deliver a solution, but have little influence on the overall schedule or scope of the changes or its delivery process. It is imperative that the dev team eliminate as many obstacles as possible to ensure the best use of very limited resources. The dev team, and only the dev team, can correct their situation. It is imperative that improvements be done on a continuous basis.
The reason I bring this up is to offer perspective. Some of the “hard” technical problems dev’s face aren’t so bad after all. Trust me on this, dev problems are much easier!
In any endeavor, one has a choice to perform well or poorly. It’s very easy to be poor performer; take the path of least resistance, offer excuses, passive aggressive behaviors, and so on.
What can be done to reduce this? How can a boss work with his team, using their words and actions to constantly improve performance?
Ask either the team or individual: what has been done in the past week/month/2 months to improve performance? Track the results. Share the results. Discuss them.
It’s important that one not get caught up in the desire to have “great” or correct or even the best results. Often what is improved today will need to be discarded later as learning or circumstances evolve. The important thing is that a bit of progress is achieved.
Incremental, continuous progress is critical. For the team’s success, as well as for each of us as individuals. There are no excuses.
ps. I would like to thank Harold Allen for a critical lesson he imparted: “As far as the customer is concerned, you cannot remain where you are. When the competition improves just a bit, you have fallen behind!” Thank you, Harold, for the wise words so many years ago.
Any good boss knows a percentage of their staff is on the lookout to earn “brownie” points. What’s scary is when you’re not sure whom that is, or how many are in this group. When that happens, the team is so lacking in fortitude/vision/desire that action is not possible without a nod from on high.
On the other hand, there is often the oddball or crank that always has something new or different to try. You can count on this person to absolutely always be wanting to try something new. These people are easy to identify, as they tend to stand out (for better or worse.)
Now to be sure, one cannot be too quick to put folks that don’t fit the latter group into the former, just because they don’t speak up. They may just be quiet folk. There is nothing wrong with this.
So how to find the group thinkers or follow the boss sheep? Easy: just offer up a slightly lame-brain idea and see who reflexively stamps it as a good idea. You don’t have to immediately follow through on it, just defer action for a day or so and then announce a different set of priorities.
Now you know whom not to count on!
As a corollary, one of my sons football coaches was commenting on player attitudes: “There are two kinds of players: ‘Whoa’ & ‘Go’. The ‘Whoa’ player is one whom has to be throttled back; the ‘Go’ player is the one whom you need to kick in the butt. I prefer a ‘Whoa’ player.”
As many folks of Finnish descent are want, we have a sauna. Each night someone is tasked with monitoring the temperature. What better application for a RaspberryPi to announce via social media, that the desired temperature is reached?
Here is an offering via GroupMe:
It’s pretty basic, but a temperature sensor is connected to a RaspberryPi which has a wireless connection to the internet. With a little work, it’s integrated (securely) into a popular social media platform.