DEV Community: Josep Mir

Build products taking advantage of uncertainty

Josep Mir — Thu, 03 Dec 2020 09:54:25 +0000

Uncertainty: Imperfect or incomplete information

What is uncertainty?

If we step away for a moment from software development and we try to define what uncertainty is, as a concept, we may come up with tons of definitions and synonyms, starting from the obvious, lack of certainty, but also we could go through terms like vagueness, unknown, unobservability, stochastic(random), undefined, unstable, variable, undetermined, unreliable, insecure, doubtful, ambiguous,… all of these terms are states that we cannot describe or outcomes that we cannot predict. Therefore, we can assume that the uncertainty for every situation is determined by two categories:

Descriptive complexity: the difficulty to make sharp and precise definitions. (current state)
Complexity by unknown: when selection between one or another option is unspecified. (future state)

When we come back to software development, we still have the same problem when dealing with software projects. We have to deal with uncertainties every day, and most probably, now even more due to all the corona situation. When we have to make decisions and assume risks, we don't like uncertainty, we like things crystal clear, but not always is possible. When uncertainty is around, it is more difficult to make the right decisions, and not just that, given our human condition, we also are bad guessers, so it makes it almost impossible to determine or predict correctly any situation possible. So, what would we do?

A bit of history

In order to have a bit more context and understand the problem better, let's go back to the early days of software development, back then what we did was simply forget the uncertainty. We created processes, methodologies, and tools that completely ignored that uncertainty was there. At the beginning of our young industry, the very first programs provided solutions to specific and small problems with all the requirements and expected outputs defined upfront. They could do that, in the end, they were just a small group of geniuses and other clever people, very methodical and disciplined. For a short while, we created software to solve specific and well-defined problems, but that didn't last much. The problem came later when the software industry grew and expanded literally everywhere and we had to make it work in one way or another. Now the problems were not so easy to model and they were becoming bigger and bigger. In addition, more and more people were entering the industry due to the huge demand, and not all could reach the same levels of excellence that we used to have in the past.

As the sector was growing, we needed a way to control and organize ourselves. So we brought the ways of working and organizing from other industries, such as top-down hierarchy from military or waterfall plan-execution from construction. After all, plan and execute seem like a reasonable thing to do, and in the same way, having the more clever or more experienced people managing and commanding average people makes total sense. We (as an industry) blindly went for this way of working, and after a while, we even adopted complex models like CMMI, so we could evaluate and improve our waterfall development process in our top-down organization.

But it wasn’t until after thousands of companies were broken, millions of projects failed and billions of money were wasted that the industry started to realize that maybe this way of working was not appropriate. Uncertainty is not something that you should ignore, it is something that you should embrace and build your product around it. This is what all these gurus in the Snowbird ski resort signed up for, a better way of building software. It was the agile manifesto that came out from this reunion. We want to build the right product and we want to do it assuming risks of hours or days, not talk about months or even years, that is too dangerous and difficult to make it right.

It turns out that whatever you are trying to build at your software-based company, it is the first time that it is being done in humankind history. This fact makes it impossible to foresee what is coming next for your business, it is normal to have uncertainty there. Nobody went as far as you did, and if somebody is doing something similar, either what you are doing doesn't have any economical interest or: congratulations, you just found your competitors!

Now is when the real talk starts. You have to openly accept the situation that you don't know everything and start working in a way that let us beat our competitors. You don’t need to stop avoiding uncertainty and start embracing it to take the best out of it. This is when Agile methodologies come into place. Agile is meant to develop software around this uncertainty. Organizations do not adopt agile just as a new and cool way of organizing work and managing people. It is way too expensive, we have all these new payrolls from agile coaches, scrum masters, product owners,.. all the time spent in meetings, or even all these new tools that we have to learn and pay to use. Organizations adopt agile to use it as a competitive advantage, if that is not clear for your organization, maybe you should reevaluate your investment.

Agile methodologies, like scrum or kanban, will let your organization build a product clearing the uncertainty that exists in your business. They will go iteration after iteration, collecting feedback and introducing it to improve the product, figuring out the needs of your clients/customers and how your product covers that need. Is this quick feedback loop that agile focuses on what gives your product this advantage in front of your competitors. As this is a competition, the first company that clears the uncertainty and is able to identify what customers really need and want to pay for is the one that will win the prize.

Experimentation Culture

The experimentation culture should be a thing in every agile team. It is by building the product that we continuously learn how to build our product, and also how not to build it. Experiments should take place during the whole project lifecycle. They could be more close or less to the scientific method, more formal or informal, longer or shorter (always timeboxed tho), with simple or complex goals,... But in order to discover which is the best solution, in order to clear the uncertainty, we have to investigate and try out the different options.

Usually, when talking about experimentation, the first thing that comes to mind is an evaluation with users of a new registration form or an A/B test of a certain UI component, but the reality is that it can be applied in any stage of the project lifecycle. Starting from the beginning, did you dedicate the proper effort when defining the navigation between screens? How many prototypes did you build before making the final decision? At team level, the dynamics, the communication, working agreements,... are the right ones? The format and outcomes of your meetings are correct? The tools we are using help us to do a better job? Did you choose the right language/ database/ framework for your problem? Or the only one you knew? Or maybe was the first you found on google? Did you find a better way to implement something but it was already too late to go back? How painful is having to live forever with bad decisions from the past? Take a minute or two, and think about the impact of these decisions you made. Would have been worthy to spend an extra day or even a whole extra week before making that decision? For most of them, you can still run an experiment and try to improve them.

Running experiments it's similar to investing. In order to win, you have to play in the first place, but also, you have to be ready to lose sometimes. Not all experiments end up with huge improvements, some even just confirm that there is no possible solution for that hypothesis you had. But even in those cases, it should never be considered as a failure or a waste. As mentioned before, part of learning how to do it implies that we also learn how not to do it. The experiments are the price you have to pay to obtain certainty in the project.

Uncertainty in code

We can have the right agile mindset in the team and the proper way of working perfectly agreed, but we still have to build and deliver the product, and we have to do it in the right way too. As developers, our duty is to build and deliver the software in a way that lets the business be agile. It is the business that needs to be agile in order to change and adapt to the requirements that appeared by exploring the uncertainty. We need to absorb this feedback in the product and we have to do it fast. This means that our software needs to be flexible, easy to change. Any piece of code should be easily modifiable in a matter of hours if not minutes, we can never talk “in weeks or months” when changing a behavior in our system.

Not tested code == Legacy code == Uncertain code

The only way to achieve speed and flexibility when building and delivering software products is by having a high-quality product, a software that is a cohesive and low coupled piece of code. We have to continuously pursue technical excellence, being disciplined, and taking the best use of the practices. The biggest problem of agile methodologies is that they focus on the process and organization and do not talk about technical disciplines or practices, they take it guaranteed. When we create a piece of code that is not covered (100%) by tests, we are introducing uncertainty in the system, we don't know how that part of the code behaves. If we don’t have a fully automated pipeline, we don’t know how long it will take to deploy. If we don’t estimate the user stories, it makes it impossible to come up with any realistic plan,... We do not do TDD, CI, plan games(like poker), or any other of the best practices and disciplines just for the sake of doing them, we do it because it is the way to achieve high-quality software that is easy to change and fastly deliverable.

If you want to keep reading about this topic, check out my article about the fake agile.

Wrapping up

Instead of running away from uncertainty, instead of avoiding continuously going into the uncomfortable zone, companies and more specifically, product teams have to deep dive in there. Exploring uncertainty creates certainty. Agile provides an excellent framework to explore the unknown, minimizing risks, going one step at a time and validating whether the previous step was right or not, so we can adjust direction for the next one. Is by clearing up all the uncertainty in short iterations (closing the feedback loop) that we can build the best product possible that satisfies the needs of our clients before our competitors. In order to achieve that from the business side, the technical side always needs to be ready to adapt, chase the technical excellence, to build software that is easy to change and fastly deliverable. Is the combination of both, business and technology, working side by side that leads products to success.

The scrum master role

Josep Mir — Fri, 04 Sep 2020 07:07:59 +0000

Scrum master: promoter of the theory, practices, rules, and values of scrum.

Scrum in a company

Companies didn’t want to use scrum, it was never the goal. Companies try to figure out how to build the right thing at the right time for their customers. They are after customer satisfaction but it turned out that predefining the release dates, trying to land on predetermined targets, defining previous big designs upfront,... it used to work, but now, simply it does not work anymore.

Successful companies are turning into empiricism, observing behaviours and outcomes, inspecting what is going on and making frequent adaptations. Scrum is the only framework out there that lets them do that, that is why they want to use it.

In scrum we learn by doing. We do not prepare super defined roadmaps for the next year(s) and force us to stick to them. We use the feedback we got from our last movement and use it to improve and maximize the result of the next one. Is by doing the work that we understand the work we need to do. Throw away the playbooks, do a little bit, gather feedback and figure out if what you are building is right.

Implementing scrum is a huge investment, it is very expensive to hire an agile coach, some scrum masters, prepare events, prepare the people,… we spent so much money doing this that it must be a competitive advantage for the organisation, otherwise it is a waste of time and money. Self-organising teams, cross-functional teams, empowered product owners, all these things get us to that competitive advantage, so the investment in the scrum adoption is worth it, only when done right of course...

Mastering scrum

Being proficient at implementing scrum is no easy task. If we compare it to chess, the rules of chess are quite simple and basic, you can learn them in just one afternoon, but becoming a great master, requires several years and in most cases a lifetime. Similarly, you can read the 17 pages of the scrum guide in one sit, if you have not done it, do it now, I’ll wait.

Once you read it, you can start right after, prepare the first events and artifacts for your team, distribute the roles, but the very first moment you start to apply scrum, impediments happen. Friction appears everywhere because the organisation is not used to work in that way, it is something very disruptive. It takes a long time to learn how to leverage agility and empiricism in a way that it is useful for individuals, teams and the company itself.

You may need a while to unravel organisational dysfunction, it takes a long while to change the mindsets from command and control to servant leadership, basically, it takes years to master how to change the DNA of a company. The challenge is everywhere else but the scrum framework itself.

The scrum master role

The scrum master is the enabler of the team to succeed, remove impediments and serve the team. Any scrum master should look after these three statements:

Devotion to the team. Deep care of the team, want them to be as successful as possible.
Level up people. Help to get promote and elevate each one of them, even in their careers.
Remove organizational impediments. Zero tolerance for anything that is holding the team back.

The person that holds the role of scrum master should impact the scrum team, help the team to deliver, empower each one of the team members and remove any organizational issues. This person should never fulfill the PO’s role nor tell the developers what to do. Also do not neglect the organisation problems avoiding difficult conversations with leadership or HR. With the COVID-19 situation and all the remote working, these organizational problems only get amplified, but now the impact is 10x.

The scrum master is the bridge between the team and everybody else, a bridge that is constantly shrinking until it completely disappears. The duty here is to connect people, not being a proxy, put the stakeholders and the dev team together, not place themselves in the middle.

A scrum master does not keep the backlog up to date, a scrum master does not baby sit the dev team. In scrum, the teams have to keep their progress visible and transparent so we can keep them out of the status meetings with managers, that is the deal.

Always fulfill the three levels of service: P.O., Dev team and organisation, in a way that empowers others, not commanding and controlling. Do not take the power and influence of the role to command and control other people.

The scrum master only makes sure that the scrum events happen and is only facilitating when needed. They are not the center of attention, it is not about them, it is about everybody else in the meeting. For instance, daily meetings? Totally optional, the scrum master just has to make sure that it takes place and they should only facilitate when the team still does not know how to do it.

Make everybody understand the scrum values

It is very easy to turn scrum into a process, in order to avoid making people understand that this is a framework, a human practice, and leadership should go first. People will crush any scrum implementation if the values are not followed. We need:

Focus: to tackle fewer things at once, but getting things done.
Courage: to speak to the power, to managers and leaders. to say a stakeholder “no” or to a customer “not yet”.
Openness: to new ideas, to be wrong, to diversity, to inclusion,...
Commitment: to give the 100% of ourselves, but never to a scope, big misunderstanding here.
Respect: all things above must be done in a respectful way, otherwise everything tears apart.

Teach the culture because this is what is really important.

Prepare the development team

The dev team is a self-organized and cross functional group of people that is capable of delivering a product. The team can build and ship an increment of the software on their own without depending on any other team to do anything for them. We implement scrum in an organisation to use it as a competitive advantage, part of that competitive advantage is time to market, being able to generate a new idea and place it into the world in hours, if not minutes, is game changing. If we have to wait for decisions, if we have to wait for permissions, wait for all these proxies,... we lose time and money. We are giving up this competitive advantage by organising us in bad ways. When setting a new scrum team, we expect a good return on that investment.

Engineering managers should clear impediments, take care of HR duties, but it is not their task to tell the team how to do their work anymore. In scrum, we empower the dev team to figure out how best to do their work, we trust the team to decide how to do their work, the team is accountable to get the job done, accountable to deliver and they have to decide how to get there passing all the constraints along the way.

From a scrum perspective, if you have an engineer manager, people manager, lead architect,... is up to the organisation, but the team is fully empowered in any case to decide how to do their job. If they find obstacles, they can go to their manager to help them or to clear the way, but in any case the manager/lead role is only to help the teams, not command and control them.

Scrum does not recognize titles between dev team members, in a self organized team, a tech lead fades away. There is not one voice louder than another, we want a highly collaborative environment, respect, rely on others and help each other,... A scrum master should detect this and correct it: Go to HR and make them understand that by creating hierarchies inside the teams, they are killing the team self organization, they are causing issues to the team culture. For sure they can compensate these more experienced people in different ways.

Truly cross functional self organizing teams with strong ownership, always will find ways to sort things out.

Teach the product owner

A scrum master has to make the product owner understand they have to maximize the value of the dev team, that they have to protect the investment made by the organisation and look after the 3 Vs:

Vision: The impact of our project in the world with our effort.
Value: Define what value actually means,
Validation: Accountable to check if what we deliver reached the value expected.

Usually product owners are very busy persons, they have to talk to customers, perform a/b tests, perform market research, have constant meetings with leadership and managers,… They are here to make sure that what we are building is actually what people need and want. They have to define how winning looks like.

In the scrum guide it says: “The Product Owner is one person, not a committee”. We want just one voice for one product, a person that is able to make decisions tactically, strategically and even financially without waiting for permission. When we have a proxy product owner, it only leads to waste of time, waste of work, and if the needs are not communicated properly to the head product owner, this person is not going to make the appropriate decision. Many problems will come up. This doesn’t mean that the P.O. cannot get any help, a person inside the dev team could be accountable for the value of a piece of product in front of the rest of the team.

The cohesion is going well in the team when a PO can defer a question from a stakeholder to anybody else in the dev team. It is a really good sign that the relationship is working. The PO trusts the dev team, and the dev team show that they truly understand what they are doing. Just a little thing, but very significative.

Protect the backlog

POs express the value and vision in the backlog, holding all the things we could do to match the product vision, sorted by value of what we could do. In english, by definition, priority is singular. Having more than one priority invalidates the first one. In a scrum team we only have one priority and this is the sprint goal. The backlog is not sorted by priority, the backlog is sorted by amount of value, notice the big difference. In the daily we inspect our progress towards the sprint goal, and if necessary we perform some adaptations with the things we learnt along the way. We are in a complex domain, and we are learning about it constantly.

Prevent backlog from growing too big, set a limit time to live for a story, something like 3, 4 or 6 months, depending on your project, and delete everything that goes beyond that. If a story never got enough value during this time, most probably is never going to come, and if it does, the context would have completely changed, so you’d need to rewrite the whole thing again. Don’t worry about deleting stories, if it was important, it will come back from the feedback of your customers.

Beware of changing scrum

Be careful and be sure that you adapt the company to scrum and not scrum to the company. When scrum has to change, it is because some organisational dysfunction, rather than changing scrum, change the way your company works. Leave the framework alone! There is a lot of space to be creative outside the boundaries of scrum, between the events, artifacts and roles, but do not change the framework itself.

Measuring success in scrum

We know whether we adopted scrum successfully when we can answer affirmatively to the question “Do we deliver high quality products that delight your customers?” That is the only measure that it counts. Do not focus on the figures of the scrum master or the agile coach, if your company cannot ship an increment of the product at the end of the sprint, it is a clear sign of failure.

The scrum master is an advocate of the scrum process, values and principles. Clearing the way far beyond the process: remove organizational obstacles, create a cozy work environment, ensure communication with and within the team, promote collaboration,... a servant-leader to the team, to protect it and to push it forward. A scrum master can only succeed if the whole team succeeds. The name master is not given by chance, we consider this person an expert of scrum, and as an expert, we expect from that person to help and coach any member of the team in need.

User stoy lifecycle

Josep Mir — Wed, 27 May 2020 12:59:15 +0000

User story: Informal description of a feature of a software system

In agile, a user story is a functional increment of the software, agreed with the customer or with the product owner. Each user story must contribute adding value to the product. When writing a user story we must specify for who is made, what is done, and why it is done, explaining the business value added. Defining good user stories affects directly to every stage of the story lifecycle that we are going to visit after.

There is an assessment you can perform to your user stories to evaluate how good they are, it is called INVEST:

Independent
Negotiable
Valuable
Estimable
Small
Testable

After having defined good user stories, let's see how we can improve the whole story life cycle in order to improve the velocity of our development team. The next schema, it is a generalistic schema, the story life cycle may be slightly different from one company to another and have much more steps maybe, but the core concept will be very similar:

Idea: Everybody should be able to contribute here. As a software business, we need disruptive, inventive and creative ideas. We should not only restrict that crucial part only to certain roles or members of our team. An idea should be able to come from any mind, for instance, a developer could provide a competitive differentiation taking advantage of the technology, or a sales person could identify and tackle new requirements based on the contacts with the clients. The product needs the contribution of every member of the team.

Issue: We don’t want these ideas to get lost, so we write them all down here. In all stories identify, for who, the what and the why is important so we don’t forget why we wrote that after some time. Afterwards, it’s the PO’s duty to arrange the prioritization of these stories, or even remove them when they are not needed.

Plan: This phase does not only refer to deciding when we implement the story, it also refers to deciding what we build. Here is when this negotiation between the business and development takes place. Developers should make sure they deliver exactly what is needed and nothing more than that--don’t develop things that weren’t asked--.

Code: It is the core of everything, here it is when we build what is needed. Even though I call this stage as code, I mean a bit more than just the word code. Design goes here, documenting these design decisions goes here, writing tests also, if they are written before the code, even better(TDD). Refactoring when possible, before and after writing the code... This is the phase when developers apply all their technical knowledge.

Commit: Commit is here to remember you to use a code source control. Luckily, it is not that necessary to remember that in 2020, but just in case. Commit often and commit while you are writing the code, do not wait until the end and do 1 big commit with everything.

CI: Continuous Integration it is a powerful tool that gives feedback to the developer about the code they just wrote. The code of each developer is automatically evaluated here together with the whole system in a production like environment, so we can make sure that the changes introduced won’t break anything unexpectedly.

Review: This is the phase when developers give feedback to each other about the code produced. It is also a way of spreading the knowledge between the team on the job done. Pair programming could help to reduce the amount of rework required in code reviews, because the feedback is immediately given while writing the code, we don’t need to wait until we finish the whole task to get feedback about it.

Merge: In this point, the enfasis goes to the branching control (git flow). It will determine the next phase. We have to take advantage of a tool like git. (avoid svn, mercurial,...)

CD: The continuous delivery / deployment, it is the ability to put every user story into production in just a few minutes. The difference between continuous delivery and continuous deployment is a business decision, the business decides which stories go straight to production and which ones don’t, but all the stories should be able to go into production on their own.

Production: Notice, I went straight into production. There may be other environments for testing purposes or other teams, but I keep them out of this process. For the vast majority of failures in most of the companies, it is cheaper to recover from failures than trying to prevent them. Meaning that, if we have a reliable test base, it is more efficient to accept that we may introduce a minor bug into production, than have an entire team manually testing (preventing) a bug to go into production, because even then, you cannot guarantee that you won't sneak any failures anyway. Again, in most of the business, not all.

Monitor / Evaluate: Monitor everything we do is crucial to understand what is going on in our systems in order to make improvements later. Here is when we can evaluate the story delivered.

Feedback: We have to check what we did, to make sure that it fits the needs of the clients. Otherwise, why did we build that at all? Why have we built that in this specific way and not a different one? If we don’t gather feedback after each iteration we are failing at the most elemental concept of agile. We also have to reduce the fear to experimenting and try new and creative ideas, if they don’t work, nothing happens. But these are the things that may make the difference for our business.

The speed we gain completing the circle(lead time) is the speed we can provide to the business. This speed is not only in terms of moving forward, it also means speed to change the product fast. Business should be able to steer in order to find the perfect market fit, and we, as developers, have to provide them this ability to adapt quickly, in other words, we as developers have to be agile to let the business be agile.

The Software Quality Cost Myth

Josep Mir — Tue, 05 May 2020 11:02:28 +0000

Software Quality: Not only working software, but also well-crafted software

A short story

Just like every other myth, there is a scary story behind it. The story in this case is this software project that a certain company started. After months of thinking and planning, the directors of the project finally got the budget to kick off. They started hiring people to begin with this business idea that will make them millionaires.

At the beginning, there were only a few people there, and like every beginning, this was a sweet phase. Everybody was happy and extremely motivated. All the members of the team were on the same page, the developers started to deliver the first features and the managers could start showing everybody the first steps of their little baby.

But as the time passed by, and more people were added to the project, the communication between all the team members decreased a bit. The old people are still the same, but the new people… you know, it is not the same feeling. They don’t fully understand the product, don’t understand the code, and they don’t understand certain decisions we made in the past. But there is no need to worry about it, let’s give them some time, they will be aligned soon.

Soon after, the productivity of the team started to slow down, now everybody in the company noticed it. Maybe it was because of the new people or maybe because of other reasons, but the business could not meet the goals set for this quarter. The development team didn’t identify any major problem, so let’s give them a bit more time, and for the next quarter and let’s add more resources there.

Next quarter was even worse, we doubled the resources in the development team, and the productivity dropped to minimums. The development team is delivering nearly nothing at the moment, and the few things they deliver are full of bugs that need endless extra hours to be fixed. They just complain about the codebase, apparently it is a complete disaster now. People are not happy anymore, they have endless discussions about silly things and sometimes they even have heavy arguments. But this is not all, the cherry of the cake is that the two most experienced developers, the ones that knew more about the product, just left the company. And being honest, I think other people are looking for other options outside the company too.

We don’t know what happened, we didn’t do anything wrong. We were doing all good and we were all happy but all the sudden everything was a mess. We still have a business to run, but the software is not there. The developers are unable to deliver anything on time, plus we are all sweating bullets every time we release anything to production because it has lots of bugs. Our customers are complaining a lot because of that and many of them are already considering other options. We lost completely the innovative DNA that helped us to found this company, we are just average now.

If you have been working in the software industry for a while, most probably you have seen or heard a story similar. Maybe not that dramatic ending, but the rest sounds familiar.

What went wrong in the case company or in other similar companies? Why one day they wake up and discover the scary truth that everything was a mess? Well, there are several factors, many. Starting because every company was different, with different context, and the problem described affected at different degrees... But they all share the common cause: low quality software.

In this business case, just like every similar case, the development team was focused on delivering business features, adding business value but they completely forgot all the technical practices. Little by little they were adding technical debt to the project in order to deliver features on time, and just like quicksands, the more they developed, the more they were slowing down. In these cases, adding more people to the project is even worse, because there is more people adding cr*p things to the pile, making the mud snow ball bigger faster.

Don’t think this only happens in old fashioned waterfall projects, this happens also, and even more frequently I’d say, in agile projects. In waterfall projects, may be erroneous, but at least you have everything designed at the beginning of the project. In agile often we confuse no big design upfront with not thinking at all. In the case above, maybe they were using some agile implementation like kanban or scrum, probably they were even doing daily standups, sprint plans, reviews and retros, as they should, but the technical disciplines just weren’t there. Agile doesn’t solve problems, agile exposes problems so you can react to them.

Some symptoms of low quality software, to name a few, are:

No tests or not enough tests
No reliable tests
No automatic tests
No documentation (class diagrams, architectural diagrams, sequence diagrams,...)
Software complex to install, compile or run
Takes ages to be deployed (and it's all manual)
Has bugs or known issues
Code hard to understand
Expensive to maintain or extend
Software fragile, not stable or not available
…

If you identify any of these symptoms on your project, start to worry but don’t panic yet. Prepare a contingency and recovery plan asap. The later you fix these problems, the more expensive is going to be. In a software project, the pace of the business is set by the developers not by the business, the business can only go as fast as the developers go. The software quality matters and it is something everybody in the project should care or enable.

What is Quality in software?

Well, just as any other product, we have on one side functional quality, which is what we expect from a working product, and on the other side, the structural quality, which is how the product is built. The difference with other industries is that in software you can have the first without the second.

A basketball ball should be spheric and have a certain size, orange and with some black stripes, but if it breaks after bouncing it 15 or 20 times, we can say the quality is very low. The same happens with software, we can have an application that does something as expected, but internally is rot. As long as we never have to change it, there is no problem, but in the moment we have to change anything, then all kinds of problems arise. But being honest, how many projects do you know that developers don’t ever touch the code?

The software quality myth

Quality is always perceived as something expensive, we often say that it is impossible to have speed and good quality at the same time. But in software it’s not the case, it’s something counter-intuitive, because the only thing that can guarantee in your project the speed and flexibility is this high quality in software. Let’s see this in some plots:

When starting a project having low quality, immediately we can deliver business value. At the beginning, there aren’t many problems, as we have only few developers and the code is still small and the functionalities reduced.

But after a while, as the codebase grows and especially, when we add more people to the project, the velocity starts to slow down. The code is not easy to understand, there are different coding styles. Only the authors of each piece of code can work effectively with each part but not the rest because they don’t understand. Gradually and as the time passes by, the team is becoming slower and slower.

But what happens with high quality software? At the beginning, there is not much value delivered because all the technical concerns are set properly. We focus purely on the technical aspects here, business value is a secondary priority at this moment. Thinking how we are going to build the software and also how we are going to deliver it.

The complexity in the design is higher but it compensates with the simplicity in the code. It takes a while until it starts to pay off, but as you see in the image, the velocity by then is increasing much faster than it never did. How step this line will be determined on how good is our design and architecture. As it can be seen in the image, at some point, there is an intersection where low and high quality cross. Don’t think when this happens is measured in the scale of years or months, we are talking about 4 to 8 weeks most probably for this to happen in most of the cases.

If we extend the timeline a bit more, we see that the low quality project is not only not improving, it is steadily decreasing. On the other side, high quality software is able to not just keep the increment of velocity of value delivered, it has even increased. One reason is because if we have a good design, we can start reusing pieces of code after a while. The second is that we can add more people to the project and they are more productive as they understand the code. It means increasing the team, proportionally increases the velocity. When the quality is low, new joiners have to ask questions for several months, slowing down, not just them but the other person that helps them.

Good quality practices.

There are tons of literature written about best practices when writing code, but if you don’t know where to start, I would recommend you taking a look to the extreme programming (XP) practices:

Extreme programming is a set of well proved practices introduced by Kent Beck back in 1996. It is probably the most used framework in combination with some agile processes like scrum or kanban. It focuses on raising the internal quality of the software product and delivering value continuously to the business in short iterations. Give it a try.

Summing up, quality in software is extremely important and sadly, it is something usually overlooked or directly forgotten. Counter-intuitively, high quality in software is the key to have fast deliverable and flexible software products. Good practices, just like every other practice, requires some time of learning. It is like learning how to ride a bicycle or a car, or even a musical instrument. It requires some dedication and discipline to become competent at it. The good part is once you get it, you have it forever. You can bring that knowledge from one project to another, just as you would do when changing the bicycle, the car, the guitar or the piano.

Build effective software product teams

Josep Mir — Mon, 20 Apr 2020 07:50:59 +0000

Team: NOT just a group of people working together.

The software industry has changed a lot in the last years, well… actually, it changed a lot since it started, and it may change a little more until it reaches a proper level of maturity. We (as industry) have problems understanding these fast paced changes, so it becomes a real challenge to react properly to it.

The most important thing about software development is the communication between humans, between the members of a team primarily and secondly with customers. The later we cannot control how it is done and organized, but the internal team we do. Even coding is a way of communicating first with other developers and secondly with a computer. We have to take care of the language used in the code too, but this is a story for another time.

Having a good team, performing well is crucial to have a good performant business. It is the only way to effectively achieve business goals. In this fast paced industry in which we are, we need the contribution of each one of the team members. It doesn’t work having one or two minds managing all the people and commanding what to do.

When talking about software product teams, the old fashioned industrial era management style does not work anymore. Managers should manage the product, not the people. Here are some properties of poorly managed teams:

Centralized and military top-down structures
Planning and coordination done only by management
Strict work policies
One skill job positions
Department boundaries defined by functionality
Rewards based on individual performance
Employees viewed as tools
Employees accept the factory workers role

Good performance teams need motivated and empowered people, working in a cohesive way. We want people that understand what to do and act proactively, and the only way to do it is having everybody on the same page. Here we have properties of good performing teams:

1 - Small teams
If we work in small groups, it is easier to share the objectives, make sure that everybody understands them and we all are going for the same goals. In a team, the most important thing is the communication, but have you considered how many connections do you need depending on the size of a team?

Team members	# Communication links
2	1
3	3
4	6
5	10
6	15
7	21
8	28
9	36
10	45
11	55
12	66
15	105
20	190
25	300
30	435

It is a real challenge to keep all these communications alive. Everybody heard about the two pizza team sizes of amazon, that you should be able to feed your team with two pizzas (american pizzas I guess they are talking here :P). But the thing is, we are talking around 12 people maximum here. The second part, often omitted, is that everybody in the team should have a pass through to their customers. Which leads to our second point:

2 - Business oriented
The development people should communicate often with the business people to understand the needs of the business, so they can deliver software that properly meets the business requirements. When this communication is lost, it leads to loss of the coherence between the business function and the code produced.
If the communication flows, development and business interact with each other, and developers can make sure that they are delivering what the business needs. They should ask many questions, negotiate the tasks, propose different possible solutions and pick the best, … act like professionals, not factory workers just accepting orders. If this never happens, the business is never going to be able to take advantage of the technological capabilities.

3 - Technology led
Everybody in the team should understand the technology they are producing. After all, we are talking about a software product, so everybody should know about it. I am not saying that all the members should know how to code, but understand it properly to fully comprehend the value of the technology behind the business value. And also very important, value the work of their tech colleagues. I personally have seen (two) companies go bankrupt because product managers or sales people didn’t understand what they were doing or selling, and in both cases directors and developers were completely aligned.
In the same way, we have to bring an atmosphere of continuous learning to the team. Being engaged with different technology communities is also something to take into account.

4 - Autonomous
Every individual should be able to work in an autonomous way. Mostly, this is already happening in some business or sales units for instance, but it is not that common to happen within the development team. Some companies still have one trick pony developers, that require from the job of other developers to accomplish their own job. We don’t want developers that only work in UI or just databases, we want developers that can bring business features all the way from databases, backend or frontend into production. They should be able to deliver useful software to the business and this requires having the ownership of everything from development to production.

Extra: Trust
Trust is the glue that ties all the previous points together. Within a team, members should not be afraid to ask for help when needed. They all should be keen to share knowledge of any kind. They should not blame other team members. Peers have integrity in their responses, when asked “what do you think?” there are no hidden feelings going on…
Trust is often overlooked by many companies, but is crucial to make teams work. In a team we need to provide a healthy psychological safety where members can work freely to create these inventive ideas. Last, but not least, getting rid of toxic people is way more beneficial than trying to get the right people, or the best people, whatever it means being the best. A single toxic team member can lead to the destruction of any kind of cooperation.

Just like any sport played in teams, every member has a different role(s) and has different responsibilities(s), but in order to win, they have to work together, in a cooperative way, have cohesion, be aware of the movements of each team member and act of a single unit. This is the spirit, values and attitude you need for any team. We win or we lose together, as a team. The word team goes far beyond just a group of people working together.

The agile principles

Josep Mir — Fri, 17 Apr 2020 07:59:08 +0000

Agile: able to move quickly and easily.

Almost 20 years ago, in 2001, few software developers got together in a ski resort in the mountains of Utah to discuss software development methods. The 17 people there were: Kent Beck, Ward Cunningham, Dave Thomas, Jeff Sutherland, Ken Schwaber, Jim Highsmith, Alistair Cockburn, Robert C. Martin, Mike Beedle, Arie van Bennekum, Martin Fowler, James Grenning, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, and Steve Mellor.

As an action to turn away from the documented driven, regulated, planned and micromanaged methodologies to develop software widely used, all these ~~celebrities~~ developers were related somehow to different lightweight methodologies to develop software such as rapid application development RAD (1991), unified process UP (1994), dynamic systems development method DSDM (1994), Scrum (1995), crystal clear and extreme programming XP (1996) and feature driven development (1997).

The outcome of the two day meeting was the signature of the well known agile manifesto:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

This is a great manifesto. It is short, easy to remember and it expresses precisely which is our position while developing software. It is a revolutionary declaration to whoever opposes us or works in a different way.

But if you don’t want to just declare yourself as an agilist, and want to gain adopters instead of enemies(skepticals), I usually refer to the agile principles behind the manifesto. They express much better what we want to achieve and the value that we will add. It is a list of twelve principles:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity--the art of maximizing the amount of work not done--is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Next time you want to discuss with somebody about agile, refer them to the agile principles instead of just the manifesto, and explain the motivations and the values behind each principle of this list. It is a much more convincing and understandable way to comprehend the agile benefits. After all, software development is all about communication and interaction between humans, we need to be aligned in the way we work.

TOP 20 VS Code shortcuts: Windows Edition

Josep Mir — Wed, 18 Mar 2020 08:51:57 +0000

Here is the guide for mac and linux

Just as many of you, I have been working with Visual Studio Code for a long while now in projects using languages like Python, Javascript, Typescript,... With no doubts it is a great tool, but I have the feeling that I am not as productive as when I am working with Java using IntelliJ IDEA. Why is that?

The biggest difference is that I learnt most of the shortcuts that I need in intellij, so I barely use the mouse when programming, and that for me makes a huge difference. In intelliJ there is a great plugin called Key Promoter X that tells you the shortcuts for every action you do that could have been done with a shortcut, it is super easy to learn and remember the most used shortcuts. I couldn’t find any plugin like this for VS Code, if it exists, please, please, PLEASE, let me know in the comments!

As I know it is hard to go and check from time to time the cheat sheet of VS Code shortcuts, here is a compilation of the most used (by me) shortcuts that you(I) should remember first:

Here is the list of TOP 25 shortcuts, with images:
1- Command Paletter: Ctrl+Shift+P

2- Quick file open: Ctrl+P

3- Errors and warnings: Ctrl+Shift+M
navigate trhough errors with F8 or Shift+F8

4- Toggle Terminal: Ctrl+backtick

5- Toggle Sidebar: Ctrl+B

6- Zen mode: Ctrl+K Z
Exit with Esc Esc

7- Open new tab: Ctrl+\

8- Switch tabs: Ctrl+1, Ctrl+2, Ctrl+3

9- Multicursor selection: Alt+Click or Ctrl+Alt+Up / Ctrl+Alt+Down

10- Next occurence selection: Ctrl+D

11- Select current line: Ctrl+L

12- Expand / shrink selection: Shift+Alt+Left or Shift+Alt+Right

13- Copy line up / down: Shift+Alt+Up or Shift+Alt+Down

14- Move line up and down: Alt+Up or Alt+Down

15- Code format: Shift+Alt+F

16- Go to definition: F12 or Ctrl+click

17- Go to references: Shift+F12

18- Peek definition: Alt+F12

19- Navigation history: Ctrl+Tab
Navigate back and forward Alt+Left and Alt+Right

20- Rename: F2

Extra: Configrue autosave
open settings Ctrl+, and search for autosave

Just as knowing the language and the paradigm you are working is a must, knowing the tools you are using in order to work effectively is also a important. It makes a difference.

TOP 20 VS Code shortcuts: Linux Edition

Josep Mir — Wed, 18 Mar 2020 08:51:53 +0000

Here is the guide for mac and windows

As I know it is hard to go and check from time to time the cheat sheet of VS Code shortcuts, here is a compilation of the most used (by me) shortcuts that you(I) should remember first:

Here is the list of TOP 25 shortcuts, with images:
1- Command Paletter: Ctrl+Shift+P

2- Quick file open: Ctrl+P

3- Errors and warnings: Ctrl+Shift+M
navigate trhough errors with F8 or Shift+F8

4- Toggle Terminal: Ctrl+backtick

5- Toggle Sidebar: Ctrl+B

6- Zen mode: Ctrl+K Z
Exit with Esc Esc

7- Open new tab: Ctrl+\

8- Switch tabs: Ctrl+1, Ctrl+2, Ctrl+3

9- Multicursor selection: Alt+Click or Ctrl+Alt+Up / Ctrl+Alt+Down

10- Next occurence selection: Ctrl+D

11- Select current line: Ctrl+L

12- Expand / shrink selection: Shift+Alt+Left or Shift+Alt+Right

13- Copy line up / down: Ctrl+Shift+Alt+Up or Ctrl+Shift+Alt+Down

14- Move line up and down: Alt+Up or Alt+Down

15- Code format: Ctrl+Shift+I

16- Go to definition: F12 or Ctrl+click

17- Go to references: Shift+F12

18- Peek definition: Ctrl+Shift+F10

19- Navigation history: Ctrl+Tab
Navigate back and forward Ctrl+Alt+- and Ctrl+Shift+-

20- Rename: F2

Extra: Configrue autosave
open settings Ctrl+, and search for autosave

Just as knowing the language and the paradigm you are working is a must, knowing the tools you are using in order to work effectively is also a important. It makes a difference.

TOP 20 VS Code shortcuts: Mac Edition

Josep Mir — Wed, 18 Mar 2020 08:51:49 +0000

Here is the guide for windows and linux

As I know it is hard to go and check from time to time the cheat sheet of VS Code shortcuts, here is a compilation of the most used (by me) shortcuts that you(I) should remember first:

Here is the list of TOP 25 shortcuts, with images:
1- Command Paletter: ⇧⌘P

2- Quick file open: ⌘P

3- Errors and warnings: ⇧⌘M
navigate trhough errors with F8 or ⇧F8

4- Toggle Terminal: ⌃+backtick

5- Toggle Sidebar: ⌘B

6- Zen mode: ⌘K Z
Exit with Esc Esc

7- Open new tab: ⌘\

8- Switch tabs: ⌘1, ⌘2, ⌘3

9- Multicursor selection: Option+Click or ⌥⌘↑ / ⌥⌘↓

10- Next occurence selection: ⌘D

11- Select current line: ⌘L

12- Expand / shrink selection: ⌃⇧⌘← or ⌃⇧⌘→

13- Copy line up / down: ⇧⌥↑ or ⇧⌥↓

14- Move line up and down: ⌥↑ or ⌥↓

15- Code format: ⇧⌥F

16- Go to definition: F12 or Cmd+click

17- Go to references: ⇧F12

18- Peek definition: ⌥F12

19- Navigation history: ⌃Tab
Navigate back and forward ⌃- and ⌃⇧-

20- Rename: F2

Extra: Configrue autosave
open settings ⌘, and search for autosave

Just as knowing the language and the paradigm you are working is a must, knowing the tools you are using in order to work effectively is also a important. It makes a difference.

A quick intro to code smells

Josep Mir — Mon, 16 Mar 2020 09:52:48 +0000

Code Smell: An indicator of a design principle violation

What are code smells?
The term was popularized by Kent Beck in the late 90s and its usage increased after appearing in the well known Martin Fowler’s book Refactoring. Code smells are indicators that something may be wrong in a piece of code. They are not a problem just because they are a smell, a deeper analysis is needed to determine if there is a problem or not.

In order to clarify, let’s see what code smells are not?

They are not bugs
They are not technically incorrect
They do not block a working program

Okay, this isn’t scary, but then why should I be worried at all? Well, let’s see what code smell actually are:

Indicators of weaknesses in design
Indicators of slow development
Indicators of high risk of introducing new bugs and errors

Memorizing the list of code smells and understanding the complex idea behind each one of them, helps to reduce the conflicts within the development team regarding code discussions. There is no place anymore for arguments like: “I don’t like your code, but I can’t tell you why...”. They don’t miscommunicate or talk using ambiguous terms. When a person mentions the name of a smell, all the rest know exactly what it means and understand immediately the point of the discussion.

Let’s move to what we all came for, here is the list of code smells. They appear divided in 5 categories:

Bloaters: Things that grew too big

Long Method: Too many lines of code in just one method.
Large Class: Always putting in but never taking things out.
Primitive Obsession: The objects passing around are too dumb. As everybody understands primitives, everyone can do its own interpretation.
Long Parameter List: Use several parameters instead of an object with all the required data.
Data Clumps: Pieces of data that always appear together and probably should become an object.

Abusers: Tools from OO that were misused

Alternative Classes with Different Interfaces: Two classes that look different but perform the exact same operations.
Refused Bequest: A class and a super class share a tiny part of logic, but the inheritance as a whole does not make sense at all.
Switch Statements: Switch statements (or sequenced if statements) are a signal that polymorphism could be used instead.
Temporary Field: An attribute that is only used as a part of a process or algorithm and never again.

Change Preventers: Things that makes changes hard and expensive

Divergent Change: When the logic in a single place is so twisted that you have to change unrelated things to perform your changes. Opposite to shotgun surgery.
Shotgun Surgery: When the logic is wide distributed and a modification requires small changes in many different places.
Parallel Inheritance Hierarchies: Two mirrored hierarchies that need to change always at the same time.

Dispensables: Elements that could been avoided

Comments: If comments are needed, something is not good. A good naming for the method and its parameters should be enough.
Duplicate Code: Two fragments of code that are identical.
Data Class: A class that is only a container of data with getters and setters and all the logic is placed in other classes.
Dead Code: Anything that is no longer used in the code.
Lazy Class: A class that does not get enough attention in a while, maybe has lost their right of being a class on its own.
Speculative Generality: Anything that is built “for the future” or “just in case”, in very rare cases we will be right doing predictions of the future.

Couplers: Stuff that binds the objects together, therefore they cannot be used in any other context.

Feature Envy: A method of a class that accesses the data of another object more than their own data.
Inappropriate Intimacy: A class that uses private fields or methods of another class.
Incomplete Library Class: When a library does not meet all the requirements anymore. Then the use of that library becomes painful. Fix it or throw it.
Message Chains: A client requests something to an object, and this requests something to another object, and so on. If the type changes, everybody needs to adapt.
Middle Man: When the only job of a class is delegate work or forward messages to other classes. Couldn’t it be avoided?

If you want to dig deeper in code smells, I leave here a link with much better explanations and code examples.

A code with smells is only a problem when you have to interact with it, but until that very moment, it is working software and it is not costing any money as long as it does not change. Think twice before refactoring something, most probably there is no need to clean all the smells of your code base, and certainly not all at once. Legacy code is perfectly valid and working software, beware if you decide to go into the mud.

The software design principles you should remember.

Josep Mir — Thu, 13 Feb 2020 08:27:29 +0000

acronym: is a word formed from the initial components of a longer name or phrase

During my time as a software engineer, I have heard so many acronyms that I could not even try to guess the number in thousands. Acronyms are a bit overused in our field. There are acronyms everywhere, in every area, in some cases they help to shrink names, but in some others they are used just made up to make cool names.

Personally, I like acronyms as a tool to encapsulate much deeper knowledge in just a simple word. As a kid/teen I used to use them quite a lot to remember lists of stuff for my exams, but now as an adult and as a software engineer, more specifically, I can still use some acronyms related to software design on a daily basis. These acronyms are not to remember lists, these acronyms are to remember design principles.

KISS: Keep it simple, stupid
There is not much to add to clarify the intention of this principle. Avoid unnecessary complexity on your solutions, try to keep them Simple, Short, Small, Straightforward,... When software is simple, it makes it easy to understand, easy to maintain and easy to extend.
DRY: Don’t repeat yourself
This principle is easy to understand, but not so easy to spot in a real life project. It goes a bit further than some copy-pasted chunk of code. The theory says: “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system” and what it means is that sometimes, especially in large projects, you have split logic into two or more places, because it looked completely different, but after a while it turned out that they have some logic shared between them. In order to avoid synchronous changes in all these places, put together this shared logic in a single place.
YAGNI: You ain’t gonna need it
The software principle behind this acronym tries to avoid all functionality in the system that is not needed or used yet. Do not bring anything that you foresee that you will need but it is not required/used now, because in the future when you need that, you will have more context and the software may have changed, so then, you can come up with a much better solution. This is commonly used when pairing doing TDD because you or your partner don’t stick to “do the simplest thing that could possibly work” or DTSTTCPW. Don’t waste resources nor compromise the possible final solution at this point.
TDA: Tell don’t ask
Again, easy to remember, but not so easy to identify in real life projects. This happens when you have split the logic and the data needed for that logic. The module/class/component that has the logic needs to ask for the data in order to perform the action, this generates an extra communication between elements that could be avoided. Wouldn’t it be more convenient, and if it is your case, more object-oriented if the logic was tied together with the data? An example, imagine you want to calculate the bonus of an employee, you need to ask for that employee’s name, the position, its current salary, days worked, project performance,... whatever, and then when you have all the data do the calculations, right? Wouldn’t it make more sense that the employee had (directly or indirectly) the bonus calculation logic and simply use the payBonus function instead of all the getters?
LOD*: Law of Demeter
The last one is not a principle, but it can be used as a guideline of design. The purpose is to limit the access boundaries of the objects. Simplifying it with an example, given an object A that accesses an object B, and this object B access an object C. You could never ever from A, use B to access C. A should only know about B and communicate with it and not mix with any of the concerns of C. This is to keep responsibilities separated which makes it is easy to extend and maintain.

After reviewing these acronyms, it has never been so easy to remember how to write good code, right? Now I guess we only need to remember when to do it… I use these acronyms quite often, especially when I am pairing with other people. I like them because they are easy to remember for everybody, not just me, and also because of the massive amount of knowledge compressed in just a few words. They may look silly or obvious, but they are a distilled sentences of really complex and recurrent problems in software development.

Pair programming, keen to try it?

Josep Mir — Fri, 17 Jan 2020 09:58:53 +0000

Pair programming: The technique in which two programmers share a single workstation.

What is Pair Programming?
It is a technique in which two programmers work in just one machine. The one who writes the code is called driver, and the one who reviews what is written is called navigator. In addition, the navigator also has to come up with a strategy to tackle the problem, making suggestions for improvements or prevent future problems. By doing that, the driver can focus exclusively on solving the task and rely on their partner for guidance.

Do not expect people to be good at pair programming from the beginning, it is a social skill that needs time to master. It is a cooperative way of work that needs efforts from both partners regardless of the corporate level. Both members should verbalize their thought process to become effective. This technique relies on successful communication over programming skills.

Swapping roles
This is a turn-taking technique, the programmers must switch roles often. How often do they have to switch, is something that every pair must decide, but in any case here are some known tactics:

Ping-pong, used with TDD, one person writes a test and the other make it pass. Later they can decide if they do a refactor or write the next test, following a red-green-refactor structure. They must swap who is writing tests and who is writing production code, that is an anti-pattern of the technique.
Pomodoro, members switch roles in every iteration of this method. It is more structured, but they have the time fixed to switch and mandatory breaks, something important and usually forgotten.
Unstructured switching, when the members know each other well, they can decide when they pass the keyboard to their partner. The only concern here is that at the end of the day, they must have been in both roles the same amount of time.

Benefits of pair programming

It seems like an ineffective use of resources, the literacy and empirical studies say that two programmers working together have at least nearly the same productivity than working separated, some others go even further than that,... I guess it really depends on each team.

The amount of errors is reduced considerably, therefore the software quality is increased without compromising the time to deliver. This increase in quality will pay off later in the project. At the beginning, the productivity may decrease a bit, but it is mainly because the quality of the code code produced is much better.

Solutions are evaluated upfront, not once they have been implemented in a code review. Before implementing a solution, the pair discuss, evaluate and identifies the possible trade-offs.

It is an effective way to share context and knowledge of the project across the development team, when the code is written, both programmers share the context. The knowledge and the context is spread across the team, so when somebody leaves the project, it is not that dramatic and the team does not need to spend extra time in meetings or code reviews.

One of the biggest advantages of pair programming is the mutual learning. The best practices are shared, it is the best way to develop skills, especially for junior programmers, but it has its benefits for senior programmers too. Everybody has something to teach, everybody has something to learn.

The positivity in the team is increased, facing complex problems with someone helps the moral support of the individuals.

Procrastination is reduced to the minimum, knowing that having someone waiting for you to work puts some pressure. Also distractions are reduced, because most of the times you cannot respond that slack message or that email in front of the other person.

Pair programming also makes awesome on-boardings, the productivity of new members of the teams is boosted when pairing with more experienced developers.

Increases overall employee satisfaction, developers are not just happy because they are learning a lot from others or because they are improving their career. They also know better their peers at personal level, which builds a feeling of belonging to a community or a pack. This is great for introverted programmers, which are the majority of them.

It helps to develop interpersonal skills, teams become more collaborative. They learn how to communicate with each other, work together, organize themselves and share information.

It is a fantastic recruitment tool, doing an exercise or a kata using this technique you quickly realize how the other person analyzes the problem, how approaches it, if the feedback is accepted, and how is the code produced. Sure there are other factors to take into account in the recruitment process, but generally, people don’t code at the same level that they talk, some are above and some others below.

Concerns to take into account

It is difficult to engage developers that are free in the wild to commit to work with someone. This technique may not be attractive at all to developers that always have worked on their own.

Despite the fact that there are some companies that do not allow to write production code alone, it is not a good option to force its adoption, members of the team may have issues between them and forcing them to work together could lead to dramatic consequences.

Beware of stress, fatigue and motivation, when programmers are not in the proper state, they may not be concentrated or communicative enough to perform a good pairing exercise, dropping the productivity of the pair.

Simple tasks may be ineffective due to its simplicity. Two heads think better than one, on complex tasks for sure, but in simple tasks where there is no need to anticipate possible problems and the code is so simple than does not even need much attention, the navigator may get bored and out of the exercise.

Conclusion

This is one of the core techniques of the extreme programming practices, it should be at least considered by teams and organisations.
Take into account, that theoretically this may look costly ineffective in the short term, but the increment of quality pays off in the mid-long term.
Personally I think that the risks or problems are not that complicated to prevent and the benefits that you may get are so interesting that it would be a big loss not give it at least a try. It doesn’t need to be fully adopted by the organisation, nor do it all the time, but enough to learn it and to be sure that it is done right, measure it and make a decision based on the results of your team. Remember, pair programming is not for everyone.