Normalization of Deviance: What to do when human nature collides with procedures in the workplace.

Normalization of Deviance: What to do when human nature collides with procedures in the workplace.

Curated by: Sergio A. Martínez

Let’s think of the following example: imagine a brand-new bridge connecting two highways over a river. This highway sees a lot of traffic, including transport trucks that must pass from one side to the other daily, which tend to have a weight, on average, of about 25 tons. Thus, they mark the bridge accordingly: Limit Weight: 25 tons. However, the engineers know that they need a safety margin to ensure that the bridge doesn’t stress and wear out too quickly, so it’s designed to actually support up to 35 tons. It all seems good until one day, ten years later, the bridge collapses; a 40-ton trailer tried to cross it, and a tragedy occurred.


It’s easy to point a finger at the culprit, right? That truck was way too heavy for this bridge, so we need to build sturdier bridges and think of a system that checks if a truck has the appropriate weight before crossing. Maybe even instill punishments and fines for people going over this limit. Easy stuff. Well, if that’s the case, then nothing was learned from this disaster. It will happen again in the future.

This is normalization of deviance. Simply put, it’s when people become so accustomed to seeing certain things done wrong that they no longer register as problems, but instead as the way “things work”. And they do work, until the day they don’t: catastrophic failures like a bridge collapsing are seldom the result of a single, unavoidable act of God, but instead the accumulation of small problems that one day reach a breaking point.  And normalization of deviance is a huge problem in the software development industry. 

However, how exactly does the normalization of deviance work, how does it affect software development, and what could be the steps to mitigate, or outright eliminate, the risks it presents?

Bending the rules (until they break)

Normalization of deviance

Software and civil engineering are not that different, at least when it comes to the complexity and precision needed to build things. After all, engineering of any kind is the art of finding solutions that work under stress: creating stuff that works reliably, no matter who is using it. So, no matter if you work with code or concrete, the process is roughly the same: you need to take into account every single situation that the design demands. And thus, both disciplines also tend to have very similar problems, with the normalization of deviance being one of them.

Let’s go back to our bridge example: what was the actual problem? The truck was way too heavy to safely cross that bridge, for sure. But why was such a truck trying to cross it in the first place? Because simply put, it was a normal thing to happen, and if that sounds like a contradiction, you would be right. After all, the normalization of deviance is a lesson in human nature.

People like to bend the rules. That’s what we do. Intellectually, we know rules are meant to keep things working properly, but rigidity is not our strong suit as a species. In the words of veteran programmer Foone Turing: “We always want to optimize. We want to do things cheaper, quicker, and more at once. And the thing is, most of the time going a little faster, a little hotter, that’s fine. Nothing goes wrong. Engineers always design with a safety margin, as we’ve learned the hard way that if you don’t, stuff goes wrong very fast. So going 110% as fast as the spec says? probably OK.

So, you may see where this is going. In our bridge example, an interesting wrinkle is that the disaster didn’t happen right away, it was a full decade after the bridge was constructed. That’s the tricky thing with the normalization of deviance: it takes time to build up. It works through subtlety: if your bridge says that it has a limit of 25 tons, but you once drove a 30-ton truck through it and nothing happened, then the actual limit is higher, right? You can do it again. And if you do it enough times?

You’ve been going 110% all the time. It’s worked out just fine. You’re doing great, no problems. You start to think of 110% as the new normal, and you think of it as just 100%. […] Then one day you’re running into 5 other problems and need to push something, well, maybe you do 120% today? After all, it’s basically just 10% of normal…”. That’s how you get a 40-ton trailer trying to cross a bridge rated way lower than that: someone drove through it with 35 tons of cargo, and nothing happened. 36 should be fine, right? Or 37, or 38, and so on. Bending the rules became so normal, without any immediate consequence, that it ceased to be wrong. Slowly, it became the standard, and a standard supported by bent rules is always a time bomb.

But how to avoid deviance?

Normalization of deviance

In software development, the normalization of deviance can happen at every level. For example, at a product level, it’s not exactly unheard of to release software that is not fully tested, on the assumption that the bugs will be fixed in future releases, which can lead to serious problems, such as data loss or security vulnerabilities. At the development level, programmers can start to disregard code style conventions if they feel slowed down by them (there’s a deadline to meet after all), resulting in a codebase that is difficult to read and maintain. And at the security level, it’s often easier to just write down a password than wait half an hour for IT to reset your account if you forget it. In either case, the result is the same: an organization will start accumulating issues until something serious breaks one day.

However, diagnosing the normalization of deviance can be difficult because there’s no immediate feedback loop to it. The bridge probably doesn’t produce a loud cracking sound if you go a couple of pounds above the limit, or the code doesn’t stop working immediately if you deviate a little from a style convention, so implementing effective ways to detect when it’s happening, or to deter this kind of behavior, can be tricky.   

The aforementioned Twitter thread gives a great example of why: “Susan gets in trouble because she put a post-it note with her password on her monitor, and we had to sit through a boring security meeting about password security. So, people learned to put their passwords in their wallets and their phones.” Or in other words, maybe the systems we have in place provide the incentive to deviate from the rules in the first place, and having after-the-fact measures don’t do enough to stop the buildup of problems. In that case, it falls on the culture of an organization to take into account these possible challenges and take the steps necessary to avoid lowering standards as a normal practice. These four key points might help:

  1. Rules are not forever. When it comes to technology, a year might as well be a decade in terms of advancement and innovation, so every procedure and workflow must be constantly reviewed to ensure “rule-bending” is not encouraged when certain parts lag behind, becoming obsolete or just ineffective. Revising and streamlining are always valuable skills for the leadership of any company to have, and giving people the power to always ask “why” could help avoid problems down the line.
  2. Open communication is critical. In that same sense, the main danger of deviance is that it develops in secret. Effective project management means communicating effectively with people, making clear the purpose of every rule, and being open to opinions, suggestions, and discussions to ensure those rules are effective and followed. Also, promoting an environment where a developer can communicate when a rule must be broken for the good of a project is crucial, as it allows management to respond and control such changes. “This situation has happened to us in the past”, says Jesús Magaña, Senior Project Manager at Scio. “And this decision has never been taken lightly. The objective, after all, is reaching the finish line without compromising quality or performance. This ‘shortcut’ has to be done with the consent of the Project Manager and the client, keeping in mind the possible consequences of doing so.”  
  3. Any change has to be clear and well-thought. The software sector is also ripe for new technologies, frameworks, languages, and tools to be implemented during development, but these changes are not trivial. If a new element is adopted within the development environment without proper measures (like clearly explaining the benefits and drawbacks of the new tool, giving people enough time to acclimate to change, being open to concerns, etc.), the risk of deviance grows.
  4. A culture of collaboration, not politics. Probably the most common cause of normalization of deviance, many of these examples don’t happen in isolation. Humans are social beings that tend to form cliques and in-groups that cover for each other, which can happen at every level of the organization, and thus be the perfect place to brew deviance that could snowball into disaster. So, promoting collaboration, being lenient enough with consequences so people feel comfortable about speaking up, but not to the point that developers feel they can get away with anything, and frequently promoting people to mix and work together in different configurations might be the key. It all comes down to skilled leadership.

And knowing is half the battle

Normalization of deiance

However, let’s not assume that these steps, although useful, are completely infallible when it comes to mitigating the normalization of deviance because this kind of behavior is simply human. We bend the rules when we know we shouldn’t, even at a personal level sometimes (“I’m on a diet, but this piece of cake shouldn’t be a problem, right?”), but that doesn’t mean that we cannot anticipate, learn, and improve at every opportunity. Understanding this is what separates good software organizations from the rest of them. After all, as Jesus Magaña tells us, “one of the values of the Agile Manifesto establishes that ‘people and interactions are above tools and processes’, which implies that a process doesn’t have to be a rigid path. Sometimes you need to veer off-course, and that’s not cheating. Let’s just keep in mind that, if everything is going well during development, a process is meant to help us to be consistent with the quality of our work.

The Key Takeaways

  • Normalization of deviance, of lowering standards over time, is always a risk in any industry, especially software development.
  • Simply put, people are going to bend the rules when that benefits them because that’s simply human nature.
  • The main danger is that this normalization is almost always invisible until too late, helping the build-up of issues and problems until a disaster occurs.
  • It’s up to the management and culture of an organization to mitigate this deviance, which is virtually impossible to eliminate but can be avoided with the right approach to communication and collaboration.

Scio is an established Nearshore software development company based in Mexico that specializes in providing high-quality, cost-effective technologies for pioneering tech companies. We have been building and mentoring teams of engineers since 2003 and our experience gives us access not only to the knowledge but also the expertise needed when tackling any project. Get started today by contacting us about your project needs – We have teams available to help you achieve your business goals. Get in contact today!

The Toyota Production System in software development: Lean, Agile, and Effective.

The Toyota Production System in software development: Lean, Agile, and Effective.

Curated by: Sergio A. Martínez

Software development is a notoriously unpredictable process. Even the most experienced developers can find themselves facing unexpected challenges and surprises which can lead to frustration, as new requirements pop up, deadlines change, and unanticipated bugs can throw everything off course, especially as projects grow in size and scope, and a tighter collaboration and approach is needed.


As a result, in such a volatile industry, it’s important to avoid waste whenever possible; anything that doesn’t add value to the end product, from inefficient code to unused features, should be left off, as it helps to keep development costs down and ensures that the final product is as high-quality as possible. 

However, due to how unpredictable software development can sometimes be, a good approach is to use lean practices. Lean practices in software development aim to create more value for the customer while minimizing waste. This is achieved by constantly improving the process and eliminating anything that doesn’t add value, helping to reduce the risk of errors and defects by catching them early on.

Our current model of lean development comes from the Toyota Production System, a manufacturing approach that seeks to make the whole process as efficient as possible in seven key areas: overproduction, inventory, motion, defects, over-processing, waiting, and transport. And although the material processes involved in manufacturing cars and developing software look very different from a distance, applying this same logic brings even better outcomes; common lean practices include things like continuous integration, continuous delivery, and test-driven development, in addition to reductions in the cycle time and batch size, so developers can ship working software more frequently and get feedback earlier, allowing them to make course corrections sooner, leading to a more efficient process overall. 

As a result, lean practices can lead to significant improvements in software quality and developer productivity by promoting continuous improvement and efficient use of resources. By identifying and removing unnecessary steps, lean practices help to improve quality and speed while reducing costs. In an industry where time is always of the essence, lean practices can play a vital role in helping developers deliver high-quality software on time and within budget.

Lean Manufacturing and Agile Methodologies, hand in hand

The Toyota Production System in software development Lean, Agile, and Effective. 3

Both approaches have their strengths that complement each other very well. On one hand, lean manufacturing is all about efficiency and minimizing waste, and on the other, Agile focuses on flexibility and responding quickly to changes”, says Luis Aburto, CEO, and Co-Founder of Scio. “Together, these two methodologies can help to create a process that is both efficient and adaptable; for example, Agile can help to identify areas where lean manufacturing could be improved. And lean manufacturing can help to streamline the Agile process and make it more efficient, enabling developers to create a process that is both responsive and efficient – the perfect combination for today’s ever-changing landscape.

But what do these lean practices look like in an Agile environment? By adapting the Toyota System into a software development process, we can come up with a series of key areas or steps where it’s possible to avoid waste, and thus create products that accomplish the goals of the client, the team, and the project in the least wasteful way possible. Such key areas are:

1. Unnecessary Features.

There is an oft-cited study by the Standish Group that famously says that “45% of the features in a given application are never used”. If that number seems too high, you may be right (it was based on four internal applications, which is a small sample), but trying to keep requirements in check is a key point of lean development. If your requirements team tries to anticipate everything a client might want in their product, it’s easy to add features that will not matter to the final user. An Agile methodology, then, which prioritizes the most critical features, is the best strategy to save resources otherwise wasted on elements nobody needs or wants.

2. Unnecessary Value.

Following the last point, there is such a thing as unnecessary value, also known as “gold plating”, which is devoting too many resources to polish a product in places where it’s not necessary, risking the cost-effectiveness of a project. “Good enough” is not a bad approach, especially in software where a finishing point tends to be nebulous at best, and continuous support, debugging, and updating is a normal part of the job.

3. Unrealistic Expectations.

Most of the problems of these last two points stem from overestimating the resources, time, and effort needed to accomplish a project, and thus overpromising on a result. Trimming down requirements to their most basic and critical not only helps a team to get going with development but also ensures they can make the necessary progress on each sprint, focusing on a narrow set of variables easy to control and correct. Going beyond that only ensures problems down the road.

4. Unnecessary Innovation.

Ready-made solutions to challenges and obstacles in development are not forbidden; getting stuck “reinventing the wheel” is an easy way to waste resources and delay a product in search of a completely new approach that might or might not have benefits in the long run. No-code solutions to prototype applications, AI-based tools to look into coding solutions, and the like are tools that can have a marked positive outcome when striving for timely delivery each sprint.

5. Unnecessary Downtime.

Waiting for a team, or even a single developer, to deliver to another to continue development is seldomly a process that results in efficiency. One of the key points in Agile methodology is to structure development to avoid this downtime, with short overlapping steps that ensure no one gets stuck and delays the contributions of the rest of the team and splitting development into blocks where “the business owners can identify the next set of features while the development and QA teams can implement the last requirements.

6. Over-relying on QA.

Going back to our “good enough” philosophy, achieving this result doesn’t mean that developers can let their guard down concerning bugs and errors in the codebase of the product; good lean development has quality implementation at each step of the process, with QA as a continuous process that audits development at each step. Code reviews, unit testing, and constant communication are key to reducing the time and resources necessary in QA to achieve the best possible product.

7. Underused Creativity.

The Agile methodology knows the value of creativity and problem-solving as a tool during development, letting each member of the team add their knowledge, experience, and insight into the perfect solution for any programming challenge. Treating development as a machine where every cog has a specific function, without context, collaboration, or communication, is a sure recipe for negative outcomes if the individual developer doesn’t have the flexibility to bring any useful input they might have.

Bringing Agile talent to your team

The Toyota Production System in software development Lean, Agile, and Effective.

When it comes to software development, the lean approach is all about doing more with less, having the goal is to reduce waste and increase efficiency by streamlining the development process and choosing the right talent and collaborative environment that can be conducive to that, with Nearshore augmentation offering an alternative that brings the best of both approaches.

One of the benefits of Nearshore development is that it is easier to implement a lean software development process. This is because the team is already in place and there is no need to go through the hassle and expense of setting up a new office or hiring additional staff, saving on time and resources when starting a new project. In addition, nearshore teams are typically more flexible and responsive than offshore teams, making it easier to implement changes rapidly. 

As the software development landscape evolves, more organizations are turning to lean and agile methodologies to streamline their processes and deliver better results. And while these approaches can offer a number of benefits, they tend to work best when teams are nearshore”, explains Luis Aburto. “Nearshore teams tend to have a better understanding of the local market and what customers are looking for. This knowledge can be invaluable when it comes to developing software that meets the needs of the target audience. Additionally, nearshore teams are typically more responsive to changes and feedback, which is essential in an agile environment.

As a result, lean software development processes can be more effectively implemented with a Nearshore team in place. This can lead to quicker turnaround times and reduced costs, making it an attractive option for businesses that are looking to improve their bottom line. In addition, it is important to build flexibility into the development process, being willing to adjust plans on the fly and make changes when necessary. By remaining flexible, developers can ensure that their projects stay on track, even when faced with unexpected challenges.

The Key Takeaways

  • The unpredictability of software development can create situations where avoiding “waste” (of time or resources) is the main obstacle to productivity and the effectiveness of a development cycle.
  • The “Toyota Production System” can offer some guidance for a lean development approach that can help alleviate these challenges.
  • Lean development is as its most effective when paired with an Agile methodology, feeding each other to achieve peak effectiveness and the least waste during any given project.
  • Working with Nearshore talent to augment your staff is also a great option to avoid waste, as an organization doesn’t need to commit time or resources to build a team and start development right away.

Scio is an established Nearshore software development company based in Mexico that specializes in providing high-quality, cost-effective technologies for pioneering tech companies. We have been building and mentoring teams of engineers since 2003 and our experience gives us access not only to the knowledge but also the expertise needed when tackling any project. Get started today by contacting us about your project needs – We have teams available to help you achieve your business goals. Get in contact today!

The Bus Factor and Nearshore talent: A net positive outcome

The Bus Factor and Nearshore talent: A net positive outcome

Curated by: Sergio A. Martínez

When you’re cooking up a new software application, it’s important to think about the future. We have talked before about measures like futureproofing, refactoring, and how to deal with technical debt to maintain an application in the long run, but let’s look today beyond the product, and think instead about the team in charge of helping it become a reality. And “the Bus Factor” is key in all of this.

What does "Bus Factor" mean?

What does “Bus Factor” mean?

Chances are you won’t be the only one working on the project; at some point, someone will need to pick up where you left off. It happens all the time, as it is not very realistic to expect that the same people that build a piece of software will be around forever to take care of it when the need arises. 

That’s why it’s important to have a robust risk assessment approach to development, identifying anything that could jeopardize the success of a project. This includes both technical risks, such as the possibility of errors in the code, and non-technical risks, such as changes in market conditions. Risk assessment is an important part of project management, helping to identify potential problems early on and develop plans to mitigate them. There are several different methods for conducting a risk assessment, but all involve breaking down the project into its component parts and evaluating each one for risks. 

And when it comes to assessing risk in software development, the Bus Factor is an important consideration to ensure a project not only gets finished but also can be trusted to work in the long run. Simply put, this factor indicates the number of people who would need to be proverbially “hit by a bus” before a software project would be severely impacted and stall. If your Bus Factor is 3, for example, that means that losing 3 people is all you need for the project to fail, so measures to bring that number up become necessary to guarantee a good outcome in development.

As a result, it’s essential to pay attention to the configuration of a team when developing software. By ensuring that team members are aware of the codebase, that collaboration is encouraged, and that everyone is on the same page, you can help to reduce the risk of potential problems down the line.

A bus is always around the corner

The Bus Factor and Nearshore talent: A net positive outcome

So, with proper risk assessment, software development projects can be more successful and less likely to encounter unforeseen problems. That’s why it’s important to increase your Bus Factor; if too few people know how the code works, if the tasks are too partitioned, or if there’s no good collaboration between team members, then the project is at risk. A low Bus Factor can lead to problems when people leave the team, get sick, or are otherwise unavailable, bus involved or not. 

Losing key people during development can be devastating. They can take with them valuable knowledge and expertise that can be difficult to replace, as well as disrupting the workflow and causing delays”, says Adolfo Cruz, PMO Director and Partner at Scio. “However, the worst part of losing key personnel is the impact it can have on morale. When experienced and talented individuals leave, it can be demoralizing for those who remain and damage an organization’s ability to attract new talent. It’s a ripple effect that extends far beyond the immediate impact on the project.

So, when it comes to increasing your Bus Factor, there are two sides to take into consideration. The first one, the technical part, is simple enough: losing people can make it difficult to make changes to the codebase, since there may be no one who understands how it all fits together, and some good practices in project management are important to reduce this risk as much as possible. For example:

  • Use comments liberally. Some programmers believe that comments are essential, while others feel that they only clutter up the code. After all, well-written code should be self-evident, and easy to understand, but in a complex project with many people involved, it never hurts to explain what the code is doing and why. If you need to bring someone entirely new to the project you can easily waste time trying to reverse-engineer some vital functions of the application. So even if the code looks obvious, leaving comments just to be sure it can be understood in the future goes a long way toward ensuring a project can be maintained properly. 
  • Write clear and concise documentation. On the same token, this will help others understand the design decisions behind your code. Without clear and concise documentation, it can be difficult to keep track of the various code dependencies and file hierarchies, essential for ensuring that the project runs smoothly. In addition, documentation can be extremely helpful when it comes to debugging (which may not be done by the exact same team that wrote the code), aiding to pinpoint the root cause of a problem more quickly.
  • Hold regular team meetings. The Agile methodologies in software development have done wonders for team collaboration, offering a way to keep everyone up to date on the project’s progress and ensuring that everyone is on the same page. Additionally, by keeping everyone in the loop, points of failure can be identified before they become a problem for the project, making regular meetings with the team a must for a well-managed development cycle.

By taking these steps, you can help increase your Bus Factor and make it easier for others to step in and continue working on your project if something happens to a key member of the development team. Nevertheless, the challenges of maintaining a project can go beyond the product itself, and with the way development works today, a different approach might be needed.

What happens when the bus is in another country?


Software development is a notoriously challenging field, and one of the biggest changes we are currently living through is the normalization of remote teams, an increasingly likely outcome in a post-pandemic world where the advantages of having a hybrid approach and collaborating with external people, have become clear.

However, how does the Bus Factor come into play when your team is distributed over a wide geographical area? With so many options in outsourcing or hiring freelancer developers to collaborate on a given project, management has an increasing challenge in keeping everyone looking in the same direction and minimizing any risk involved in not having direct contact with a team. The challenge is that software development often requires very specific skills to carry through, from programming languages to types of technology being worked on, and the Bus Factor gets lower as more variables are involved in development.

The complexity of a project isn’t necessarily the biggest problem contributing to your Bus Factor; that dubious honor goes to the subject’s specificity. The more specific your topic, the worse your bus factor will be. More specifically, if all other factors remain constant, your bus factor will decrease proportionately to how much specific expertise is required to carry out your work”, explains the blog “How to Beat the Bus Factor (and Be Prepared for Anything)” published by the workflow management company Process. st.

This is especially true when a project requires very specific skills that are hard to find. For an extreme example, imagine you’re working on a project requiring knowledge of a particular software library that only a handful of people know how to use. In such a case, it can be nearly impossible to find someone with the necessary skill set, and in case you do, how do you ensure that person not only remains during the entirety of development but also can come back and help if something goes wrong? Or leaves enough documentation behind so other people in the team can continue? If those questions are a concern, a different approach may be needed.

As the benefits of Nearshore collaboration become more widely recognized, even more businesses will likely choose to partner with developers in Mexico and Latin America”, says Luis Aburto, CEO, and Co-Founder of Scio. “There are many reasons for this trend, but one of the most important is the increased collaboration that Nearshore development enables, letting developers in nearby time zones to integrate easily to a specific project.

The option of Nearshore is attractive if an organization is looking to increase its Bus Factor, guaranteeing a positive outcome in the development cycle. You may have heard of Nearshore companies before, easily confused with mere outsourcing at first glance, but unlike trusting development to an external team (often in faraway locations such as India or China), the Nearshore model offers many benefits, including shorter project timelines, competitive costs, and reduced risks within the same time zone, allowing for a smoother collaboration no matter where in LATAM is the talent you want. 

In the case of Scio, we offer teams of skilled and experienced developers working together, putting collaboration and knowledge-sharing as some of our core tenets. This way, some of the common approaches to increasing the Bus Factor (like cross-training developers in a multitude of skill sets, empowering developers to grow and take on more challenges, implementing Agile methodologies, encouraging close communication at every level, and generally fostering a culture of collaboration and team-focused mindsets) are endemic to Scio, where not only we ensure any onboarding process in a new project is as seamless as possible, but also that everyone is continually learning and growing with new skills, offering knowledge and insight at every turn. In the rare cases, the Bus Factor comes into play, have ready-to-go measures to minimize its impact.

In short, the Bus Factor is an important part of risk assessment in every software development project, and increasing it as much as possible is always the best policy. So next time you or your company is looking into bringing talent to a team to complete a project, think of the best options out there to manage this risk as best as you can. 

The Key Takeaways

  • Risk assessment is important for every software development cycle, and the Bus Factor is one of the most critical metrics to watch out for.
  • In short, the Bus Factor is the number of people that can leave a project before it stalls completely, leading to negative outcomes for development.
  • Good practices can be implemented (like a commenting discipline, through documentation, and having consistent meetings to keep everyone in the loop) can increase the Bus Factor in any project.
  • However, when it comes to working with remote or distributed teams, the Bus Factor can increase depending on the approach of this collaboration.
  • Nearshore development can offer a solution, with organizations like Scio offering the support and culture necessary to ensure collaboration is a success, and a positive outcome can be reached for the project.

Scio is an established Nearshore software development company based in Mexico that specializes in providing high-quality, cost-effective technologies for pioneering tech companies. We have been building and mentoring teams of engineers since 2003 and our experience gives us access not only to the knowledge but also the expertise needed when tackling any project. Get started today by contacting us about your project needs – We have teams available to help you achieve your business goals. Get in contact today!

Ghost colleagues: Creating a sense of professional connection in the age of remote work.

Ghost colleagues: Creating a sense of professional connection in the age of remote work.

Curated by: Sergio A. Martínez

There is such a thing as a colleague in the age of remote work? As we begin to get accustomed to working far away from the office, even for a couple of days a week, some of the things we took for granted in the past have begun to be re-examined and appraised after the pandemic started, especially around the social side of things.


On one hand, remote work started to be normalized, bringing a lot of perks with it: the ability to set your own hours, avoid commute times, and save money on office expenses, as well as a greater sense of control and flexibility over your work life became invaluable for many people, and the ability to design their workspace and create a flexible schedule seemed to outweigh the drawbacks of this model.

But on the other, there’s a challenge in adjusting to working in isolation; in the modern reality of work, more and more people are finding themselves trying to create meaningful professional relationships with colleagues through a screen, and this complete absence of human interaction can have some effects not only on the mental well-being of a person but also how their professional career changes and develops.

But what is a colleague? Just someone you work with? Or does it encompass a lot more? A colleague, to put it simply, is someone you can rely on, whether you need help with a project or just a sounding board for your ideas; it’s someone who will challenge you and push you to be your best, and who will support you, both professionally and personally. Having a strong network of colleagues has been thought essential for any successful career, but now, forming these kinds of bonds seems to be getting more difficult by the day.

A workplace of ghosts

Working in software development can be a great career; you get to use your creativity and technical skills to solve complex puzzles and build products that people use and enjoy. However, it’s also a very collaborative effort that often needs a well-synchronized team looking in the same direction to succeed. So, what has been the effect of remote work when forming bonds with a colleague to create a successful product? 

I think the biggest challenge when working remotely is that you don’t know your coworkers very well, which can make communication difficult”, says Julián Verján, a developer at Scio. “Establishing bonds beyond the job, like friendships, is difficult. I feel like, once we stop being coworkers, that connection can get lost easily, something I feel doesn’t happen as much with more face-to-face interactions.

Beyond productivity, which has increased noticeably during the pandemic, the challenge faced by most modern software development organizations is more cultural in nature; missing out on the daily interactions that help to build relationships, or the opportunities to collaborate and learn from each other can have consequences on the overall cohesion of a team. 

Contact is important. You are more excited about your work and meeting new people. Personally, in the Marketing department of Scio, I feel I have to be updated by my colleagues, and which new projects they are working on, etc.”, comments Ari Hernández, a Digital Media Designer also at our company. “I think immediate communication is the biggest challenge. I’m now used to scheduling video calls to discuss the smallest things when I could just walk up to the person in the office and ask. And there are things that you cannot communicate as easily through chat or video calls.

This has given rise to the term “ghost colleagues”, the people on your team who you never actually meet in person since you’re both working from different locations. Even though you may never meet face-to-face, you still have to collaborate with them on projects and stay in communication via email, platforms like Slack or Microsoft Teams, or video chat. And it can be tricky to build a rapport with someone when you’re not actually in the same room, especially without any downtime at all between interactions, which tend to always be work-related. Additionally, if you have questions or need assistance with something, it can be harder to get help from a ghost colleague than it would be from someone right there in the office with you.  

I would define the relationship with my coworkers as purely professional. Everybody is very nice to each other, but I feel it could be different with more face-to-face interactions. The good thing is that many here have the same sense of humor as me”, says Ari again, about her feelings towards remote work.

And this approach to colleagues has noticeable effects on the work itself, and how a worker approaches their job; a study cited by the BBC says that “part of the reason is that these social ties people have in the workplace feed into their sense of attachment and belonging at work. […] 65% of workers who had switched to teleworking all or most of the time felt less connected to their colleagues than they did before. A second study showed almost a quarter of workers felt disconnected from goings on in their company overall.

Bringing the team together (at distance)


Of course, a lot of the responsibility of bringing everyone together, even remotely, rests upon the culture built inside an organization; is not enough to just connect developers and tell them what a client needs (the “how” of remote teamwork), but to ensure the collaborators are looking in the same direction, sharing the same values, and moving to the same rhythm (the “why” of remote teamwork”). 

Speaking strictly about the job, I’ve always felt very comfortable thanks to the Scrums we do every day. We all know what everybody else is doing during that day, making it easier to move as a unit”, says Julián again. “I think the biggest challenge is not knowing your coworkers very well, but Scio solves this pretty well. They do like to organize calls and activities to just kick back and relax, get to know each other, and even practice our English. It’s pretty neat.

Anyone who has ever worked in an office knows that a positive relationship with your colleagues is key, which is why Scio likes to promote good chemistry among every collaborator. For one thing, a good working environment is more enjoyable and motivating, and when you get along with the people you work with, you are more likely to feel like part of a team and be invested in your job. Moreover, a good working relationship with your colleagues can lead to better collaboration; if everyone is on the same page, it can make it easier to get work done.

I think a hybrid approach is the best. It lets you build a connection with your partners, and personally, I like to dress up and get out of the house”, says Ari. “I’m glad there’s the option to work from home, even if I found it difficult to adapt at the very beginning. I feel productive now that my routine is pretty well established, but I’d still like to visit the office sometimes.

The workplace can be a lonely place if you’re the only person in your office, after all. You might feel like you’re on your own while keeping up with the workload, and when you take a break, there’s no one to chat with about the latest office gossip. But it’s important to remember that you’re not alone, especially if your workplace offers ways to connect with your colleagues, so here are a few tips for overcoming this kind of isolation: 

  • Try to socialize. Even if you’re not naturally outgoing, force yourself to chat with your co-workers or strike up a conversation with someone new. You never know when you might make a new friend.
  • Get involved in company activities. If your company offers any type of social event or team-building activities, make an effort to participate. It’s a great way to meet new people and build relationships.
  • Don’t be afraid to ask for help. If you’re feeling overwhelmed, reach out to your supervisor or a coworker for guidance. Asking for help is a sign of strength, not weakness, and you might even strike a deeper connection with someone that way.

Just because they’re not physically present doesn’t mean they’re not interested in getting to know you. By trying to connect with others, you can overcome the challenge of working remotely and avoid feeling isolated, and have a better sense of community to make development as enjoyable as it can be.

The Key Takeaways

  • The term “ghost colleagues” has become famous thanks to the fact that most remote collaborators do not have the opportunity to work face to face with their peers.
  • Although remote work has many perks, this isolation can give some side effects that a company with good culture has to minimize.
  • A hybrid approach seems to be the most popular option; by giving a chance to meet in person, while not taking away the benefits of a remote office, most developers can find their own balance and feel more connected to their colleagues.

Scio is a Nearshore software development company based in Mexico where we believe that everyone deserves everyone should have the opportunity to work in an environment where they feel like a part of something. A place to excel and unlock their full potential which is the best approach to creating a better world. We have been collaborating with US-based clients since 2003, solving challenging programming puzzles, and in the process showcasing the skills of Latin American Engineers. Want to be part of Scio? Get in contact today!

The Rubber Duck Method: What is the explanation behind this debugging approach?

The Rubber Duck Method: What is the explanation behind this debugging approach?

Curated by: Sergio A. Martínez

Debugging software is an important, if often tedious, the task for any programmer. Finding and removing errors generating crashes, freezes, or incorrect results is critical to ensuring the quality of a piece of software, and while some bugs can be fixed with a few simple tests, more difficult ones require special approaches and techniques. And thankfully, there are many resources available to help programmers debug their software; after all, with patience and perseverance, even the most difficult bugs can be squashed.

The Rubber Duck Method: What is the explanation behind this debugging approach?

One such technique is the popular Rubber Duck method, which may already be familiar to a seasoned developer. In short, the Rubber Duck method is a debugging approach in which developers explain their code line by line to an inanimate object, such as a rubber duck. This may sound silly, but it’s an incredibly effective way to find and fix mistakes. 

Computers process information differently than humans do. Anyone who’s first learning to program understands this well. What’s hard about programming for a beginner isn’t really big hard esoteric concepts, but that you’ve got to be so painfully exacting in how you describe everything to a (dumb) computer. That’s why we do rubber duck debugging.

However, have you ever been curious about why this approach works? What exactly happens in our brains when we verbalize a problem to someone else (even if that someone just happens to be a bath toy), that could lead to a solution that was obvious all along? And what is the best way to implement this method to finally find and solve that bug that has been bothering you all week?

The challenge of language

Computers are dumb. And we don’t mean that in a Luddite, anti-tech sort of way, we mean it in the original definition of “dumb”: incapable of human speech. And speech here is more than just talking; speech includes context, mood, choice of words, familiarity, and an infinity of other variables that a computer can’t understand (yet).

Of course, this doesn’t mean that we cannot communicate with computers, it just means that we use specialized languages to do so, and every single one of them works with the principle that computers are dumb: unless you tell a machine exactly what they need it to do, or how to react when something happens, they will not produce a desirable outcome. Thoughtful Code put it best:

‘Is it cold outside?’ is a question that most humans, having some idea of the weather, will answer pretty easily. They’ll say something like, “No, it’s pretty nice.” Asked that question, a computer — or a really finicky and hyper-rational person — will need you to define each of those words.”  

A computer understands the most literal and absolute terms and learning to manipulate those terms is the basic principle of programming. This also means that computers don’t make mistakes, people do. So, if something within the instructions given to the machine doesn’t add up, then the program will not work as intended, and finding the exact place where the communication between a person and a computer got out of alignment can be a challenge. Here’s where the rubber duck comes in handy, thanks to the way we process language.

Here’s a fun fact: did you know that reading, writing, and speaking are located in completely different parts of our brain? Our understanding of the way we use and apply language is always evolving, but it is understood that we use different functions depending on the type of language we employ, which is why it’s so useful to verbalize a problem to find a solution: you involve a completely different part of your mind to help.

Of course, the Rubber Duck method is not useful only in software development, but since computers are very linguistically complex tools (being probably the only ones we need to “speak to” to use), verbalization is useful here, forcing developers to slow down and think about the minute details of their code, which can help to spot mistakes that they would otherwise overlook. As the blog “The Psychology Behind Rubber Duck Debugging” puts it:

A lot of times, I’ve experienced some programmers that will ask my help about a specific bug they are fixing. I will then ask them how their application and their code works. I literally have no idea how to fix a program that is not mine and have no idea about the flow. However, I let them explain the flow of the process and the connection between functions and files. Oftentimes, they think of a solution before I even understand what is happening. Many people have been so thankful for me — for doing literally, nothing.

Programmers understanding themselves

The Rubber Duck Method: What is the explanation behind this debugging approach?

You can see the same principle at work in the classroom. Teachers probing students with questions are intended to make sure a lesson has been learned, forcing the students to consider and explain it by themselves. The only difference is that a programmer using the Rubber Duck method is taking both roles (teacher and student) at once. 

In other words, this method allows developers to share their thoughts with a neutral party, questioning and probing themselves regarding their code, which can help identify areas of confusion or misunderstanding. And most importantly, it encourages developers to develop a clear and concise explanation of their code, which can be useful for future reference. 

The real magic doesn’t happen on the rubber duck itself (sorry, Duck Norris). However, it happens in our minds. It uses the same psychological principle wherein we are encouraged to explain to ourselves why we did such actions and have a self-realization about what we’ve done. It is usually used by most psychologists to fully understand a person and, at the same time, for the person to understand himself/herself fully.

And understanding yourself is fundamental to being a good programmer. Just like writing any other thing (a novel, or a sheet of music), everyone has their own style, approach, and technique when coding an application, which makes the ability to explain what you wrote so important; if you aren’t able to understand your process inside and out, then debugging will always be a challenge, especially when working as part of a team, where the code must always be in sync. In fact, the Rubber Duck method can be used as a form of collaboration, as another programmer can serve as your rubber duck and offer feedback or suggestions while you go through your code trying to find an answer.

When working on a software development project, it’s important to have a good collaboration method in place, and the rubber duck method is one way to ensure that everyone on the team is on the same page”, says Jesús Magaña, Senior Project Manager at Scio. It can help a developer to articulate his or her thought process, and as a result, team members can quickly identify any gaps in understanding and address them before they cause problems. Additionally, the rubber duck method can help to uncover errors in logic or coding syntax, and overall is an effective way to ensure that everyone on the team can contribute.

In a Nearshore development environment, where collaboration has come a long way in recent years, the Rubber Duck method can also be useful to bring keep everyone on the same page by improving communication, helping maintain contributions clear, and easing the challenge of solving a tough bug even in remote settings (where a developer may not have anyone to immediately bounce ideas or solutions during debugging), which can help projects to come together more easily. After all, Nearshore software development has its challenges, but by using the proper approach (or bath toy), teams can overcome obstacles and build better software together.

The Key Takeaways

  • A bug in the code is basically a mistake in communication between a developer and a computer.
  • Following this, it’s no wonder that approaches to problem-solving like the Rubber Duck method can help to find the precise place where a code is not working.
  • Although you only need something to talk to (like a rubber duck), this process can involve many people in a team, offering advice and feedback.
  • However, in remote setups (like with a Nearshore development partner), having a way to find and fix bugs without the insight of anyone else can be a valuable resource.

Scio is a Nearshore software development company based in Mexico where we believe that everyone deserves everyone should have the opportunity to work in an environment where they feel like a part of something. A place to excel and unlock their full potential which is the best approach to create a better world. We have been collaborating with US-based clients since 2003, solving challenging programming puzzles, and in the process showcasing the skills of Latin American Engineers. Want to be part of Scio? Get in contact today!

Maintaining Productivity: Is the Pomodoro Technique for you?

Maintaining Productivity: Is the Pomodoro Technique for you?

Curated by: Sergio A. Martínez

One of the main challenges for software developers everywhere is maintaining a high level of productivity throughout the day. No matter the size of the project, or how interesting the final result may be, it will involve hours coding away, looking at a screen, trying to stave off distractions, and keeping engaged long enough to accomplish a good outcome at every stage of production. And that can be difficult.

Maintaining Productivity: Is the Pomodoro Technique for you?

We have talked before about ways to make the most out of your workday here at Scio because we understand the importance of this focus and engagement, and today we want to dive into a popular technique that promises to effectively manage your productivity, allowing you to finish all the tasks involved in that sprint currently closing on you: the Pomodoro Technique. Have you heard about it? Has it helped you? What’s your take? Let’s dig into it and find out!

The key to productivity in software development


There are several ways to increase productivity when working on software development projects. First and foremost, it’s important to have a clear understanding of the project requirements to focus your efforts in the right place and avoid wasting time. Secondly, use tools and processes that are designed to improve efficiency; many software development tools already include features that can help automate repetitive tasks. And finally, take regular breaks to avoid burnout; by giving yourself some time to rest and recharge, you will be able to come back to your work with fresh energy and ideas. This is where the Pomodoro Technique comes in.

We know the software development process can be a long and complex one, often involving multiple team members working on different parts of the project at the same time, which makes it difficult to stay focused and ensure that each task is completed efficiently. The Pomodoro Technique, which breaks down work into short intervals followed by breaks, allows developers to take on small tasks and then rest for a bit before starting the next one, preventing them from getting overwhelmed or bogged down in a single task. 

The beauty of the Pomodoro Technique is that it’s easy to get started and there’s no need for expensive tools or software. All you need is a timer and a way to keep track of your progress. The technique is effective in helping people focus and get work done, and it can also help to improve communication among team members, as developers can share their progress and discuss any challenges they are facing more frequently. As a result, this technique has become a popular tool for software development teams looking to improve their productivity.

How does it work?


The Pomodoro Technique was devised by Francesco Cirillo as a University student in Germany, when he used a tomato-shaped timer to break his work into intervals, allowing him to keep a productive rhythm throughout the day. The basic technique follows these steps:

Before starting

  1. Determine the amount of work that you will need to do.
  2. Deal with any possible interruptions before starting (like emails, phone calls, meetings, or if you are at home, unexpected visits or deliveries).
  3. Make a schedule and set deadlines to finish, to calculate the number of Pomodoros you will need.
  4. Make a list of the tasks you will be tackling in this session.

During the Pomodoro

  1. Choose a task.
  2. Put your timer to 25 minutes and start.
  3. When it is done, take a break of 5 minutes.
  4. Repeat.
  5. After four 25-minute sessions, take a longer break of 20 minutes.

After finishing

    1. Record in a notebook (or something similar) how much you accomplished this session. 
    2. After you compile a good amount of data on your rhythm, start comparing it and note where you are getting stuck.

There isn’t much beyond this, which is the genius of the Pomodoro Technique; it only requires a timer and the willingness to keep records of everything that’s happening, to improve your efficiency constantly, which is why Jesús Magaña, Senior Project Manager at Scio, who advocates for this method in most of the projects he collaborates on: 

It sounds very exaggerated to say you can only focus completely for about 25 minutes at a time, and some developers say that, when they get into the zone for hours, they can absolutely multitask, chat, watch videos, and work at the same time, but that’s just a simulation. You are not doing those things at once, but one thing after another, as interruptions. So, what Pomodoro does is organize your workflow so you can control your productivity better.”  

With such simple effectiveness, then, it’s easy to see why software developers are drawn to this method. Anyone who has ever worked in software knows that it can be a frustratingly difficult process, and part of the problem is that it’s very difficult to predict how long a given project will take. Even with careful planning, unforeseen complications can always arise and cause delays. 

In addition, software development is often an iterative process, with new features being added or existing ones being modified as the project progresses, which adds to the challenge of maintaining a consistent level of productivity. The relatively high cost of making changes to software once it has been completed can also lead to delays as developers are forced to make sure that each change is necessary, so it’s not surprising that the Pomodoro Technique has seen such a rise in popularity; it promises to keep a developer focused on making progress.

However, is the Pomodoro Technique the end-all of day-to-day productivity? Or are there some downsides we should keep in mind to ensure that it is implemented in the most effective way possible?

The challenges of an effective Pomodoro Technique


While a popular time management strategy, the Pomodoro Technique is not without challenges and downsides that any developer should be aware of to get the most out of it. In theory, it should help to increase focus and productivity, but it can be difficult to stick to the strict 25-minute/5-minute timeline, especially when you’re in the middle of a particularly challenging task, and the frequent breaks can end up disrupting a workflow, making it harder to get back into the zone, which is something that Jesús Magaña likes to address: 

There’s research going into people’s attention span, and 25 minutes is a consistent limit for it. So even if you are completely in “the zone” during the Pomodoro, it wasn’t going to last too long after the 25th-minute mark. The trick is getting yourself used to this length of time to accomplish something.

Of course, nothing stops you from adjusting the length of the Pomodoro according to your personal rhythm; after all, the point is finding a way to keep you engaged in the task without getting burned out in the process. A more personal, customized version of the Pomodoro Technique is the most common at Scio, where the developers implementing it are likely to have better results if they take away some of the rigidity of this system.

Another common criticism of the Pomodoro Technique is that, even if it helps you go through the tasks of the day with no problem, it can be disruptive on a team to have everyone working at different speeds and taking mini breaks at different times. Does the Pomodoro Technique promote or hinder teamwork?

There are some advantages to using the Pomodoro Technique in a team setting; for one, it can help to prevent scope creep by keeping individual tasks focused and manageable, keeping team members on schedule by holding everyone accountable to the same timeline. However, there are also some potential drawbacks, like fragmenting the team’s work or making it difficult to collaborate on complex tasks. Additionally, the Pomodoro Technique relies heavily on individual motivation and discipline, which may not be evenly distributed among team members. Ultimately, whether or not this technique is beneficial for teamwork depends on the specific team dynamics and goals. There is no one-size-fits-all solution for this, so strong management of the project is required to make it work as it should.

Final thoughts

Regarding software development, the Pomodoro Technique is a powerful tool to increase your daily productivity, keep deadlines under control, and help developers make progress every day. And while it has some important downsides to keep in mind, as a solution to daily distractions, it can get the job done. With all that said, we can extract the following key takeaways from it:

  • Keeping your daily productivity can be hard depending on the project and its requirements, but there are a lot of methods out there to help you with that.
  • The Pomodoro Technique is the most widely used, thanks to its low-tech approach and simplicity to keep a working rhythm.
  • However, the rigidity of this technique is not for everyone, but nothing stops you from fine-tuning it to your personal preferences. 
  • Also, it can be counterproductive to teamwork, so having a solid direction and management during the development cycle is critical for a successful implementation of the Pomodoro Technique.

Scio is a Nearshore software development company based in Mexico where we believe that everyone deserves everyone should have the opportunity to work in an environment where they feel like a part of something. A place to excel and unlock their full potential which is the best approach to create a better world. We have been collaborating with US-based clients since 2003, solving challenging programming puzzles, and in the process showcasing the skills of Latin American Engineers. Want to be part of Scio? Get in contact today!