Software-Development

I don’t like the term technical debt. We mostly use it without thinking, and it’s often the wrong way to frame the value of our software designs. Most of the time we’re being dishonest when we call our decisions debt, and unless we’re planning out the general long term costs of our approach, it’s not debt at all. With financial debt, money is mostly money, regardless of the source. The terms of a loan are known up front when we borrow money, and those terms may or may not be satisfactory. Any decision to borrow is based on a known commodity, and on the need and the terms, both compared with the gains. Taking on debt, at least in business, is an informed and unsurprising proposition. Debt is often a rational choice for a business too, if the risk is low and the return is favourable. It’s rare for a company’s investors to allow a business to take on financial debt that isn’t clearly understood. ...

Last week I was talking about how it’s easy to conflate debt and regret when it comes to technical decisions. Technical debt is the set of simple, shorter paths in software development that you follow intentionally. Regret is more about getting lost and following unsafe paths, often blissfully unaware that you’re lost. Technical debt will feel good in the long run, as it helps you get somewhere faster at a reasonable cost. Regret, on the other hand, feels bad, as you can see the wasted time and effort spent on a path that was clearly followed by mistake. It’s easy to feel unqualified to measure technical decisions, especially if you’re not technical. You may be disconnected from the planning process or you may not understand the jargon and details of an approach. How can you ask intelligent questions about risk when you feel so separated from what’s happening? How can you make clear decisions about risks with incomplete technical knowledge? Luckily, most regrettable technical decisions fail to satisfy even the most basic of principles, and risky debt is all about the poor ratios of cost versus gain. ...

I review a lot of code these days. It’s an incredible way to nudge a team of bright people toward greatness. It allows me to look at problems from the outside with a perspective of experience and distance from the low level design. The perspective is important too, and I see things that I often miss in my own code. You see, we’re easily blinded when we’re too close to the problems we’re trying to solve. ...

While writing a spec earlier today the last few years of progress in server land hit me: uptime is a facade. In the early days, server resources were expensive and scarce. Uptime was sacred. Long running hardware was celebrated, UNIX tools were born, beer was consumed. The problem of focusing on the hardware is that it detracts from the time you spend developing software. Remember those late nights configuring RAID setups? What about hunting down faster drives, or terminating SCSI cables? ...

It’s not that these tools and techniques are bad in themselves, but our use of each should be fit into a well tuned approach to building software. An entire project delivery should be tidy, professional, and complete. There are a few causes to the problem of organizational buildup. Our software is limited, our methods need improvement, and the unseen pieces of our project pile up and are left a mess once we ship. categories: rants ...