In the last few months, I have been coordinating a software project as a tech lead. From a PR perspective, we are calling this position as a tech lead, but in reality, I am undertaking an architect role.
It is a lot of fun to launch something from scratch. Sometimes it is not fun, as decisions in the dark may appear scary at times, but as a part of a Scrum team, we are always there to correct course. I am also surrounded by great people who catch whenever I overlook something.
As I gained a lot of experience in the corporate world, I started understanding how corporations work, what a nine-tier corporate structure with directors and vice presidents are like, and I also started grasping the essence of what skills are needed to get to the top. This article will focus on the tech lead role in the context of requirement analysis and software design.
The Tech Lead Role
A tech lead of a project can do many things that help move the project forward. This includes
- taking architectural decisions,
- resolving disputes on technologies to be used,
- overseeing the functional and non-functional requirements,
- setting up repositories, project structure,
- driving architectural and detailed software design,
- helping the team deploy an application to the cloud,
- setting up a continuous integration pipeline,
- and surprise, even coding.
Tech lead is a role, not a position. You may be a tech lead in one project, and may have a completely different role in another.
Tech lead is a lead for a reason. In an environment, where team members are highly autonomous, team members go to the tech lead for advice. High autonomy means that anyone who is responsible for a task, is entitled to take a decision. The tech lead is just there to provide direction, and stabilize the team.
There are some ivory tower tech leads and architects out there who never code. Similarly, you can meet some managers in most organizations who know some very high level concepts, but they do not know how to help out another team with information, because they are not connected to their own domain that deeply. They delegate and stay on very high level. Some managers and directors admit these loopholes and point at the right person. Others play a game and are afraid of admitting if they don't know something. Similarly to the latter types of managers and directors, an ivory tower architect is often a burden for the team, because this type of person distances himself from the real world. So much so that he will delay the team rather than helping them out.
The worst type of ivory tower architects may do something called productive procrastination. They appear productive by focusing on the wrong things, and distracting the whole team with requests that no-one else cares about.
The other end of the spectrum is a tech lead who is capable of solving any challenge, maybe even a bit better than most of the team members. The practical tech lead codes less than the average because of adding more value elsewhere.
Leadership is responsibility. On all levels, leading means serving. Those who want to shine in the spotlight should immediately switch to an acting career. In today's world, you don't even need gatekeepers, as you just need to learn some acting skills to start a Youtube channel. Then you may convince a less tech-savvy audience that they can make $100 an hour after investing a few months of their hard work in your course. Is it possible to earn $100 per hour this way? Yes. Is it likely? No, especially if your audience has trouble with basic math.
What does a Tech Lead do during Requirement Engineering?
A tech lead is helpful during the whole software development life-cycle. During requirements analysis, a tech lead helps clarify the following aspects of the requirements:
- Functional requirements,
- Non-functional requirements.
Functional requirements describe the software we are building.
Non-functional requirements describe the quality of the system we build. This includes the specification of the maximum tolerable downtime (availability), data protection issues, scalability etc.
Functional requirements may imply non-functional requirements. Both functional and non-functional requirements drive architectural decisions.
As a consequence, the tech lead should be involved in exploring the requirements by asking the right questions.
Discovering Functional Requirements
Functional requirements describe the software we are building. This includes:
- understanding who the users are,
- understanding what problems the users want to solve,
- understanding why the users want to solve the problem.
A great way to specify acceptance criteria for software is Gherkin. See the role of the who, what, why in the structure:
AS AN Advertiser
I WANT TO set up Advertising Campaigns
SO THAT I market my product
There are different tools to capture requirements. Without understanding the users, also known as actors, the workflows associated with the users broken down per role, and the context in which our system operates, the software we develop will be unlikely to address the pain points of the client.
In a Waterfall project, the scope of the whole project is determined upfront, which means that by the end of this phase, the requirements are more or less set in stone. For instance, if you order building a house, you will have to clarify in advance what kind of house you want. When the architect goes to work to create an architectural plans for the building you ordered, you will rarely change your mind saying that you want to add a second level on top of the building.
In agile projects, requirements often change. We tend to embrace change. We still do our best to collect all requirements to the best of our abilities as early as possible, but we expect change to happen.
Being agile should not be an excuse for not gathering requirements to the best of our abilities. Giving an excuse that requirements will change anyway, so why create requirements, is called ignorance, not agility.
To course-correct, we need a well defined direction. This direction is provided by functional requirements.
Similarly, there is a big difference between data that get updated live, hourly, and daily. Back in the days, I was the tech lead and architect of a stock trading application on end of day data. We imported our data from an Australian data provider once a day. Our clients wanted live updates, so we had to completely change the method how we got the data.
A tech lead should be there to monitor requirements, because often times the client does not know what they want exactly, until they receive the right questions.
I have seen requirement documents that contain logical contradictions. Humans often have a hard time describing what they mean by using conjunction and disjunction. Many non-tech people mix
or. When they write
or, they often mean
I have seen user stories that did not deliver any value to the client while they drastically increased the complexity of the solution. A good tech lead is supposed to point these issues out, either by recognizing them, or by delegating and supervising the analysis of technical requirements to an expert.
When discovering functional requirements, high level analysis of data may be needed to understand what the system is doing. This may include:
- a context diagram detailing the system and its boundaries in terms of data flow
- a data flow determining how data is transformed by processes inside the system
- entity-relationship models, which act like the foundation of a building, because both the database schema and the business logic depends on it.
What kinds of non-functional requirements do we need to pay attention to?
Once more, non-functional requirements describe the quality of the system we build. Quality is measured by some metrics that need to be defined clearly to drive architectural decisions.
I assume you don't need this article if you are designing a mission critical application where human lives or trillions of dollars are at stake, therefore, I will focus on the typical non-functional requirements we focus on in a project:
- Availability metrics
- Performance metrics
Let's explore the role of these non-functional requirements one by one.
Availability describes the percentage in which the system operates according to the specification. Think about your Internet banking software. What happens if it is down between 1AM and 3AM? Not much. Bank transfers are not live anyway, and in case of emergencies, there is a telephone operator that can handle your request. In other context, just one minute of downtime threatens the lives of people, or causes a financial loss of billions of dollars. Availability is usually measured with nines.
In the telecom sector, 99.999% is a usual availability metric. What does this mean exactly? 0.864 seconds a day, or just over 5 minutes a year. Designing a system with such a high availability requires drastically more resources and fault tolerance than a system with 99% availability, where our system can be down for 3.65 days a year.
Performance metrics are typically connected with the amount of time a request is responded. In an enterprise application, a report for a member of the executive team may take a minutes to compile. Compare this to day traders, who compete against each other with decreasing the latency time from their office to the center of the stock exchange. They also minimize their response time with algorithmic trading software that acts as soon as the necessary conditions are recognized. At the same time, some people still believe that day trading is an easy living, even if you do it manually.
Performance metrics may make it impossible to use certain technologies, as there is a size of data, where your MySQL database will never respond. In other cases, you can choose between blocking I/O (PHP) and non-blocking I/O (node.js server). You may also have to consider the computer of the client to take appropriate client-side decisions.
Scalability is a metric that determines future performance needs for your software as your user-base grows. This metric is loosely connected to my article An Introduction to Microservices. You may create a monolithic application to validate your idea as an MVP (Minimal Viable Product). Then you can scale the performance bottlenecks by extracting microservices out of them.
Compliance is an important metric, because your application may be constrained by the legal environment. Legal standards for Data Protection, or licensing in case of online gaming companies are two mandatory elements that may pose an existential risk to companies. Another example is governmental tenders, where all formal elements have to match the required elements.
Security is an important metric that is often connected with compliance. For instance, data theft is caused by a security hole in the system. While a small startup will not do much except for declaring a bounty program and reward ethical hackers with some cryptocurrency, corporations are often obliged to audit their system and maintain a security team looking after all software solutions. This team performs penetration testing to make sure the software solution does not contain serious security vulnerabilities. Requirement analysis should deal with these security issues based on the associated risk, which means, some non-functional requirements are dictated by security requirements. For instance, the authentication and authorization system may be constrained by security requirements.
Maintainability is implied by the life-cycle of the software. Are we building an MVP to validate some ideas? Is development speed more important than maintainability? Maintainability is like a financial account. When the quality of the software is sacrificed, it is like borrowing money. This money has to be repaid at a later stage with interest. If too much money was borrowed, we may never be able to repay the lone and we go bankrupt. In software terms, we don't borrow money. We create technological debt. This debt has to be repaid to avoid bankrupting the application, unless the application is meant to be bankrupted. For instance, an MVP may be completely thrown away, as its main purpose is to validate a business idea. The MVP should be developed fast, often without considering maintainability. On the other hand, a complex system automating all business processes of an organization will have to be maintainable, otherwise one day we realize that feature development takes a lot more time than before.
Extensibility is one aspect of maintainability. It is often implied by functional requirements. For instance, your task may be to build an MVP for one special client, but you should prepare the system to be used for any client in the industry with minimum customization.
Always think out of the box, as there is no checklist to extract all non-functional requirements that cover all cases.
Non-functional requirements may also be derived from the golden path approved by your organization. Bigger organizations tend to standardize tools, programming languages, frameworks, libraries, cloud providers, and almost everything related to software development. Consider this before innovating too much in your architecture.
Many other considerations may contribute to non-functional requirements, including the competencies of the development team, and internal politics.
Soft-skills as non-functional requirements
You have to know the stakeholders of the project.
For instance, due to automation, the users of the system cannot exploit a loophole anymore for financial gains. This implies that they won't cooperate with you, because their interest is to continue exploiting the system, not to help you make the processes better.
For instance, if a disease diagnostic system automatically prescribes the best medicine for a symptom, the doctor won't be able to get bribed by the marketers of a favored, but sub-optimal medicine so that they get more prescriptions.
A tech lead coordinates architectural and engineering decisions throughout the whole software development life-cycle, and leads his or her team.
In this article, we discovered the role of the tech lead by analyzing requirements. Requirements can be functional or non-functional. All requirements lay down the foundations for architectural choices.