Resilience is a concept I love. It has many different meanings, but the one I prefer is our ability to face difficult situations and resolve them, learning from them and coming through stronger and better for it. Experience can destroy us, but it can also make us stronger; it all depends on the attitude with which we face it.
For years, I’ve naturally applied this more psychological concept to the software projects I take part in. In short, I try to learn from mistakes and improve whatever can be improved—no more, no less. Over time, this helps us build up better knowledge and better ways of doing things and approaching projects. The worst thing in any project is realizing at some point that we’ve stumbled over the same stone again.
But is there anything to improve? We can’t learn from situations if we don’t even ask ourselves whether anything could be improved. I’m afraid there’s sometimes too much arrogance in our industry for people to acknowledge their mistakes.
There’s always something to improve. If we’re brave and humble enough to acknowledge it, we’ll gradually become better professionals.
We keep improving when we’ve made this ability to improve a daily habit. That’s why, whenever I finish a new project or a development sprint, I like to review everything that could be improved and, sometimes, hold a session I call Lessons Learned. In it, every team member, myself included, acknowledges where we may have gone wrong and identifies what we could improve for the next project.
Anything is fair game in these sessions: technical problems, lack of resources, poor communication with the client, or anything else that may have negatively affected the project’s progress.
Since we’re talking about software, these questions come up regularly in any lessons learned session, whatever the specific nature of the project:
- If there were significant delays in delivery, what caused them? What could we do to prevent them on the next project?
- Did development mostly follow the specifications? It’s not unusual for a client to revise or try to add functionality that wasn’t initially specified. That’s normal and common, but it becomes dangerous when we try to include the whole package of uncosted requirements in the same project without changing the deadlines or cost estimates. The person communicating with the client needs to be diplomatic but firm, so the team isn’t adversely affected.
- Were all the expected project artifacts produced correctly? Depending on the project, these could include deployment documentation, a user guide, maintenance documentation, and so on.
- Once the project was in production or delivered to the client, were any serious bugs found? If so, something must have gone wrong with the project’s testing.
- Did we do enough refactoring and clean-code work to leave the project pristine, clear, simple, and approachable when someone picks it up again in the future?
Each project will determine what kind of evaluation is appropriate. What’s important is to finish a project with stronger knowledge and broader experience, so the next project doesn’t suffer from at least the same problems—and, naturally, to leave the client very satisfied with the work and confident enough to trust you or your company with future projects.
Technical competence and good work aren’t demonstrated at the end of a project; they’re demonstrated throughout it. That’s what the client needs to see.
The main obstacle to holding these kinds of constructive sessions in any workplace is the lack of a culture of acknowledging mistakes. How can we admit something wasn’t done quite right if we think our boss will value us only if they believe we do everything perfectly? How can we distinguish ourselves from colleagues or competitors who, just like us, want to show how good they are? Our boss will soon realize that nobody gets everything right all the time.
To me, acknowledging a mistake is the first step toward excellence, the only attitude that can help us improve—especially in software, where any project has so many different ways to get things wrong.
If we don’t learn from experience, we’re in trouble. As I always say (paraphrasing the great Raimón Samsó), “if we’re not improving, we’re getting worse.”