Journey through software development

Books

In the career of a professional developer there is a time where we are asked not only to produce high quality software but also to become a leader for our team. And this new task requires different skills in order to be achieved, being a leader is not easy and it can definitely be frightening.

In this blog post I will not share my experience regarding this topic. Why? Simply because, when writing these lines, I am not a software team leader. And therefore I cannot give you tips for an experience I have not yet lived.

This article will be about a book that shares the experience of an actual team leader: Roy Osherove. In his book, “Notes to a Software Team Leader“, Roy explains the concept of the elastic leadership and also what are the 3 phases in which a software development team can be.

Why did I read this book?

You might wonder why I read this book about software leadership since I am not a team leader. And I asked myself the same question before reading the book. Well, maybe one day I will be asked to take the role of a leader in a software development team.

I am the kind of person who likes to plan ahead and therefore I decided to read this book about the responsibilities I might have one day. By doing so I will be able to have ideas about what will await me for this challenge.

Also, the two senior developers of my team read the book and they referred to its content. They spoke about comfort zone, commitment language and others topics. And it made me curious, so I decided to read the book to able to understand what they were talking about. And after doing it I was able to understand a bit more their situation and mine as well in the team.

In some software development teams there is no formal team leader, there are only programmers which have to work with each others in order to complete the tasks they have. And sometimes you are the most experienced developer of the team in the company and even if you did not ask for it, you are kind of the leader.

I went through short periods like these ones during my career and it can be stressful because you just don’t know how to behave when facing some situations. Reading the book can be helpful to understand in which phase you currently are and how to get out of it.

Elastic Leadership

The “ultimate” style of leadership just does not exist. If it does we would all know it by now. To be an effective leader you will have to adapt to the context you are working in, the work environment, the personalities within the team and everything that can have an impact on your team. Your leadership has to be “elastic” and you have to adapt it depending on the situation.

In “Notes to a Software Team Leader”, Roy Osherove describes 3 different kinds of leadership: command-and-control leadership, coaching leadership and facilitating leadership.

In a command-and-control mode, the team leader tries to solve everyone’s problem. This looks commendable for your team but it can also prevents your team members to learn anything since you are doing all the work.

The “coach” leader is great at teaching new things to others. He will let you experienced new things and sometimes let you do some mistakes if there are lessons to learn. This mode is helpful for your team but in some situations you can’t do it because your don’t have time for it, there are too many fires to put out.

The facilitator leader stays out-of-the-way. He makes sure that the environment is optimal for its team and relies on the skills on the team members to get things done. This type of leadership cannot be achieved if the developers are not experienced enough to face the challenges they have to deal with.

These three leadership styles can be applied to different phases that a team can encountered during the lifetime of a project.

Survival phase

Does your team spend its days on putting out fires? There is absolutely no time for learning new technologies and technics? Then you probably are in the survival mode.

Even if does not look like the kind of environment you want for your team it can be appealing to stay in it. Why? Because day after day you will do the same kind of work, the kind of work that feel “safe” because you have already done it, several times. You are in your comfort zone even if there are fires everyday.

To get out of this phase, you have to break the circle by providing slack time dedicated to learning. By gaining new skills the team members will be able to deal with more issues they have to face.

For example they can learn about refactoring technics in order to decrease the technical debt of the project. They can learn how to add unit tests to the source code.

You should not see these learning opportunities as a waste of time but as an investment in your team.

The survival phase is the time where command-and-control management can be helpful. You take control of the ship to avoid sinking and you give orders. To correct previously made bad decisions, to avoid mistakes you know will happen. Your job is to get the team out of the survival mode, to aim for the learning phase.

Learning phase

In this phase, the focus is on gaining new skills. The project is more stable than it was during survival phase and you now have time to spend on improving things.

You are no longer needed to apply a command-and-control type of management, you now need to act as a coach. Helping your coworkers to learn is your goal.

When learning you are not increasing your productivity at a constant rate, the curve is more like the one shown on the graph below.

Learning Rate With Ravines

There are ravines before each peak, they are adjustment phases and they might seem painful because your productivity is decreasing. Yet you should embrace them because they are leading you to new paradigms, skills and knowledge, you are stepping outside of your comfort zone.

The learning phase is the perfect time to teach about commitment language. When you will do something, you mean it and you will actually do it! I wrote an article about “saying yes” a while back, where it is all about commitment.

You also have to teach your team to start dealing with its own problems, the one you were dealing with during the previous phase. When a new issue is raised by a member of your team you should give them the following answer: “What will you do about it?“.

This question aims to make the members take actions in order to deal with the challenges they are facing everyday. And they of course have to answer the question using commitment language.

But what if the solution is not in our hands? Then in which hands is it? What prevents you from speaking to this person/team to explain your issue?

Even if in a lot of situations we cannot fix our problems alone, this does not mean that we are powerless. There is always an action that can be done by ourself to get closer to the “fixed” state for our issue.

During the learning phase, the team leader has to focus on the autonomy of its team to make it self-organized.

Self organization phase

When the team enters the self-organization phase, you can follow the facilitating kind of leadership. You act as a guide and remind your team the concept they learned during the learning phase, such as the commitment language.

You do not have much to do, you give your teams goals and after that you just get out of their way. They should know how to deal with the challenges they will face. They will learn the skills they need in order to get things done.

During this phase there is not much else for you to do.

Conclusion

As a software team leader, I think that your job is to strive to create self-organized teams. In a way you have to make yourself “unnecessary” by making your team autonomous. Don’t worry, this is a long and fastidious work so you won’t be unemployed just after a few months. And when you reach this goal, you can take another team stuck in the survival phase and grow the people working in it. There are a lot of software development teams that need your help!

This is just an overview of the book content and I can only encourage you to read it to learn more. I think that it is not only intended to be read by team leaders but also by every professional programmers who is interested by the phases a software development team can be in.

“The Clean Coder” is not a book about the code, it is about the coder. A software developer does not only write code for himself, he writes code to solve problems, to add value to his company. In this book Robert “Uncle Bob” Martin shares his experience on the mistakes he did and how he changed his behavior in order to act as a professional.

I really enjoyed “The Clean Coder” because it made me think of my own behavior. Do I behave as a professional ? What can I improve ? What should I stop doing ?

This software development ideology suits me, it gave me a path to follow. I decided to sign the software craftsmanship manifesto to be committed and to ask more of myself. Being a craftsman is not an easy task, it is an attitude that has to be learnt. It is challenging and that’s fine to me. I like to be challenged, it allows me to improve.

I hope you liked this journey through “The Clean Coder”, see you next time !

Software development is a relatively new profession, new technologies and discoveries make it changes constantly. Thereby it has not been codify yet, there are several methodologies, principles, practices and patterns. And this is a good thing, we still have a lot to explore to master and contribute to our craft. Yet, this lack of codification allows us to do whatever we want and sometimes in a bad way. We’ve all seen teams that defined themself as “agile” because they do not have any single methodology and use the term “agile” as an excuse for chaos ! We’ve all seen a two or more years project that does not have a single test ! We’ve all seen programs that become unmaintainable after 6 months of coding ! We’ve all seen projects that have more bugs than lines of code ! Somehow this is the cost of our new non-codify profession. Fortunately there are a lot of well designed, covered with tests, maintainable software too. It is up to us to share our knowledge and best practices with each other, it is up to us to codify our own craft.

Even if software development is new, we all had mentors to teach us programming. We learned through teachers, colleagues, books, videos, articles or even friends. Forty years ago when programming was starting all these resources were scarce or non-existent. Uncle Bob (“The Clean Coder” author) had to learn programming the hard way, without all the resources we can find one mouse’s click away. If we work with senior developers or any experienced professional we can ask them to share their knowledge to teach us how to behave as a professional. And we can of course share our own experience with the younger ones.

After graduation, a medical student is not thrown into an operating rooms to perform brain surgery or open heart surgery even if he as the theoretical knowledges to do it. The medical profession oversees education through intense mentoring. Medical students spend a lot of their education time working with professionals to sharpen their skills. It takes a decade and thousands hours of practice to become a professional doctor. Are we shocked by this approach? Of course not, we cannot even conceive it otherwise. Their work is highly important and we expect them to act as professionals.

In the software industry, things are “slightly” different from the medical system. It is no surprise to see “teams” formed with freshly graduated programmers that are asked to build software even critical ones. Of course creating programs is not as crucial as surgery, there is no life at stake. But bad software can lead to colossal monetary loss, Sony is one example of many. Graduating in Computer Science (CS) gives us enough skills to work in the domain but schools can’t teach us everything about programming. Software development is a complex world that evolves day by day and offers us an environment with constant learning. Creating a doctor-like system for our professions is essential to avoid making the same mistakes over and over.

Software apprenticeship can be a three steps journey : starting from apprentice and moving to journeyman before becoming a master.

Masters have more than 10 years of experience and have worked on different systems, technologies and programming languages. They are able to lead and coordinate several teams. They are responsible for the technical aspects of the projects.

Journeymen are trained and competent programmers, they are professionals. They learn to work as teams and to become team leaders. Their experience levels vary among them, there are former apprentices with little experience and there are burgeoning masters.

Apprentices are programmers that just begin their career. They are closely supervised by journeymen in order to improve their skills and knowledges, pair programming is heavily recommended to do so. They learn how to behave as professionals.

This system is similar of the guilds organization during the medieval era. In the real world this system seems to exist, graduates are supervised by young team-leads who are supervised by project-leads. But most of the time there is almost no technical supervision.

When we build software, we are crafting them, programmers are craftsmen. Craftsmanship is the mindset help by craftsmen, it contains values, disciplines, techniques, attitudes and answers. A craftsman is able to work quickly but without rushing, he also know when to say “no” and to meet the commitments. A craftsman is a professional !

If craftsmanship is your way of life keep in mind that you cannot force other programmers to become craftsmen, and convincing them is difficult. If you want them to become craftsmen you’ll have to show them how it is done and the benefits of it. Then maybe they will join the movement.

This was the final chapter of “The Clean Coder : A Code of Conduct for Professional Programmers” by Robert C. Martin. My next article will be a conclusion about the book, explaining what I’ve learned.

Your organisation might have several teams and several projects. It is important to know how to manage these 2 areas of your IT department in order to get things done.

In a “project first” environment it can happen that some people will work on several projects at the same time but with different teams. A developer working in this type of environment will have to learn the methodology used for project A and the one used by the team on project B which can be completely different from the first one. He will also have to learn to work in an effective way with the people of project A and the ones of the other project. Making these switches over and over can be annoying or even frustrating. At the end this will result in a loss of focus for the people working on distinct projects.

Forming a team (a real team and not a group of individuals) is a long process. It takes time for the members to know each other, it takes time for them to know each other strengths and weaknesses, it takes time to understand each other motivation. The members will start to form relationships at some point, the team begins to gel. However having a gelled team is worth the waiting, the members will enter into a new dimension, they can do miracles. They will anticipate each other, they will support each other and they demand the best from each other, they make things happen.

In software development a gelled team is not only composed of programmers, the testers and the business analysts are part of this team as well, all of them working with a project manager. They will all plan together, face issues together and solve problems together, they work as a team. The analysts develop the requirements and are able to write the acceptance tests through user stories. The testers will also write acceptance tests from another perspective, they focus on correctness providing failure scenarios where analysts focus on the happy path. The project manager tracks the progress of the team and makes sure that the team is heading the right way.

Once your organisation has a gelled team you do not want to break it, you want to keep it alive. When the team’s project is reaching its end, give them a new one. They already know how to work as a team and they can focus on this new project right away at full speed. These kind of teams can even work on several projects simultaneously once they know their velocity. This velocity is shared amongst the projects depending on their importance and can be reallocate during crisis for example. It is easier to switch from a project to another with the same team than switching from a team to another.

Building teams is way harder than building projects, this is why it is important to persist them and make them work on a project after one another. In some cases they can even work on more than one at the same time. It takes time to build these teams but once it’s done they exceed the expectations you had.

Software are made by teams and collaboration is needed in order to be efficient and to produce quality.

Sometimes we choose to work in programming to deal with the predictable behavior of a machine and not with the messy relationships between humans. But at some point dealing with others is mandatory in order to achieve our work especially with Agile methodologies.

Except if you work for yourself you will have employers and you have to keep in mind that their business is your business. They pay you so their problems are also your problems. Professional programmers collaborate with the managers, business analysts, testers and other team members to deeply understand the business goals. If you do not understand it how can you provide the best solution to the business problems ?

In a development team programmers have to work with other programmers. Do not fall into the “my code, my precious” attitude, it is not helping anybody. Maybe you think that your code is perfect and everyone should do the same. Perfect code does not exist ! Some developers will prefer a strong design over performance and some will prefer the other way around. It is just a matter of perspective. When you build walls around your code and your scope, you are doing harm to the entire system. It can not work as a whole, how can it move forward if one leg refuses to move ? The code of your application is owned by the team, not by the individuals. So code as a team : share your design ideas or your performance ideas, practice pair programming in order to benefit of all its advantages. Write the code in collaboration.

An open-space setup does not make you work as a team, especially if the members are sitting in corners with their backs to each other. Configure your work environment to face each other, this allows you to communicate with efficiency without making you roll your seat all over the open-space. You will also see when one of your teammate is struggling allowing you to offer your help.

Professional developers work with people whether they are from the business teams or their own team. They collaborate to answer the company’s needs and to produce great software.

When a surgeon is operating under pressure do you want him to stay calm and focused or to rush ? Professional developers are calm and decisive under pressure. They have best practices and principles to avoid making mistakes, they are made to be followed during pressure moments.

If you don’t like working under pressure, the first thing to do is to avoid the situations that cause it. As seen in the previous chapter (“Estimation”) do not force you into a stress situation by committing yourself to an unrealistic deadline you have to meet.

It is also important to “stay clean”, do not succumb to the temptation of the “quick & dirty” path. As it says it is dirty and you know you’ll have to deal with the consequences at some point. Furthermore it is not always that quick because the “quick & dirty” approach creates technical debt on your system and at some point your application is just a swamp and you are doing harm to your structure.

Stressful moments are not always avoidable, there are times when you will have to work under pressure. It these situations it is important not to panic, not to rush and stay focused. Rushing will in almost every case drive you deeper into the hole. Instead you should slow down and think of the problem you are facing in order to find the best path toward the solution.

Do not hesitate to communicate to your team that you are in trouble, look for input and guidance, avoid creating surprises for your teamates. You can practice pair programming to help you with your problem. Your partner will see the mistakes you are making, will have ideas you did not think of, will keep you from panicking and more. You are stronger when working as a team so do not hesitate to be the partner when someone else is struggling.

Relying on you disciplines is also important, you have them to give you guidance and they are the most useful during pressure moments. Do not abandon them at any cost, be even more dedicated toward them as usual. If you to TDD, write more tests. If you are a refactorer, do more refactoring. If you write small methods, make them even smaller. You practice these because you believe in them and you know it works, rely on your disciplines !

The best way to deal with pressure is to avoid it but when it is not possible you must remain calm and focused, communicate with others and trust your disciplines.

Developers have to estimate the amount of time required to complete their features. This is at the same time a simple and a frightening task because the business depends on them. There is no ultimate way to make correct estimation every time but it is possible to aim for a good evaluation.

But first, what is an estimate in the software development environment ?

In some cases it is a commitment, you must achieve it ! You have to be absolutely certain (100%) to commit yourself into a deadline. Other people will make plan based on your commitments so you definitely don’t want to miss them. Otherwise you will look as a dishonest person and you are doing harm (see Professionalism chapter).

In other cases an estimate is… an estimate ! It is a guess, you do not promise anything and you do not commit yourself. If you already had to quantify the time a development task will take you certainly know how difficult it is. Most of the time there are too many variables in play to make a proper estimation. And most of all an estimate is not a number, it is a probability distribution ! The concept is explains with the following figure (fig. 1).

Probability distribution example (fig. 1)

In this example the task has 50% chance to take 3 days but it can also take 4-5 days or even 10 days (the Murphy’s law is never far away). With a distribution the business has data to rely on for their work and the development team does not have an inconsistent deadline. It is also important not to commit yourself without willing to do, especially if you use the verb “try” (see chapter 2).

Program Evaluation and Review Technique (PERT) offers an effective way to convert estimates into probability distributions suitable for the business team and for the managers. When estimating a task 3 numbers must be provided, it is a trivariate analysis :

With these 3 values it’s possible to describe the probability distribution of the task with the following formula :

µ = (O + 4N + P) / 6

µ (mu) gives us the expected duration of the task. For the example this value is equal to 4 days. But this is just an average based on some coefficients and cannot be used as a deadline, it is a hint. Moreover the pessimistic estimate high value increase this average.

σ = (P – O) / 6

In this second formula, σ (sigma) represents the standard deviation of the task. It is a measure to specify how uncertain the task is, it is equal to 1.33 days with our sample data. The higher this value is the higher the risk is.

With the PERT technique the estimate for the task is the combination of the two values : 4 | 1.33. You cannot take one without the other.

Agile methodologies have given us several techniques to estimate tasks within a small development team. You can try a method called Wideband Delphi for example or the Planning poker approach or even the Affinity Estimating technique. All of them are based on agreement to provide meaningful estimates and you can combine them with PERT. To ease the process of estimating it is advisable to transform larger task into several atomic tasks, this way the team can be more accurate.

Professionals developers provide practical estimates, do not make promise they can’t keep and commitments that can’t be meet. An estimate is a probability and not a deadline !