Software-Development

I’ve been thinking about a particular flavor of technical disaster that keeps cropping up in software companies. I call them “turducken projects” - those unfortunate mashups where you try to maintain two different solutions to the same problem, usually for political rather than technical reasons. Like the absurd holiday dish they’re named after, these projects seem impressive at first glance. “We’ll support both approaches!” sounds inclusive and customer-friendly. In reality, you end up with something that makes everything involved worse. ...

Some of my most productive business tools are the simplest. Take the triage board. It’s a whiteboard that hangs over my desk that has a list of my current projects, with magnets marking what I’m working on next. Weekly I erase the board and re-prioritize my projects, and daily I scribble notes and move the magnets as I work. These concrete tools are about focus, flexibility, and the least amount of investment possible. It’s critical to work on the most important things, and important to know what’s next. Seeing the list of clients and projects helps me understand where I stand in terms of bandwidth too, using the simple, physical limits of the size of the board and legibility of my writing at smaller sizes. ...

“A common example is process as proxy. Good process serves you so you > can serve customers. But if you’re not watchful, the process can > become the thing. This can happen very easily in large organizations. > The process becomes the proxy for the result you want. You stop > looking at outcomes and just make sure you’re doing the process right. > Gulp.” (Jeff Bezos) This is a quote from a Jeff Bezos letter to the board, talking about internal metrics and improvements. Sometimes when you add a process to a problem, the process can become the focus and not the outcome. ...

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