Six Leadership Roles that Can Make or Break Your Software Project

When you hire a software team, you probably have a pretty good understanding of the technical roles they need to fill: development, design, devops, testing, etc. But don’t gloss over the leadership roles—especially the ones that your team may be responsible for. Read more on Six Leadership Roles that Can Make or Break Your Software Project…

Retrospective: “Building a Virtual Appliance – Repeatably”

A few years back, I wrote a post describing how we used Chef and other tools to build a virtual machine “appliance.”

The short version is that we tried to make a copy of everything we were installing so that if we needed to make a point release later, we’d be able to reproduce the build. We made sure that we mirrored all external dependencies, downloaded all the RPMs, and kept the DVD ISOs around.

It’s been a few years now, and I had cause to go back to it. Spoiler: It didn’t really work. Read more on Retrospective: “Building a Virtual Appliance – Repeatably”…

Your Logs Should Be Considered Features, Too

Sometimes, printing things out is the simplest debugging technique we can use. And then, when we forget to take the print statements out, we call the output our logs.

That’s a mistake. Logging shouldn’t be an afterthought. It’s a core piece of diagnostic tooling. Logs are so cheap to integrate that they are almost always an extremely high return-on-investment feature. Your logs should be treated as first-class features warranting all of the attention to detail that you give to your more user-visible features.
Read more on Your Logs Should Be Considered Features, Too…

Tech Debt Isn’t What You Think It Is

Technical debt isn’t what you think it is.

Kellan Elliott-McCrea wrote up an excellent commentary on tech debt back in January ’16. He makes some fantastic points that help clarify what tech debt is and isn’t, but I’ve still been feeling like something is missing in his definition. I think I’m starting to get a handle on it.
Read more on Tech Debt Isn’t What You Think It Is…

A Hierarchy of Needs for Software Development

When we talk about educating developers, we talk about “what they should know.” For example:

  • They should know “the web” (as if it were a homogenous enough thing that someone could “know” it).

  • They should know JavaScript or some other language.

  • They should read Design Patterns.

But how do you drive down from the whole universe of topics worth knowing to the specific of the next thing to learn? I’ve recently identified a way to think about that: a “hierarchy of needs” for a developer. Read more on A Hierarchy of Needs for Software Development…