What’s a Good Software Engineering Culture?

I often enjoy discussing with colleagues, leaders, and peers from other companies about software engineering culture. I find it interesting to observe how each company’s development team seeks to solve the problems they face. In the following lines, I present what, in my view, is a general overview of what we, as technology teams, should strive for to achieve a good work culture, software engineering-wise.

For me, the software engineering team should be guided by three principles: team spirit, focus on quality, and value delivery.

Team Spirit

Team spirit symbolizes the shared responsibility that a good engineering team commits to having; in daily life, this is seen in a team that has no fear or difficulty in communicating with each other to achieve a goal. From a code perspective, this is reflected in “leaving the campsite cleaner than you found it,” as Robert C. Martin would say, meaning not ignoring opportunities for improvement when found, whether during development or code review.

It is also advantageous for the technical growth of the team and the company not to foster an individualistic culture with knowledge silos, where individuals hold unique knowledge of how parts of the system work. Building this way may be faster for senior professionals, but it is not a safe or reliable way to maintain in the medium and long term.

Furthermore, from an organizational perspective, team spirit means creating a blameless culture in processes, where, in case of incidents, the involved processes are examined and improved instead of punishing a specific member. This creates an environment where everyone can learn from each other and contribute in the best way according to their role in the team.

An example of a practice that helps generate this culture is the post-mortem, which involves creating a document related to a specific incident after its resolution. I can say that I have had experience with this practice; over time, I needed to create post-mortems for incidents that occurred with parts of the system for which I was responsible.

In the document, I included information such as the cause, how the correction was made, and steps that can be taken to prevent a similar problem from occurring again. These steps were transformed into tasks for the team, while the document is available for us to consult in case similar incidents occur again.

Focus on Quality

The development team must, as an intrinsic part of their duty, deliver the best possible code, taking into account its maintainability (how easy it will be to maintain should it prove necessary to understand, modify, fix, or extend) and stability (how difficult it would be for problems or other unexpected behaviors to arise when changing this code or other parts that depend on it).

To optimize these two metrics, a given team can apply various techniques and processes, depending on the average maturity of the team members. In general, quality code will apply design patterns where needed (when needed), good documentation to facilitate the entry of new contributors, and automated tests to ensure that behavior over time remains stable.

To provide an example of how a developer can maintain code quality where they work, one of the most essential tools for this is the usage of pipelines, which are steps through which the code may pass before being sent to production. We might configure pipelines so that our automated tests run (preventing the code from going to production with a broken test), a linter is triggered to ensure standardization in the style adopted by the team, in addition to organizing the team’s releases, among other uses.

Ultimately, a focus on quality also means that everyone on the team needs to commit to being open to possible improvements. The reality of our scenario is one of constant change, and sometimes working methods that in a historical context could be considered optimal may not be the best in the future. Constant improvement is constant change.

Value Delivery

Speaking of constant improvement, we should also talk about constant delivery; an important part of what constitutes value delivery. The best code structure or the most cohesive team mean nothing if they produce nothing; or, more realistically, if what is produced is not pleasing to the customer or in disrespect to the correct time to market. Thus, the delivery of value is the most important principle because it ensures the continued existence of the engineering team and the improvement of the projects it is involved in.

This does not mean that the team should yield to any demands, bypass good software development practices, and stretch to meet predictably impractical deadlines (likely incurring all the problems that the previous principles were designed to avoid or resolve).

We must see — both the client and the team — that software engineering is not like civil engineering. We live in a world of flexible requirements. Even more than that; sometimes, it is difficult to guarantee in advance how important a particular feature in the system will be (although this type of problem is softened from the moment a company commits to being data-driven, that is, making decisions based on data and research, rather than instinct).

As requirements are subject to change, so is the team responsible for them. And it is in this context that the concept of continuous delivery becomes relevant. Unlike civil engineering, we can deliver the project gradually. According to the Pareto principle, 80% of the value can be delivered with 20% of the effort.

Most of the value of a stock system for a store, for an example, comes from it simply existing with its basic features, such as registering items and their quantities; with this information properly digitized, the technology team has already freed administrators from a myriad of papers that needed to be checked by hand, freeing up cognitive load so that they can make their businesses better in other areas.

This means that other features, such as an external search for items or automatic creation of sales charts, which could block the software for a long time if they had to be included from the initial version, can be released iteratively — thus generating value continuously.

As such, to respect the other principles, the engineering team must know how to create continuous delivery cycles in which it will gradually work to create high-quality work. It does so by understanding and prioritizing what the customer’s goals and needs are, what software pieces can be assembled to contribute to these purposes, and in what order.

In terms of technical application, the pipelines mentioned in the previous section are also very useful for ensuring continuous delivery; a well-constructed pipeline will allow new code to be safely integrated with the main product as soon as the code is reviewed and approved. From a product perspective, agile methodologies are our main tool for prioritizing activities.

Conclusion

I think that, based on the points raised above, team spirit, focus on quality, and value delivery are indeed the principles that guide a successful technology team. The first one guarantees team morale, the second guarantees product quality, while the last pleases the customer, enabling the rest of the processes. However, the way each one is worked on can — and should — change radically from one team to another. After all, no team is the same as another, no product is the same as another, and not every delivery has the same value for the customer.

There are many best practices that could be mentioned here. Things like TDD, DDD, Clean Architecture, among other tools useful for ensuring quality in the developer’s work. However, I wanted to convey a personal and very general view of what I see as useful for the overwhelming majority of software engineering teams; it is up to each of these teams to know what the best tools are for their case.

And as for the reader, thank you for sticking to the end! Allow me to take the opportunity to ask: what do you see as important for technology teams? Is there a tool that is or has been very useful in your team to maintain or improve the software engineering culture?

Thanks!