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!

Advertisements
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

Internet of Things (IoT) – Our Sauna

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:

animatedSaunaMsg

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.

Internet of Things (IoT) – Our Sauna

Artisans Don’t Scale

Some software developers consider themselves as artists. After all, writing software can certainly have creative elements. However, these elements make up a minor part of a scalable team or product. 

Scalability, to me, has many facets: time, people, technologies and customers. 

Over time, years, a product may have many incarnations of product owners, managers, developer, strategies and so on. Artists live in the present. How will works with a time perspective of “now” hold up?

If artist #1 moves on and artist #2 steps in, what does the team do? Should the second artists creativity be stunted because of prior art? If so, he can’t be an artist. I can’t think of a good way to dig out of this hole…

In the art world, an artist tends to specialize in oil or water paints, sculpture, etc. After all, that is their medium. Do software artists have the same thoughts? Can they switch between development languages, operating systems, delivery platforms, or back-end technologies?

What if customer needs change? For example, say the government foists a new set of audit regulations on the customer domain? Implementing such a feature set sounds non-creative, in fact boring. So how is our bored artist going to get along?

So why bother with writing this? Some time ago, a software developer told me that he considered himself to be an artist. I thought this a peculiar comment and just kept it in mind over the years. Finally, I thought I had collected enough to squelch the silly notion. 

Artisans Don’t Scale

Simple Tools: Interpolation

In my shop, there are many washers – flat little things, varying diameters, metals, types, etc. When I need one, it’s a quick process to sort & select. How are software tools?

I’m working on a small RaspberryPi project with a temperature sensor. It became apparent it would be helpful to map that temperature to the wall thermometer. I ran a quick measurement exercise to build a table of matching temperatures in 10 degree increments.

Then I need some interpolation code to make good guesses. A scan of github yielded interpolation tools that seem to have a lot of other code or large libs or in one case, required me to read & comprehend the offering. Neither struck me as being simple.

What would be a simple tool?

A single file & class. Check.

Unit tests so users don’t have to debug my code. Check.

Generic class to fit several float types. Check.

Simple code, so if one wanted, they could quickly get comfortable with it. Check.

Exception safe. Check

Able to handle out-of-range requests. Check.

So here is an offering for a simple, safe & reasonably robust interpolation class for C++.

https://github.com/dhalonen/simpleInterpolation

Simple Tools: Interpolation

Developers: You are NOT special…

Software development is still a pretty immature industry. It’s very cheap to get started and essentially anyone can enter the arena. Obviously immature processes are not scalable to large endeavors, nor will hold up over time or personal changes. In particular, naming or code conventions are very important – and frequently hated by developers.

I had a conversation with a design engineer working at a domestic automobile manufacturer regarding standards. I asked of the impact to the company if designers could create blueprints/drawings by which ever manner they wanted. For example, the dimension arrows could be open or closed, wide or narrow; title blocks could be anywhere on the page; and so on. His response: “That would shut the company down immediately.”

In other words, having standard communication formats for blueprints is very valuable for the company. Mankind has been using blueprints to communicate for probably a couple hundred years now. In fact, in high school drafting class, we were instructed exactly how to create blueprints. The value of the blueprint is communication of the content.

With software development, many consider ourselves as “artisans”. Our style is best and the rest of humanity will come around. In the unlikely even this occurs, please be aware that even companies such as Microsoft are updating their tools (Visual Studio 2017) to enforce code formatting.

Notice that this is done by the IDE or source control system. It’s not a document you have to memorize. Also, each team can customize it for themselves and grow as a team. Success will be when one cannot discern who wrote what, rather we simply focus on material content.

Developers: You are NOT special…