Working as Technical Lead is very exciting; every day you have new challenges, new problems to solve and a great deal of satisfaction. However, sometimes you need some tips in order to improve and empower your teams. There are several techniques to ensure the quality of the products we are working on, but the most important, and powerful at the same time, is, without any doubt, the feedback loops. As you know, working on a new software is more empiric than scientific, which is why we need metrics and small, but incremental, improvements if we want to meet the needs of our users or clients. Feedback loops are a very basic, but powerful methodology designed to help us and our teams to succeed in their daily tasks. With feedback loops, you are sure you'll get the feedback and metrics that will allow you to improve your projects. Moreover, thanks to the feedback loops, you will also have some metrics to show to managers or technical architects to justify the technical decisions, show how a project has progressed and what kind of issues your team encountered during the development process.
The majority of the following techniques are probably already in place inside your organisation, but maybe you want to get different metrics or shorten the feedback loop in order to have more information to decide which is the best strategy to use.
In this article, I’d like to share some techniques that could help you to achieve the final goal of a Tech Lead, which is, of course, creating a strong technical environment that can be relied on and which empowers the developers to do their best every day, feeling secure and aware of the quality of their code.
Pair Programming & Code Reviews
Two techniques that could provide you with immediate feedback and benefit are sure pair programming and code reviews.
Let’s start with Pair Programming first.
When we think about this technique, the first thing we'll have to justify to our managers is whether the effort of using two resources on the same piece of code is worth it or not. When you have a good experience of how pair programming works, you should be able to decrease the productivity by up to a maximum 15% and, at the same time, you'll increase the quality of the code and the shared knowledge through the team members, and it will also help catching the bugs sooner than later in the development. This last consideration might seem like just a minor improvement, but catching a bug sooner could help to reduce the effort needed to fix it; if you catch the same bug later it will probably cost the company more because the effort needed to understand an "old" implementation will be doubled, or even worse. There are two things you should bear in mind when you work with Pair Programming. First, you should encourage doing it for a couple of hours every day, changing the conductor every 30 minutes. Secondly, you should create a pair programming station where there is only the software the developers need in order to produce code; so, no email or chat clients, but literally the minimum configuration to work on the project.
Let’s move on to the code reviews, now.
I quite often saw skipping of this practice because we were close to the end of an iteration or, even worse, close to the final delivery. The code reviews are essential to spread the knowledge of the code throughout the team members, maintain the code consistency and technically improve the project. The main downside, in my opinion, is that code reviews are usually done after a few days or so and if they are not done properly you could lose all their benefits. If you want to have the most and best benefits from this practice, I'd suggest to often commit your code in your version control system and ask one of your colleagues to check your code that same day, possibly creating some slots during the day to check the code of other developers. Remember that code reviews can be a genuinely powerful and effective technique if used properly.
Incremental Design
This is definitely my favourite feedback loop technique, as you know for sure that the up-front design of any project often leads to wrong assumptions, misinterpretations and to having too much guessing on the technical side. The best way to approach a project on the architectural side is to create enough architecture at the beginning of any project to allow you and your team to start the development, and then to review the architecture and the design decisions incrementally at the beginning of each iteration for 30mins to two hours, focusing on the tasks needed to accomplish for the new iteration. This way you'll create an organic architecture that will perfectly cover the needs of your clients or company and will facilitate the implementation of new features or refactor. You'll see that, at the beginning of the project, you're going to have to invest more time in the architecture, but, after a few iterations, you'll see less investment and plenty of benefits for the consistency and quality of your architecture. The best way to design an architecture is in front of a physical whiteboard, where you can have immediate feedback from the other members and you can also quickly add, modify or delete elements. Remember that this documentation, if not updated, will not be used inside the company, so what's the point of using expensive modelling software when the code should explain the decision by itself?
My personal suggestion on this topic is to create a high level view diagram on how the main components of your system are related to each other, so as to have an idea whether your architecture works or should be improved. In this case, the document is very easy to produce and doesn't require too much effort to be updated.
Static Analysis
Any Tech Lead should master static analysis, because it provides useful metrics that could help you to identify potential issues in your project and highlight areas of improvements. The most used technologies, like Java, C# or Javascript, offer plenty of tools that could help to retrieve information on the code side, such as the cyclomatic complexity, for instance, or a representation of the project architecture. Tools like SonarQube are useful to have installed on a server and, for each technology used within your team, you should be able to set the rules to drive the code following the company standards. Remember to define the rules to follow and automate the process in order to facilitate your team to inspect the data and get insights from them, because, with metrics, you can make improvements, otherwise it could be difficult to realise whether a particular change helped to improve your software or not.
Version of Control
As Tech Lead, you should be the code base guardian of the company. Having a messy code base means that, after a few years, or even a few months, the company or a team would no longer be able to maintain that project or would struggle to implement new features or understand how to solve bugs.
In this case, I suggest bearing in mind, and reminding your colleagues about, the "boy scout rule":
“Always leave the campground cleaner than you find it”
Currently the best solutions are GIT or Mercurial. GIT is better known and used by many companies, so it means there are more resources and documentation, Which is why I suggest having GIT as your version of the control system. It often happens that a company uses GIT, but without any branch strategy; therefore, each project is simply the wild west. You should avoid these situations by implementing a GIT flow or a GitHub flow strategy. You'll find that implementing one of these two strategies will increase the productivity of your developers and avoid the constant conflict issues when you try to merge different branches. Another important thing for all developers to remember is the tagging phase and to write meaningful comments when they commit the code. In particular, when you work with software releases or with libraries, it is fundamental to tag every stable version of your code before distribution. Last, but not least, when the developers commit the code, ask them to describe accurately what they have changed and, if it's possible, commit frequently during the day, so they can easily revert the code or resolve any conflicts in the code base.
Automation
The automation should be defined at the beginning of any project, if it's not already defined at company level. Having a replicable and deployable solution to use over and over during the development of a project is mandatory in order to ensure the correct delivery of the final artefact and avoid any problems when the project gets close to delivery date. Usually you should be able to automate:
- all the mutation, integration, acceptance, regression and functional tests for your project, possibly hooking your version of control solution with the automation tool you are using to run all the tests for every commit ,for instance, or anytime you merge in development or the master branch
- static analysis before any build will help you to enforce the code standards and the quality of your product
- tagging process and version of control management after each tag or release
- deploy the project to the test environment for the QAs
- deploy the project to live
When you have defined all these steps at the beginning of any project, you'll see that you'll avoid the most common issues of having to rebuild a project after several months or years, you'll be able to adjust the quality of the code release after release, keep a high code standard and retrieve metrics to plan a strategy for improvement inside your team or company.
Agile methodologies
The technical flow isn’t the only thing you have to maintain properly, the e information flow is also essential for the success of any project. It's true that you are not a Scrum Master, but you should help the Scrum Master to facilitate the information flow, possibly help the Product Owners to define stories and understand the right moment to introduce technical stories to improve the code quality, help the team to size stories by highlighting possible technical issues and so on. So, for these, and many other reasons, having a good understanding of the most used frameworks, like Scrum, Kanban and XP, is very important for a Tech Lead because, as leader, you should be able to lead by example, showing and encouraging your team to follow Agile best practice and guiding them to the success.
Community of practices (COP)
Sharing experiences and knowledge and improving ourselves on a daily basis should be a must in any technical team. Organising a bi-weekly or monthly community of practice could really help to achieve these goals. Usually, a COP is a session where anyone in the technical team could share a smart solution used in a project he or she is working on or a new technology/methodology that could be helpful for the whole team. If the company is big enough, I suggest dividing these meetings as per skills; thus, a COP for QAs, another one for Back End developers, another for Front End developers, and so on. As such, the arguments will be more vertical and useful without wasting time on technologies or methodologies that someone can't use in the short/medium term. A good community of practice should be organised 7-10 days beforehand, having between one to three speakers with each of them talking for 20-30 mins. If there is only one speaker, I would suggest finding a topic of a maximum 45 mins and leaving the second part of the session for questions and open discussion.
It's fundamental to have a facilitator in this meeting, at least for the second part, to encourage any attendee to share his/her thoughts on the argument. Creating a friendly and collaborative environment will help the team to be more confident in their own skills and you are going to create a shared knowledge that could facilitate the introduction of new technologies and methodologies throughout the organisation. As Tech Lead, you should be able to organise these meetings, facilitate the discussion and find topics that could be interesting for the whole department or company. Sometimes, to break the routine of everyday life, I suggest watching videos from conferences or meet-up talks or inviting external speakers to share a vertical topic with the team, and then having an open discussion on it.
Wrap Up
These are really the key activities and techniques that any Tech Lead should master and encourage during his/her daily job.
You definitely need to be flexible and skilled enough to apply the right approach to any situation in accordance with the business requirements and in line with company strategies.
Last, but not least, I’d like to leave you with my favourite aphorism to encourage you to start improving your standards: “The journey of a thousand miles begins with one step” - Lao Tzu
About the Author
Luca Mezzalira is an Italian passionate technical lead with more than 10 years of experience on front end technologies like Javascript, HTML5, CSS, Actionscript, Haxe and Lua. Luca is very passionate about software architecture and he is highly focused on any project to create the best solution to achieve the main goals in any project. Currently he is living in London and his focus is on Javascript frameworks and libraries, in particular React and React Native; web and mobile performance and obviously on Agile techniques. Luca is also an international speaker (over 60 talks around the world), co-organiser of London Agile Leadership Community and technical reviewer for Packt Publishing.