by Scio Team | Sep 2, 2022 | Nearshore, Outsourced Engineering Team, Project Management, Software Development
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?
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
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.
- 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!
by Scio Team | Aug 26, 2022 | Outsourced Engineering Team, Product Development, Scio, Software Development, Technologies
Curated by: Sergio A. Martínez
Creating software can be compared to solving a big, complex puzzle. A developer needs to take a bunch of pieces (code, algorithms, requirements, deadlines, etc.) and put them together in the right way to create a functioning product that satisfies everyone involved, from clients to final users. And just like with a puzzle, there is no single “right” way to develop software; it depends on the individual developer’s preferences and style, where some may start by laying out all of the pieces and looking for patterns, while others may start assembling pieces and then adjust as they go along.
And the biggest challenge is that if even one piece is out of place, it can throw the entire system off balance. This is why, besides having a good team of developers able to see the big picture and break it down into manageable tasks, a good QA Tester is so critical to obtaining the best possible outcome during development. Only then can you hope to create a successful piece of programming.
That’s why having a good approach to QA is so important; having experienced testers whose toolset matches the requirements of the product, capable of coming up with a plan for how they will test the code as they write it, as well as having a deep understanding of what “quality” means for the project, is a must in any team.
So, in that sense, we want to take a look into one of the most important processes of QA: test cases. Because beyond running automated tests and manual testing, QA involves a systematic approach where developers can avoid costly mistakes and create products that meet customer expectations. And in practice, how can you design the perfect test case? What considerations should you have, and what’s the best approach to document and keep track of the sometimes messy process of QA?
Test cases are simple: Just think of everything
When it comes to software development, well-designed test cases are essential. By carefully planning out each test case, developers can ensure that their code will be thoroughly tested for errors, and taking the time to design comprehensive test cases can save a lot of time and effort in the long run. But how should you approach this task in practice? Is there a trick to designing a good Test Case?
“It depends on the project”, says Angie Lobato, a Quality Assurance Analyst at Scio with a wide range of expertise in everything QA. “The ISTQB already mentions that 100% thorough testing is not something that is possible, so it comes down to the priorities of the team, the requirements, the severity of the bugs, and the timelines set to deliver the product, as well as how much time the person in charge of QA has.”
This is why knowing how to design a test case is so important; considering all the challenges that software development already faces, being able to write an efficient, timely, and thorough test case is a valuable skill, keeping in mind things like…
- Thinking about the expected behavior of the system under test. What should it do in various scenarios?
- Choosing input values that will exercise all relevant parts of the system.
- Designing tests that will detect errors, but also verify that the system behaves as expected.
- Keeping track of all tests performed, including pass/fail status and any observations made.
However, saying this is easier said than done; it can be difficult to create comprehensive test cases that cover all possible scenarios, and as software becomes more complex, replicating customer environments to test for all potential issues requires some intuition and minute attention to detail. That’s why the design of your test cases has to start with a script as the basis of the test, documented and shared to see exactly what you are trying to accomplish. For this process, Angie tells us that…
“I first need to validate that the Test Case (TC) related to the specific item I’m checking doesn’t exist yet, and do whatever is necessary, like adding, taking out or updating steps to not end up with a suite of repeated test cases”, she explains. “To design the script, it’s always good to create them in their respective suite, with a link to the requirement so everybody in the team can easily find them (I’ve personally used TFS, Azure DevOps, and Jira) depending on the tools utilized during the project. For the script itself, I define the objective of the Test Case, as well as the preconditions and postconditions it needs. Once that has been taken care of, I start to retrace the steps necessary to reach the item I need to test. I add each needed step to achieve the objectives of the test case with their expected result, and finally, I validate the final results where the change needed to be reflected.”
As you can see, there’s a lot of documentation involved in designing a test case, and having the proper formats to keep everything in order (like this one) helps to make sure that each test is accomplishing what it needs to. And according to Angie, a good test case needs a couple of characteristics to make it good:
- A good test case has a clear objective stated and is updated to the latest version of the project.
- Has all the necessary testing data to execute it without creating repeated information.
- Has defined all the preconditions and postconditions of the product.
- And most importantly, don’t try to test more than one thing in a single case.
- However, if you need to, changing the parameters of the test is necessary to make that clear.
- An ideal test case shouldn’t have more than 10 steps in total.
Ensuring quality at a distance
As anyone who has ever been involved in software development knows, QA is a critical part of the process, and a good test case can help to ensure that the final product meets the requirements of the customer and is free of issues, especially in the current development landscape where remote collaboration is becoming a given.
For a Nearshore development team like the ones at Scio, a well-crafted, carefully designed test case is invaluable, helping to ensure that the team and the client is on the same page concerning the expected results of the testing process, and providing a clear and concise way to communicate those expectations to everyone involved.
In other words, a good test case can help to streamline the testing process and make it more efficient, so taking the time to create a good test case is well worth the effort for any remote software development team.
“Any company that outsources software development knows that collaboration is key to success. A good QA team is essential to ensuring that the final product meets the standards”, says Adolfo Cruz, PMO Director, and Partner at Scio. “In a Nearshore setting, they are especially beneficial because they ensure that any problems are found and fixed quickly before they have a chance to cause major problems. As a result, well-designed test cases play a vital role in ensuring the success of a remote relationship.”
- Quality is necessary at every step of the process of developing software, not only a concern in the final product.
- A good example is test cases, how important they are to the process of QA, and what good practices get involved in designing one.
- A well-designed test case is straight to the point, meticulous, and tries to think of all the context around the product in order to ensure the best quality possible.
- Also, the process of designing a good test case is doubly important when working on a project remotely, helping keep everyone on the same page and track all the changes and corrections necessary to bring the best possible outcome.
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!
by Scio Team | Apr 26, 2022 | Outsourced Engineering Team, Successful Outsourcing
By Scio Team
The way we conceptualize work is changing, first as a result of the pandemic, and second as a result of technology letting us do something unthinkable a mere five years ago. The result is a landscape where a lot of organizations are more willing than ever to adapt to their collaborators, offering ways to work that strike a better balance between their personal and professional lives.
However, what does this balance mean? Because the more we think about changing our actual practices, the more challenges and conundrums appear in the need of a solution. And the software industry, as one of the leaders in this evolution of the workplace, is experimenting with ideas more than ever to hit the specific balance between work, personal life, and the needs of a given project.
A right to disconnect
A lot of buzzes were heard when France, back in 2018, began to implement the so-called “Right to Disconnect”, a legal framework aimed at protecting workers from retaliation if they choose to not attend calls after their shifts. As proposed, this regulation showed that “work” as we knew it was starting to evolve, as more and more tasks in a company started to need a kind of specialization that sometimes could not be accomplished in the traditional 9-5 office hours.
This fostered a culture of being “always-on”, which could not be healthy or sustainable at all in the long run. After all, a good outcome for any project could come from an exhausted team that always had to be ready and reachable? The Right To Disconnect tried to solve this, with mixed results.
“We have our best ideas in unexpected places, at unexpected times. Excelling in today’s economy thus demands short bursts of intensive thought followed by seemingly unproductive – yet necessary – lulls. Nourishing such approaches requires workplace flexibility, not regulatory rigidity; depriving skilled professionals of these practices by telling them exactly when and how to work also deprives them of potential opportunities to create value”, says this article by the non-profit policy research organization R Street.
So, even if the intent of these legal frameworks is desirable and necessary, it could be argued that they also fail to solve many of the intricacies of working in industries like software, where different dynamics are at play. Programming, for example, is as much of creative activity as it is a technical one, trying to solve complex puzzles as efficiently and elegantly as possible in a given timeframe.
This means that, even if everyone obviously needs time to rest and relax, the idea of rigid boundaries to solve a programming challenge during a project is closer to the idea of “mandatory fun” than keeping a healthy boundary, with some companies even going as far as disabling emails and chat programs to ensure their workers comply.
“While some procedures, like taking the email server offline, will help to ensure that all employees are on equal footing, this approach may have unintended adverse consequences on employees with flexible work arrangements. Many caregivers, for instance, handle family responsibilities during the day and resume work after hours. IT departments will need to navigate these issues with human resources and user departments”, claims the HR blog First Reference in this article.
This same quote, however, points out a solution that can keep boundaries clear, without enforcing a total disconnect that can result in counterproductive outcomes: flexibility. As the pandemic rages on, and we rethink what work is, the idea of flexibility starts to become more than choosing to work from home or going to the office on a given day; is the ability, up to a point, to set our schedules, our times, or to select to collaborate with an organization that closely aligns with ourselves.
We’re here for you
Thanks to the rise of remote work, the possibility of working with clients abroad in tech hubs like Silicon Valley and Austin without having to lose boundaries or sleep is closer than ever thanks to Nearshore development companies like Scio. But what distinguishes a Nearshore, exactly?
Nearshore companies are getting popular lately, and it’s easy to see why: the whole idea is to offer outsourced development services within the time zone that matches the clients as closely as possible. Being located in Mexico, Scio works mainly with clients based in the US, collaborating with tech firms on projects with all kinds of challenges to solve, without needing the odd working hours that might result from working with a client in Europe or Asia.
This results in a close collaboration that still leaves room for boundaries, as the working hours of the team and the clients are the same; in fact, the schedules offered by Scio make sure there’s overlap in the middle of the day while leaving every developer to choose when to begin and stop working.
“Some of our clients realized that their developers not only can come from Wisconsin, Wyoming or Missouri; they are finding an enormous amount of talent available in Mexico and other LATAM countries that have no problem whatsoever connecting remotely to collaborate”,
“We can see that in our more recent applicants, who value these opportunities and are more than ready to join from anywhere in the world. Our focus is on certain time zones that are not too far apart from our clients, but Latin America as a whole has opened as a software development possibility like never before.”
Tells Rodimiro Aburto, Service Delivery Manager at Scio.
This results in the possibility of expanding the scope of things you develop and learn from, while still maintaining real-time communication with clients in other countries entirely, and without having to adjust your working hours to maintain the same boundaries you are used to, because of the idea of a Nearshore company is to offer convenience in collaboration and communication for both clients and developers, giving you the space to work as you feel best, while maintaining the excellence in outcomes that’s expected in these projects.
“So, what Nearshore comes to offer is the flexibility in which a Development Lead can chat in real-time with a collaborator in Mexico, Chile, Argentina, or Honduras, for example, as a full member of their team while keeping the healthy boundaries in hours that having the same time zone brings”, finishes Rodimiro.
We hope that this article has helped to introduce you to the possibilities of Nearshore outsourcing and shown you how Scio can provide a valuable solution for your business needs. Our team is passionate about creating healthy boundaries for our collaborators while still providing the flexibility needed in the modern workplace. If you are interested in learning more, please send us a message. We would be happy to discuss our services with you and answer any questions you may have. Thank you for taking the time to read our article!