A Really Good Read: “Win Bigly”

Win Bigly: Persuasion in a World Where Facts Don’t Matter by Scott Adams

Scott is far deeper than whom we closely associate him with: Dilbert. Adams has a long-standing blog that is very popular, as well as Twitter, Periscope, etc. He’s written a couple of books & I’ve found both helpful & enjoyable.

“Win Bigly” presents reality very simply: there is no reality.

Seriously, my reality has zero relationship with yours. And vice-versa. There is tons of data to support this, which he presents.

So what? The answer is given this starting point of “no reality”, how does one influence others? It turns out there are many guidelines in this book that help in many situations. A very good “business read”.

Advertisements
A Really Good Read: “Win Bigly”

So You Want To Change the Culture?

Many find a new corporate culture attractive and try to make it so. Before starting that journey, there are a couple of prior changes you may find helpful: the Semmelweis Reflex & Donald Rumsfield’s U.S. Department of Defense update for Special Forces.

Ignaz Semmelweis was a pioneer to champion hand-washing as a standard part of medical treatment in 1847. Twenty years later Louis Pasteur postulated the germ theory, which sped things along. Semmelweis had hard data to support the change, but the resistance to change was massive. Consider the suffering & loss of life before this simple change had wide-spread adaption!

It has been said that science advances one obituary at a time, meaning as the old critters die off, the young replacements aren’t so wedded to the “proven” ways. From a change of culture perspective, one can counter the Semmelweis Reflex with natural attrition.

United States armed forces started building “Special Ops” forces after the Iranian Hostage crisis in the mid-1970’s. The very top brass resisted in many ways over many years in developing these units into what we now take for granted.

Donald Rumsfield didn’t have the patience to wait for natural attrition. As the Secretary of Defense, he had the vision & drive to affect the change in leadership that could bring about this change. It took a couple of years, but he was able to bring in the correct leadership to get the job done.

Culture change can be accomplished in both ways, however I like a quote from my friend, Erik:

“You can change people or you can change people. I prefer to change people!”

It’s up to you.

So You Want To Change the Culture?

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