Category: Software Processes

Recently someone said to me “stakeholders only care about milestones,” and something clicked for me.

In this, the third and final part of this series, I’m going to present 10 recommendations for avoiding the pitfalls of using bucketed prioritisation (e.g. must haves, nice to haves, etc.), covered in the previous two parts.

Processes are a prerequisite for high-performance in software engineering teams due to their ability to amplify the skill of the team. I believe there exists no team, given that there is little to no process to begin with, whose performance could not be improved by adding appropriate process.

Engineering Managers (EMs) are sometimes said to be “shit umbrellas”. They are supposed to keep all the distractions away from the team: the short-lived whims and fancies of various stakeholders, vague plans that are going to change several times before being solidified — all that stuff. Distractions are poisonous to good software, so hiding them should help the team deliver more and better software. A large part of this is true.

However, I would like to argue here that behaving like an umbrella is probably not a good thing. Umbrellas are shields that block rain. And what are these EMs blocking? Hopefully distractions, but also information and reality.

In this article I’m going to take a look at software quality as a way to differentiate between junior, mid-level, and senior software engineers, through the lens of failure demand, purely so that I can introduce a new concept that I thought up on a walk today, which I’m calling negative failure demand.

In part two of this series, we’re going to look at how the must-have priority bucket leads engineering to make bad decisions.

Categorising requirements into buckets like “must-haves” and “nice-to-haves” is a common approach to prioritisation in software projects. In my opinion, this is a bad way to priortise work, for reasons which become clear when you look at the incentives it produces.

A recent shower thought of mine is that agile software development might be similar to the strategic concept of a glass cannon in gaming — specifically, that it’s a high-risk high-reward strategy where the risk can be mitigated by skill/experience.

This is a quick look at the recent CI/release automation I wrote for the byebug-skipper gem.

Links

• Commits from the video

• The “Release Gem” GitHub workflow

• Config for standard-version, which is what bumps the version and updates the changelog using the commit history.

• CI step that ensures commit messages have the correct format

As a member of the software industry, I want user stories to focus more on the problem definition, so that we can make better choices around how to implement a solution.

Or should I say:

As a member of the software industry, it’s easy to decide on a solution or implementation details too quickly, without a good understanding of the problem we are trying to solve. This leads to suboptimal software for the end user, technical debt, and rework that could have been avoided. I propose that we change the user story format to focus more on the problem definition, and less on a single solution.

In this article I’m going to show you, step by step, how to set up an OSX machine to provide secure access to git repositories over the internet via ssh. This was tested on OSX 10.6.

github provides git repository hosting with a lovely interface. If github isn’t feasible, then this article will help you set up something similar, unfortunately without the nice interface.

I assume that you already have git installed. If not, install the latest version from the git website.

We will be walking through the following steps:

• Give the server a static IP address on the local network
• Set up port forwarding on the router
• Getting dynamic DNS
• Add a user named “git” to the server
• Setting up ssh securely on the client computers
• Setting up ssh securely on the server
• Making a bare git repository
• Using your new git server