Tag: software development

I was working with a customer recently that develops software for use by their clients. They work in a DevOps style flow, regularly completing work and sending that to their clients. In one case, they released a hot fix quickly to resolve a bug in their software. In this case, the developers received the report, triage’d the bug, and released the fix in less than a week. Their clients were happy with the response and speed at which the fix was delivered.

Unfortunately, they also released another bug with the fix. The new bug was in an unrelated area of the software, created by separate changes to the code. Now they had a dilemma. The hot fix helped some customers, but the fix also broke some things that other customers cared about.

What do you do here? If you were in charge of this software team, how do you decide what to do? You can pull the patch, but that means some clients might have broken software. You can leave the patch out there, but then you risk other customers being upset by a new bug.

There isn’t a good solution here, and the more clients you have, the more likely that you have a large split of customers wanting version 1 versus those wanting version 2. You could rebuild the hotfix to remove the new bug, or you could make another patch that just addresses the second bug. The latter idea is what DevOps would suggest, with a roll forward to a third version of the software. The idea being you keep improving things and fixing bugs as you continue to develop new features. You will release some bugs, but you can fix them quickly.

The downside of this is that if you release too many bugs, customers are loathe to upgrade. When this happens, you start to find yourself having to support many versions of your software. If you respond to customers with special patches that only fix bugs without adding features, you may end up with many more versions than you can track, which can be a real nightmare for developers to manage.

How do you deal with patches causing bugs? I recently re-read a piece by Eric Sink in which he recounts releasing three maintenance versions to his customers in a week. Embarrassing for a version control vendor. It’s a good (but long) read, and one that might give you some perspective. We can’t squash every bug, and we can’t test for everything, but we can work to continue to improve, chasing the dream of bug free software. Or at least, regression bug free software.

Steve Jones

Listen to the podcast at Libsyn, Stitcher or iTunes.

I am a big standards guy. Not any particular standards, but ensuring you have some in your organization and that people stick to them. Pascal case, Camel case, it doesn’t matter to me. I’ll build a habit with any of them; I just want some consistency from others working in a team. Or even across teams since people move to different projects over time.

I ran across another post on naming conventions, this one looking at SQL standards, and it’s a practical look at a few things. I like some of the ideas, like the singular or plural choice (” Who cares. Just pick one and use it consistently. “), but I especially like the idea of the third item: standard aliasing.

In the past, I’ve often found that I used the same aliases over and over. When I was the only DBA, this ensured consistency. “P” was always for dbo.Product, and pc was always used for ProductCategory. However, when we added other team members, I quickly realized we didn’t use the same conventions. I’d check out code and see prod.productid instead of p.productid. The new people didn’t like my single character aliases and I didn’t like typing most of the word for theirs.

Ultimately we had to decide what made sense for both of us and compromise. We choose specific items, not all at once, but as needed. We’d have a 30s meeting or exchange a quick chat message and then update a document with the standards. When other new developers were hired, they already had a reference list that they quickly learned.

I think the idea of standard aliases makes sense. It’s built into SQL Prompt and some other tools, precisely because many teams want to ensure their developers adhere to a standard, and more importantly, can quickly understand any code they pick up. That’s the real reason for standards: they convey information, silently and quickly.

Steve Jones

Listen to the podcast at Libsyn, Stitcher or iTunes.

Things always go wrong. Those of us that build or operate software know that we will have failures at times. These could be while applying a patch, deploying a new system, during a spike in traffic, or perhaps just a mechanical failure somewhere. Most of us fix things and move on, as there’s always plenty of other work.

In a few organizations in which I’ve worked, whenever we had a large issue, we had a retrospective. I think we defined large issue as a VP or CTO become involved, but in any case, we sometimes had to have a retrospective meeting on why things went wrong. Usually these weren’t blameless, or psychologically safe. They didn’t end up being good meetings, nor did they serve to prevent future problems.

In today’s software world where we want to adopt DevOps and build better software, we need retrospectives, both when problems occur, but also periodically as we finish major portions of work. We want to learn and become better at building software, so it pays to spend some time actually assessing how we work as a team. I ran across a post from Thoughtworks that talks a bit about how to make these better.

I don’t completely agree with the post, and I certainly think that a retrospective won’t solve all the issues we’ve had. Nor should it. I really see the growth and adaptation of a software team as taking time. When we find lots of problems, the key to making the software development process better is to decide on something to change and try it.

I’m all for an evolutionary approach for a couple reasons. The first is that change is hard and disruptive. If we can change just one or two things, then most of our work continues forward. I don’t want a new set of coding techniques and a new build process at once. The second thing is that any change we make might have other consequences. We see this constantly in the world. We try to alter one thing and other parts of our process change. If we change too much at once, we might introduce lots of other problems.

Let’s grow and change in small ways, but do so on a regular basis. This is both for the way we work as a team and get our software to customers, as well as the techniques we use to write code. Let’s code better, refactor older code when we can, and learn to improve our skills and techniques each month. We’ll have a healthier code base over the long term and a healthier team as well.

Steve Jones

Listen to the podcast at Libsyn, Stitcher or iTunes.