The biggest problem in the development and maintenance of large-scale software systems is complexity — large systems are hard to understand. Complexity is the root cause of the vast majority of problems with software today. I am not going into details about where this complexity is mainly coming from and what are the options for handling it. I would like to stop in this article on what, from my opinion, a manager or a leader of a software development team should be focused on when trying to help the team to reach the desired goals.
For a better understanding of complexity let’s look at Wikipedia definition:
Programming complexity (or software complexity) is a term that encompasses numerous properties of a piece of software, all of which affect internal interactions. There is a distinction between the terms complex and complicated. Complicated implies being difficult to understand but with time and effort, ultimately knowable. Complex, on the other hand, describes the interactions between a number of entities. As the number of entities increases, the number of interactions between them would increase exponentially, and it would get to a point where it would be impossible to know and understand all of them.
There are two different type of complexity:
- Essential complexity: Is caused by the characteristics of the problem to be solved and cannot be reduced.
- Accidental complexity: Relates to difficulties a programmer faces due to the chosen software engineering tools. A better fitting set of tools or a more high-level programming language may reduce it. Accidental complexity is often also a consequence of the lack of using the domain to frame the form of the solution i.e. the code.
I would like to pause at the definition of accidental complexity. If try to think about complexity not just of the limited scope of a programmer, but more from the view of managing a software team, then I think we can add more to the list, not just tools and program languages.
Few things that are coming to my mind, because in a way or another I was involved in all of them, are:
- people management (communication, conflicts, and resolutions)
- requirements management
- release management
- deployments, devops
- performance reviews
- hiring
- logistics (computers, desks)
As may be many other team leaders or managers, when I was for the first time promoted in the position of the software team leader, I was trying to figure it out - so what exactly are my responsibilities, where is my part starting and ending, how do I know if I did a good job?
Now, that I have few years experience as a team lead and now as a manager, I came to the conclusion that the main purpose of the software team manager is to manage accidental complexity so a team can concentrate on essential complexity.
If the team is worried just about essential complexity than I am doing my job well, otherwise, there is definitely space for improvements.