Posted on: 2025-01-14

In my career, I have noticed a few details that significantly increase the quality of a software product. Here is a summary followed by a more detailed explanation:

1. Use the system that is being developed
2. The financial incentive must not be aligned to the KPI
3. Freedom to add features, improve features and fix issues
4. A genuine care of user feedback
5. Easy access to telemetry and logs
6. The leadership must ensure the engineer is motivated
7. Automated Tests
8. Understasnd the system
9. Avoiding Over Analyzing
10. Reduce Bad Technology and Technical Debts

Use the system that is being developed

When a builder uses the product, the engineer becomes more than just the software engineer but also the user. Being a first-hand user makes you go through the user's frustration and tangible improvements. Using the product is different than compiling it, trying it out during development, and moving on to another specific feature and barely using it anymore. For example, if you are building a trading system, the software engineer should spend many hours per week using it with a real purpose and not just clicking around occasionally.

I have been on a few projects where I was using the system. For example, when I was at Microsoft, even software engineers were using Microsoft Team (dev) to communicate daily. One of my side projects was a trading simulator system I used daily. As I used the simulator, I could easily find issues, features not working as well as I thought, and many great ideas to improve the experience. Another time, I was part of a Discord server where I built a bot where I watched the logs live as I used the system. I could jump quickly to fix errors or unexpected behaviors. But, I also was able to add features to make my life easier on the server because I was using it and living the consequences of the features I was adding.

I am strongly convinced that using the system is key to improving quality as long as it is combined with a few other points below, like freedom and motivation.

Financial incentive

Financial motivation is the main cause in 2025 (and in the last decade at least) that software is in a bad state. Many products do not evolve, have recurrent issues, and have had plenty of unaddressed comments online for years. Misaligned financial incentives plague many systems that favor adding new features instead of improving or fixing issues. Behind the curtain, the bugs are documented in the tracking system, but there isn't any incentive for people to tackle them until they cause financial loss (or user loss). Thus, people focus their work on KPIs (Key Performance Indicators) that are not aligned with the quality of the product but instead work to gain a bonus or promotion by checking boxes on to-do lists. When the financial incentive is to do your best work, then the quality of a product increases.

The consequence of misaligned financial incentives is that everybody needs money in their lives at some point, which is understandable. The argument that the priority is insufficient is often unjustified because it is highly subjective. For example, I recall hearing that users are not unsubscribing, thus not worth it. However, in countless encounters, I could hear people complaining. Was the threshold to start fixing really high as losing someone? And how can we really correlate someone leaving to a particularly bad experience? In most cases, it would be the accumulation. Thus, the argument falls back to being subjective to avoid looking at the current situation but just moving forward with more and more new features.

Freedom

Freedom is necessary if the software engineer uses the system and has incentive to do the best for the user. Without freedom, the engineer can acknowledge issues and improvements but cannot move forward. While freedom requires mature people and a minimum amount of governance to the overall stragegy and direction, it is necessary to keep the motivation high and to encourage initiative (see point about motivation below).

I was blessed having many occasions with many freedom spaces. For example, I built a drag-and-drop dashboard instead of a more conventional click-and-move in 2014 for Microsoft. Similarly, at Netflix where, I was given the freedom to rebuild a system, which I moved from Angular to React (2017) and later created a whole API in GraphQL for Open Connect without having any specific mandate to do so, just because it was making the frontend and cross-team easier. Freedom leads to innovation and better software. Finally, when I was working at Jump Trading, I made the best-looking and configurable OMS (Order Management System) because I was given the freedom to do so (this feedback came from many traders with +20 years of experience). But, all of that was because I was given freedom and time and my "KPI" was not checkboxes but to build the best solution for the users.

User feedback

I've often seen people gathering feedback using UserVoice (a voting system online for features) or GitHub issues to track desired features from users. A quick scan shows thousands of features that were voted to move forward, but nothing is happening. In many cases, the product owners stop completely acknowledging the feedback, and good ideas die after years of reports. User feedback is a gold mine for software engineers, who need to understand the real needs of the user. User feedback is the best way to understand the user's frustration and to improve the product. However, if the financial incentive is aligned with product management and the manager focuses on adding new trendy features, like right now with AI, then fundamental features are left behind.

Telemetry and logs

The best projects I had were those that I was free to add and collect telemetry, understand, and quickly access (queries were fast, and the tool was available). Across professional and personal projects, seeing live logs helps to adjust and fix issues quickly. However, without freedom, having all the logs in the world would not move the project to solve these issues. The organization needs to get its people to care deeply about the features that work hand in hand with freedom. Similarly, if there isn't freedom to take time to analyze the data and act on it, then the telemetry is useless.

Automated tests

The automation of tests allows the avoidance of recurrent mistakes, gives the confidence to modify existing code, and ensures that future issues are not reintroduced. A framework must be in place to keep the quality high and the motivation for software engineers to create tests. The framework must allow easy debugging and access to data, simplify the creation of tests to the maximum, and be configured to not significantly slow down the time to push new code to production. Once you have a great automated system, adding new tests should be frictionless to encourage people to add more tests.

One pitfall I noticed is that the people building the framework slowly are no longer users of the platform they are building and lose track of how easy to use, document, etc, they become what they are building. Thus, it comes back to being a user of what you create to stay grounded on reality and not build theoretical suggestions.

Ensure people understand the system

I've witnessed more than I thought I would team of people building code without understanding the framework they are using or understanding the business. It is impressive that many lines of code can produce a decent number of features without having the creator deeply understand some decisions. Performance issues, errors, or misaligned features are the consequences. To ensure the quality of the software, the organization must ensure that people understand the system they are working on. Clarifying a product can be done by having good documentation, a good onboarding process, a good training program, and a good culture of sharing knowledge but also being available. The rise of AI, bots, or moving support overseas creates new barriers and breaks quick communication. However, because of KPI and financial incentives, in most cases, the management and the engineers run toward pushing lines of code. The quality is lower because the person is less motivated but also cannot work on the best solution because he doesn't understand the system. Thus, it accomplishes some metrics (KPI) that check the box and nothing beyond.

Motivation

A team of motivated individuals easily produces twice as many results. Motivation is complex, but increasing the incentive to build the best software and giving freedom for each individual to work on what they believe is the best is a good start. Forcing people to work on useless features while working in a code with technical debt, no documentation, or slow build time kills motivation, reduces the time to ship new features, and demotivates people to care about fixing issues or improving the system in the long run.

To motivate people, the leadership must ensure the engineers are leading and have words to say about how to create and have the time to accomplish the work without being forced to cut corners. Motivation entails having freedom, understanding the system, and ensuring the engineer works in an environment that stimulates his desire to work. Adding a large number of meetings, micromanaging every decision, having heavy task approval systems, and working in legacy or esoteric private frameworks are all demotivating factors that reduce the quality of the software. With motivated people, their time will fly, and they will say, "The day is already over?" instead of "I don't want to go to work today."

Over analyzing

Having dozens and dozens of meetings for details that are not important is draining people's motivation and makes them give up focusing on the important part of the system. For example, having hours of meetings to position a button might be important for some people, but for most, they would instead ship an initial version and then iterate. Or, use an A/B system to get the best result using real data. The example of the button is simplified (but still impressively real), but the scope and negative impact increase drastically with more complex features where weeks and months of meetings cause the development schedule to be rushed. The result is a reduction of quality where the software engineer would have preferred having more time to build a more polished version with more tests and time to read the telemetry to iterate. However, the lack of time combined with the financial incentive to move on to the next feature essentially decreases the quality of the software.

I've been in many scenarios where I needed to step in to break the pattern while we were talking infinitely about a feature. Many times, I created a proof-of-concept of one direction and showed it live in meetings, showing that one possibility could work out very well. It happened at Microsoft, where we were stuck for weeks on a web color picker. I built it in one afternoon and presented it -- it is still in production after many years. Similarly, months of image creation by designers that was focusing on a single vision of a way to build the feature. Once I got into the project, I created and presented a small prototype with real data. The sample group of users gave their feedback, and a few days later, a more polished demo was available. Thus, a few days of work instead of months of talk moved the project to the best for the users but also for the quality of the system. Having made this approach from the beginning would have given months of potential hours to improve the quality.

Bad technology and technical debts

The last point concerns the technology. Using old, legacy frameworks or programming languages undermines engineer motivation and makes simple tasks harder. The lack of support and the lack of features increase the time to build simple features. For example, proprietary systems that only a few people know the detail creates a silo where only people with long tenure really can work efficiently.

Brittle technology like a fragile build system or using an older testing framework, or building a system that increases the run time reduces the engineer's efficiency. All efficiency lost is time lost to make better software. For example, I worked in an environment where the build system was failing for days and sometimes weeks. Hundreds of engineers were stopped for a long time. Another example is a system that had a mono repository with thousands of people working on it. Thousand of PRs were always open, which caused merge conflicts for days. The technology directly impacted productivity and motivation, as coding a single line could result in a whole week of fighting for continuous integration.

Technical debts are on the same page with increasing the time to build something because of past decisions. Software is like a garden, and the engineers must have time to cultivate the land (foundation) to ensure that the features built in the garden keep growing efficiently. However, if the organization is product manager-driven, it will be a constant fight to get time to make this technical improvement. Thus, it is critical to balance the feature and engineering time to improve the quality. My best experience was at Microsoft, where the PM (product manager) and the EM (engineering manager) talked to each other constantly to balance the workload in these two areas.

Conclusion

Qualifying quality is complex, and it is easy to lean too much on either side. However, increasing the quality benefits the end users and software engineers. When these two groups of people are satisfied, the result is a win. However, in our modern way of building software, keeping the quality high becomes harder. After years of fighting the system, even motivated people will give up. Some people leave, and some just start playing the KPI game to check the boxes and move on. The problem is that with more and more disconnect between the people building the systems and the software, the more work on these systems becomes a chore, and the more users complain. The saddest part is the people who make these decisions are often already well rewarded (promotion, bonus, position) and often leave the company before the real impact of their decision is felt. Or these people are so disconnected that they do not feel the pain of the users and the engineers. For example, if they are not using the system, they might not understand that it is not efficient to have an existing feature operate in a specific way. Similarly, for the engineering side, if the way something is made makes it hard to debug, then they do not feel the pain, which means it never gets prioritized. Again, the best environment is having people connected to the system, using it, and having their hands somewhat dirty in the creation. The flatter the organizational structure, the better.