Quality and Performance

If you ask any engineer or manager, they will tell you they want quality. No one would say they do not wish to have higher quality. The reality as human beings is that we always want the best. Now, what does quality means? How do we determine if something is of quality or not? How can we learn how to see problems and how can we make things better? Hopefully I will be able to address all these questions in this blog post. In the 1980s there was big quality movement driven by Lean and other methods. Today quality is often misunderstood and took into the the wrong lenses. If you don't understand what quality is, and how good looks like vs how bad looks like, you don't know what's going on, and you certainly cannot make it better. Perspective and vision are everything. This post is not about QA. Having QA also does not guarantee quality. Like security quality is everybody's job. 

What is not Quality 

Let's take several things out of the way. So quality it's not:

• Having a role like QA (Having people do regressions, usually manually)
• Going to meetings by following a Process (usually Scrum or Safe)
• Coding Style (usually a document or some particular decisions enforced in code reviews)
• Executing 15/30 min retrospectives 

Such things I described are done by all companies and yet does not mean quality is present.

Quality can be Subjective

Many times, quality is subjective; people often use the word quality when they mean "unspoken expectations," which I cover in depth in this post. Quality can easily be in the eyes of the beholder. What one team consider quality the other can consider pure garbage. 

Idealy, we want have objective measures, for instance, these are good examples of improvements, where one could claim that improved "quality":

• You do a PR, in which the overall system latency is reduced by 10%.
• You do a PR, where you are changing the instance type in the infrastructure and you are saving 5% more per month. 
• You do a PR, where you add 50 tests and add 20% more coverage than before.
• You do a PR, where you refactor the code and can do the same logic with 20 classes less and do not introduce external or internal libraries, and everything keeps working, all tests pass.
• You propose a different experience that makes users use the system 15% more than before.
• You propose a A/B Test experiment that makes the company make 3% more money YoY.

IF you have something in the nature of the previous list, that is not subjective and that is objectively better. However, it is not always possible to do that. Some things are highly subjective like:

• Managers' Preferences (one manager loves daily meetings, the other doesn't).
• System Design (design decisions and abstractions can be subjective and would require expert and careful analysis, and sometimes even time to tell if they are better or worse).
• Some engineers love to disagree for the sake of disagreeing; it's like a sport for them (which is no fun), but it happens. Being opinionated is not necessarily bad.

When shift left is not enough

Now I want to make a little tangent here. I'm all in favor of agile methods, Lean, and the shift left culture. It's always best to figure things out as quickly as possible, and to do so better in our machines than in production. However some domains and problems are very very hard to figureout before production. Usually, that happens when:

• Production Data is Key
• Legislation/Compliance might make it difficult or even block you from having it in non-prod
• You don't have ownership of the systems/data, and real feedback is delayed until production.
• You cannot replicate prod outside of production

For that scenario, what happens is that you must go to prod in order to see what will actually happen. In that sense getting in production matters a lot. Getting to production always matters, but for those scenarios it's like the "Testing in Production" mentality, except for Discovery. So we need to "Discovery in production". There are techniques that allow us to "discover" in prod like A/B Testing and experiments but imagine if the whole feature feat is a big "Discovery bet". Pretty different scenario in that case the wolrd will be upsite down. 

Because before "Add Quality" you should ask yourself:

1. Do I understand the problem very well?

2. Now that #1 is done, I will do the best way possible ," as complete and comprehensive" as possible.

Now ask yourself, if you are not sure about (#1), and again, this is a business / discovery question, imagine you do:

1. A lot of tests

2. The perfect design

3. The perfect solution

4. All modern, all great

But after some time in production, you discover #1 is wrong, and either your users do not want that, or you are not making a lot of growth with the product, well, someone might say, this is a PMF (Product Market Fit) question. Which lean startup tries to help solve it. 

So, for this scenario, it's a waste of time and resources. Quality needs to come after the right discovery, and we need to be sure, otherwise we are investing in the wrong thing.

Don't fool yourself (with your perspective)

A significant mistake that engineers and young leaders often make is to trust their own observations. Let me be absolutely clear. It does not matter what you think, what matters is what the people who are evaluating you believe. So do not assume:

• Silence is good because it's not.
• No feedback is good feedback
• No complaints is good
• You are doing well just because X number of months have passed

There are only 2 kinds of managers, the managers that are hands on, such managers will spot problems much soon and will complain immediately or in a very short windown like 1 month. However there are other kinds of managers, the ones that are hands off, that ones might take longer to spot something, maybe 3 months, maybe six months but don't be fooled they will get you fired. 

Again, here we are seeing quality as a sense of "performance expectations". Another thing to keep in mind, especially for the most "senior" and "seasoned" engineers, no matter how many years of experience you have, and it does not matter what you did in previous companies, what matters is the current company and current performance.

Reading the silence

Silence has a high cost. You must ask for verbal or written confirmation that you are meeting the "quality bar", you will be surprised that:

• People don't give feedback until it's too late, and you lose the job.
• You might be good in one company and terrible in another (it's all about the expectations on quality)
• No feedback is bad, you want immediately: "Wow, this person is a rockstar".
• IF people do not "notice" you are a rockstar very soon, you are not, and very likely your performance is much worse than you think.
• Don't assume it's okay to NOT deliver your items every sprint.
• People can like you, and still you might have poor performance, therefore deliver poor quality.

You do not want to play with silence. Silence is dangerous, you want constant feedback, from the managers and from the people that evaluate you, all the time, very consistently and very frequently. 

My definition of Quality

Now, let me share what is my definition of quality. I believe in quality in 2 senses, the lean way and the agile way, which means:

• No Waste: Quality is built-in and part of the process, and there is no waste in the lean sense of waste.
• Add business value: In the agile sense, which means growth of users, money, or objectively better like I describe on the begining of the post. 

I believe in always delivering a show, and doing more than people ask(how to give a SHOW):

• Deliver on time (or even before or way before)
• Delivery on budget (idealy with savings)
• Blow expectations to the roof(know expectations very well and do way, way more)
• Add more quality (more tests, refactorings, improve performance, make the place better than you found)
• Impress me (teach me something I don't know)
• Be consistent - do that always

Quality in a project/product

Now, if you ask me, how do I know a project or product has quality? Usually means:

• Great team ownership: Team knows inside-out what's going on, they are on top of every bug and feature, and never miss any commitment. Team also cares deeply about code, design, tests, and the right architecture.
• Good Code/Design: The design is socialized across your team and upstream/downstream dependencies. Also, the code is well written, has a decent code coverage, and decent test diversity.
• Users like it and it has impact on they lifes: There is good user feedback, the company is making the product grow and has an impact on users' lives (a good form of impact).

There are many other essential things I could also add to the list of matters like:

• Infrastructure Automation
• Testing Infrastructure
• Good Observability

High Performance == Quality

For individuals. If you are a high-performing engineer, you add value and therefore your work has quality. Quality and performance go hand in hand. A low-performing engineer always means poor quality in the delivery. 

Quality killers: Performance Killers 

In order to be a killer engineer and have a great delivery cadence and contribute with quality work, there are some pre-requirements that people will never tell you, and they are not obvious, but IMHO, they are the quality killers.

Poor Performance Observability: IF you are an engineer, you must have an Excel file where you track how much you deliver every week. IF you don't deliver 5 PRs a week for a service team, consider that poor performance. Of course, some tasks are bigger and require more work, thats why it's essential to break things and always keep the good work flowing in high volumes. Not delivering the items assigned to you in the spring is a clear measure of poor performance. 

Lack of clear requirements: IF you don't know what you need to do, you can't do it well and fast. Usually, people get JIRA tickets without any description, full of blocks, ambiguity, and missing dependencies. There is no way you will excel in this scenario. So you must push back and figure out things before you start.

Lack of strong technical foundations: usually happens for people who are not doing POCs every day. You must know inside out all languages, frameworks, and libraries you use every day. 

Lack of Focus and Low attention to detail: In order to have a good engineer, you MUST have focus, you must have full attention. IF your environment does not give you that, change it. An engineer without focus and high attention to detail can never ever meet a quality bar.

How to increase Quality

Now that we have a more comprehensive view of quality, here are a couple of tips to improve quality:

• Care about it.
• Make sure your name is always associated with greatness
• Speed matters (deliver before the time)
• Always clarify expectations (all times)
• Avoid silence at all costs, and ask questions early and often.
• Do not assume you are doing well, ask the managers and people that are evaluation you
• Have an Excel for self-performance tracking
• Go deep: Debug the code, read the code, see how others fixed the same problem, search the web, and internal documents. Ask questions, often and constantly.
• Make sure your enviroment gets the best our of you, if is noise, make it quiter, make it with feel distractions, use pomodoro and GTD techniques, make sure you have focus all the time.
• IF people never told you that you are a rockstar, you are vanilla at best.
• Never start some work without making sure you understand all details. 
• Do POCs constanly, everyday, multiple times at the day.
• Document problems in wikis and ask opinions for more senior engineers.
• Add more tests
• Add more test diversity with: Property Testing, Chaos Testing, CSS Testing, Stress Testing, Integration Tests, Mutation tests.
• Refactor code to make it more efficient, reduce processing time, reduce latency, and save cost.
• Make sure you make notes and stop making the same mistakes over and over.
• Take ownership of your performance; it's your problem.
• Give it a show, do more than people asked you, blow the rooft with a killer presentation, a killer PR, a killer wiki, a killer argument.
• Read, Read, Read... papers and good articles.
• Use your mentor's time and ask great questions.

cheers,

Diego Pacheco