Just by making the architect role explicit, a team can effectively resolve many technical conflicts.
Quality must be enforced, otherwise it won’t happen. We programmers must be required to write tests, otherwise we won’t do it.
If I don’t understand you, it’s your fault.
Any software project must have a technical leader, who is responsible for all technical decisions made by the team and have enough authority to make them. Responsibility and authority are two mandatory components that must be present in order to make it possible to call such a person an architect.
All companies are built as hierarchies, no matter what that holacracy adepts are saying now. It’s always a boss on the top and then people who report to him down to the lowest level. Staying on the lowest level is what I always try to avoid. Not only because I have some dignity, but mostly because I am lazy. The lower you are in the hierarchy, the more work you have to do and the less money you get for it. This is how the division of labor works, not only in the software industry.
We must not blame programmers for their bugs. They belong to them only until the code is merged to the repository. After that, all bugs are ours!
The higher the price of information in a software team, the less effective the team is.
We, newbies and young programmers, don’t like chaos because it makes us dependent on experts. We have to beg for information and feel bad.
Automated testing is a safety net that protects the program from its programmers.
Responsibility means an inevitable punishment for mistakes; authority means full power to make them.
To make technical decisions, a result-oriented team needs a strong architect and a decision making process, not meetings.
Punishment demotivates when it comes from people rather than a system of well-defined rules.
The job of a tester is to prove that the software is bug free, while it has to be the other way around: The job of a tester is to prove that the software is broken. The better testers are doing their jobs, the more bugs they manage to find and report.
It’s impossible to change the management system without changing the managers who built it. The management is the product of people who created it.
It’s a good thing to remember – doesn’t really matter what the quality of your code is, your political views or your sense of humor are much more important. Isn’t it unfortunate?
Fixing the system without fixing people that work in it would be a huge trauma for them; they will do everything they can to prevent it from happening.
It is not loyalty or internal motivation that drives us programmers forward. We must write our code when the road to our personal success is absolutely clear for us and writing high quality code obviously helps us move forward on this road. To make this happen, the management has to define the rules of the game, also known as “process”, and make sure they are strictly enforced, which is much more difficult than “being agile”.
Every conflict must produce a win-win outcome and must never be resolved through a compromise, which makes both sides suffer in some way. Even forcing one side to do what the other side wants is better than a compromise.
Very often managers are just a noise, while the real boss is the project, which we work for and which pays us.
Quality is a product of a conflict between programmers and testers.