Safe Software

Software developers, manager, and teams tend to dislike analogies to traditional manufacturing, because we’re “special”. And many will argue that we’re special in soooo many ways!

When one purchases an automobile, what concern do you have for the safety design reviews? What about their costs? Clearly it takes time to conduct such. The crash-worthiness tests are similarly expensive both for the time & the capital expenditures. Yet, as purchasers, we don’t give a wit.

When it comes to software development, adding software security to the analysis, design, coding, testing, and reviews is often strongly resisted. After all, it takes time to perform this work. And additional time means less features. (If a customer doesn’t have feature X, he’s not going to miss it’s non-delivery. There already is a work-around.)

However, as with automobiles, customers have a certain expectation that the software is safe to use. (I’m not speaking of medical, avionics, or nuclear power plant software; rather traditional office or home software.) If a vulnerability exposes all of your customers customer data to the internet, methinks an expectation of safe, secure software has been blown to pieces. It doesn’t take many reports for your brand to be tarnished beyond repair.

So then, why the resistance to secure software? One reason may be that many in the chain of command have put together well-crafted product plans and a successful delivery means great bonus compensation. The implementation of new, aggressive security testing, analysis, design, training… ugh. And after all, we’ve never had an issue before, right?

People are people and most people strongly dislike change. Even the vaunted “cutting-edge” programmer title we like to bestow upon ourselves doesn’t mean we like change. Many programmers don’t like change. And for a variety of reasons. However, safe software and the associated culpability preclude dawdling; we, as a group, have to demand the time to do the job right.

Consider asking an architect for an estimate to build a bridge. When it comes back at $10M USD and 1 year to build, one impulse is to say: “Cut the cost & time by 1/2!” Professional architects will simply bid you “Good day.” Programmers, on the other hand, will say: “Sure.”

Unfortunately, they often do just that.

Safe Software

Hoarding Code is Technical Debt

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!

Hoarding Code is Technical Debt

New Code vs Maintenance Code

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.

New Code vs Maintenance Code

Roofing Your Garden

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. 

Roofing Your Garden

Process Debt is Worse Than Technical Debt

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!

Process Debt is Worse Than Technical Debt

Poor Performance is Easy: How to Eliminate?

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.

Poor Performance is Easy: How to Eliminate?

How to Check for Sheep

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

How to Check for Sheep