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.”