What “Good” Looks Like in Software Development | by Michal Sadowski | May, 2022

A few definitions to help developers

Photo by Aaron Burden on Unsplash

I saw a post some time ago saying most developers don’t know what “good” looks like — and that’s something I couldn’t agree with more. No matter how much talent and good intentions are in the team, without imagining how smooth software development can be, it can become a constant struggle.

Although I was always looking for better ways of building software, there’s still a lot I could learn as well. Still, I would like to share some good things, which I had the pleasure to see working very well in action so far. I will skip examples of specific solutions. Every workflow and team is a bit different, so things work perfectly in one context could totally fail in the other.

A good process should make life easier, not add responsibilities for team members. Sounds obvious, but many managers forget about it and establish processes just so those would be in place, without considering the impact on the team. If something could be automated — it should be. It’s not only about saving time, but also about introducing standards and simplifying onboarding.

If some part of the process doesn’t work as expected, it should be changed or removed. When people forget to do something all the time, probably they do not benefit from that. Maybe this action could be simplified or at least coupled with another one, so the same work would produce more results and save time in the other place?

The end game should be a setup that doesn’t rely on people remembering exact steps to follow, empowering regular team members to focus on their daily tasks, and giving enough visibility for leaders/managers at the same time.

An important thing for all developers; it directly impacts the development team’s ability to adapt to new changes and maintain existing solutions. Code that “just works” is not really good enough. Ideally, it should be easy to understand by others, documented, and covered with tests.

Something that many people are missing is that those don’t need to be three separate things to handle. By adopting a proper testing strategy, and making it a part of preparing the initial solution instead of just validating it at the end, you can save a lot of time and have two of those at once. When you add paying attention to readability (especially during code review) and proper test descriptions — code becomes self-documenting and there’s no need to maintain docs separately!

The usual things I heard when asked candidates in interviews about CI/CD were: running static analysis, tests, and automatic deployment. I would add measuring performance, basic security checks, and proper notifications.

However, it’s not only about “what should be done,” “how” is usually even more important. To get high productivity team really shouldn’t spend a lot of time waiting on CI/CD outcomes. In case of failure, finding the reason for it should be easy. Also, if we’ll notice anything being wrong with the already released version, there should be an easy and fast way to roll back the change. That usually requires even more checks, but hey!, we’re building CI/CD pipelines to do those for us so we won’t spend extra time on manual processes.

Implementing solutions and delivering them to end users is just the first step. Once released, the software starts its own life, and rarely does it look exactly as predicted previously. For sure we need decent logs to know what has happened in case of any incident. The faster we’ll be able to get relevant information, the better. So our logs should be easy to search and free from unnecessary noise.

An ideal situation is when we know about any issue before our customers would and can start solving it as soon as possible. However, nobody wants to spend time staring at the dashboards. The way to achieve solutions to that issue is to properly set up alerts — probably not so many, very specific, sent to the people responsible for the affected parts of the system. Using a communication channel adequate to the importance of the notice is also crucial. If everything lands in one bag, the team either would get distracted too often or could miss some urgent notifications.

Getting there takes some time, but once you’re there, handling incidents become really smooth.

Ideally, you won’t need it at all, but if something really bad happens, it’s much better to be prepared and know exactly what to do. Do you have backups of everything required to restore your system to the same state from scratch? Are those stored in another place than your primary data? Which tools can be used for restoring backups, are there any specific instructions to follow? What would be the worst thing that could happen to your system?

Even if implementing and testing solutions for those might be too expensive, you should at least know the risk and accept it consciously. Once disaster actually happens, there might be no second chance.

It applies to internal and external feedback. I have not much experience with handling end users’ feedback, so would focus on the first one.

All team members should feel their input matters. Such an environment supports creativity, constant improvement, and makes everyone happy. It’s important that the whole team understands there’s nothing personal in constructive feedback, and without it, nothing could be fixed.

On the other hand, leadership should clearly communicate their expectations and recognize the team’s effort. Without that, even the most valuable team members might have doubts if they’re doing a good job and such uncertainty leads to poor morale.

There’s not much value in robust CI if tests are not good enough and all regression testing is performed manually before each release anyway. The perfect process for handling reported errors can’t shine if you’re struggling to notice them and/or get some details. No matter what you’re doing, it’s not possible to plan ahead perfect solutions, so getting feedback and improving what’s already there is always crucial.

The more things work smoothly, the fewer issues that occur in other places. All the above combined together create synergy, empowering the whole team to move fast, safely, and without unnecessary stress. Even if your team is missing a lot of those, it’s worth taking small steps and getting at least a bit closer to what you consider ideal.

Thank you for reading. If you’d like to add something to this list, please share your thoughts in the comments. I’d really appreciate that!

Leave a Comment