«Collaboration is at the heart of everything we do here”, or how Scio creates a culture where everyone matters.

«Collaboration is at the heart of everything we do here”, or how Scio creates a culture where everyone matters.

Nearshore, Outsourced Engineering Team, Scio

Curated by: Sergio A. Martínez

The world has changed dramatically in the past few years and it’s no surprise that our idea of what employees want and need have gone through a revolution of sorts. In comparison to 10 years ago, today’s professionals seem to value collaboration over competition, so organizations need to foster an environment that encourages idea-sharing rather than individual recognition, and employees have made tremendous strides in terms of skill development and career advancement.

The-evolution-of-employee-icono

Furthermore, today’s workforce is composed of a much more diverse demographic than a couple of decades ago, enabling companies to benefit from a variety of new perspectives and experiences. Communication skills have also grown exponentially, with employees adopting more open lines of communication with one another, making it easier to collaborate on projects. We’ve also seen a shift toward flexible working arrangements as employees become aware of the many benefits such arrangements offer for both productivity and personal satisfaction. In other words, the evolution of today’s workplace has been pretty dramatic over the last two decades.

As a result, the workplace is changing quickly, and it’s been evident over the last two decades, with a shift towards self-motivation, where employees increasingly take personal responsibility for their personal development and career growth, resulting in employees more open to the idea of moving around between different companies to find the best roles for them. 

And that’s without mentioning how many jobs that existed 10 years ago look very different today due to the development of new technology including automated systems or tools that can facilitate work processes. Additionally, there is an ever-increasing focus on employee well-being, so companies are more deliberate in creating an environment with ample opportunity to disconnect from work when needed. Corporate culture has shifted as well; these days it is much more focused on creativity and innovation rather than working 9-5 to get things done. All of these changes demonstrate that employees have certainly evolved over the past two decades – a trend that will most likely continue into the future.

And this evolution of the employee and the corporate culture around it, play a big part in how Scio works today. We sat down with Helen Matamoros, our Head of Human Capital, to discuss how a developer today has evolved dramatically in the last decade, how this shapes corporate culture (and vice versa), and where this evolution might lead us in the future. Let’s dig right into it!

An evolution of perspective

The evolution of employee 3

One of the most interesting aspects of this evolution can be found in the contrasts between a Senior and a Junior Developer. Outside the office, Senior Developers generally looked for a better work-life balance, often prioritizing it both in terms of career and home life over the years. A Junior Developer, on the other hand, commonly used to take on extra hours, struggles with making time for socializing, and worries about precarious employment due to lack of experience. But today, the reality looks very different.

“Back when I started at Scio, in 2007 or so, we usually looked for more Senior staff due to the nature of the projects we did for our clients. We used .NET almost exclusively, so this kind of wide experience was needed, so many of our collaborators back then were 30+ people who already were starting families and generally expecting more stability and better remuneration from their jobs, which guided a lot of what we did back then, culturally speaking”, explains Helen about how expectations have shifted in the last decade and a half. “But as the variety of tools and frameworks have increased, we can have more variety in the amount of experience a Scioneer can have, and what we can offer to them.”

So when it came to finding the perfect fit for a career, Senior developers preferred stability and long-term growth over more immediate gratification, which could mean taking on a job that offers consistent work rather than something short-term with potentially higher pay but little security or potential for advancement, so it’s understandable why finding such an opportunity would be very important.

However, as this shift in technology happened, so did Scio’s approach to what kind of culture we fostered also changed. Developers with less experience but great technical skills became more of the norm for many projects, with Scio offering lots of training, courses, and workshops to help these developers to grow and thrive. After all, supporting the growth and development of junior and mid-level developers is a win-win situation for software companies. 

Not only does it provide a wealth of knowledge gained from experienced staff to employees at various career stages but offering developer training can help foster individual development plans, creating an attractive working environment, which is what the best software companies strive for, and in turn, makes them attractive for any prospective developer.

“Another interesting shift I noticed in the last 15 years or so at Scio, is how developers have also changed in attitude, leaving behind the “nerdy” stereotype we still see everywhere, giving more importance to the soft skill side of things”, says Helen, which is something we have commented before at our blog. “Obviously, we have a wide variety of personalities and personal stories at Scio, but we have noticed a certain openness to socialize and mingle together that wasn’t here a decade ago. And that’s something we try to encourage among our developers because collaboration is at the heart of everything we do here. We like to work with people who understand the value of teamwork, and that’s always the first filter we apply when looking for new developers.”

Building our culture across borders

The evolution of the employee 2

Unlike traditional corporate cultures, this new approach is putting each employee’s creativity and expertise on display to achieve the best possible results for the organization. A collaborative environment encourages communication, team building, and the integration of diverse perspectives, which leads to more innovative ideas, better problem-solving capabilities, and more efficient processes. 

Even with limited resources and tight timelines, a collaborative corporate culture can help shape an ambitious yet achievable vision as well as efficiently realize that vision. Furthermore, when every team member knows that their knowledge could be valuable to others in the organization, they tend to take more ownership of their work and be more engaged in their role within the company. Having a collaborative corporate culture is an essential element for achieving success in any software development organization.

“Of course, as a Nearshore development company, Scio has a hybrid remote/in-person approach where collaboration is fundamental to reaching our goals. We have employees who can often come to our offices in Morelia, but plenty more elsewhere in Mexico and the rest of Latin America who can’t do face-to-face interaction”, explains Helen about the challenges of a good corporate culture in the age of remote work. “After all we, as people, like to feel part of a whole, knowing that our work matters and how it fits into the bigger picture. So we make the effort to create the kinds of connections that make you feel part of Scio, even if you are working at home. As I mentioned, developers today seem to be more open to the idea of socializing and treating this as more than a job, even with healthy boundaries between their personal and professional lives, so we, as an organization, have a responsibility to encourage this. It always leads to better results for everyone.” 

That’s why, when it comes to software development, having a closer bond between employees at a mid-sized company like Scio can make a world of difference. Employees with close ties also have an increased sense of responsibility, since they know that their actions will affect the entire team and not just themselves. This level of trust is essential for any successful software project, as developers need to understand each other’s processes and expectations to collaborate efficiently. Additionally, organizations benefit from closer relationships between staff because certain types of feedback can be handled more sensitively within a team setting than on a larger scale. 

Altogether, it’s clear that having a collaborative corporate culture is an essential element for achieving success in any software development organization. By fostering collaboration among its employees and giving them the freedom to explore creative solutions together, a software development company like Scio can use a collaborative corporate culture as a key tool for success, in both our projects and among our developers in their personal growth.

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!. Get in contact today!

Hiring a software development team?: Red flags to watch out for when working Nearshore

Hiring a software development team?: Red flags to watch out for when working Nearshore

Nearshore, Outsourced Engineering Team

Curated by: Sergio A. Martínez

Opting to collaborate with a Nearshore development team is always a great idea, allowing your organization to reach a talented pool of developers within the same time zone, and whose expertise is ready to help you reach your best possible outcome without sacrificing communication or compromising quality in any way. Latin America, for example, boasts some of the more skilled and knowledgeable developers in the world, so for any US-based company that wants to augment their dev teams, a Nearshore is the best solution.

Hiring-a-software-development-team-Red-flags-icono

However, how to make sure you are choosing the best company to work with? Are there any red flags that your organization should watch out for before making a decision that will make or break your project? As it happens, when you’re looking to hire a software development company, there are a few warning signs that you should be aware of, in order to guarantee that you are choosing the correct Nearshore company or team to collaborate with. So, when approaching a potential partner, ask yourself…

1. What does their online presence look like?

It’s no secret that first impressions are important; when you meet someone for the first time, you form an impression of them based on their appearance, their demeanor, and the way they carry themselves. The same is true for businesses. 

 When you’re considering working with any development company, one of the first things you’ll do is research them online. Their website, their social media presence, and the way they communicate with potential clients all play a role in shaping your opinion of them. And in today’s competitive market, it’s more important than ever for software development companies to make a good impression online. A well-designed website and active social media accounts show that a company is modern, relevant, and engaged with its potential clients, as well as showing that the company is serious about its business and that it has the resources to invest in its online presence. By contrast, a company with a poorly designed website or no social media presence sends the message that, at best, it’s out of touch with the realities of modern businesses. First impressions still matter, so always be wary of any company that doesn’t seem to care about their online look.

2. Other people’s opinions are always useful

If you’re thinking about hiring an external development team, it’s always a good idea to get some input from other people. After all, you want to make sure that you’re making the best possible decision, and there are a few different ways to go about this. You can ask people you know who have used Nearshore software development companies in the past for their recommendations or read online reviews and testimonials to get a sense of what other people’s experiences have been like. You can even reach out to the companies themselves and ask for references. By taking the time to do your research, you’ll be much more likely to end up working with a company that’s a good fit for your needs.

3. Look closely at their business processes

Going Nearshore is a big decision. You want to find a company that will be able to meet your needs and deliver on its promises, so pay attention to these warning signs and you’ll be more likely to hire a great software development company. With a clear understanding of what you’re getting offered, you can feel confident that you’re making the best choice for your business:

  • Fixed-bid pricing. With an external software development company, there are a few different pricing models to consider. One of the most popular options is fixed bid pricing. This model means that the company quotes a single price for the entire project, regardless of how long it actually takes to complete, which may seem like a good deal at first glance but has some potential drawbacks to be aware of. First of all, fixed bid pricing can incentivize companies to lowball their initial quote in order to win your business, and as a result, you may end up paying more in the long run as the company tries to make up for their mistake. Additionally, fixed bid pricing can lead to scope creep when a company tries to add extra features or requirements that were not originally included in the project, leading to higher costs and delays. In general, it’s best to avoid fixed bid pricing when choosing a software development partner, instead negotiating an hourly, monthly, or even yearly rate so that you can be sure you’re getting what you pay for.

  • Suspicious estimates. Accurate estimates are important. A good estimate will give you a realistic idea of what to expect in terms of cost, timeline, and scope. It will also help you identify any potential risks during development, so this information is essential in making an informed decision. Therefore, when you’re talking to a potential software development company, be sure to ask lots of questions about their process and their experience; if they can’t give you straight answers, that’s another red flag, and too good to be true estimates are cause for concern, as they often lead to cost overruns and schedule delays. When reviewing estimates, always ask for clarification if anything seems unrealistic.

  • Unclear (or absent) feedback loops. Software development is a complex and error-prone process. Even with the best planning and management, things can go wrong, which is why a feedback loop is an important part of any development process, and critical when working with an external team. Without a clear feedback loop in place, it can be difficult to manage expectations, track progress, and identify potential problems. In addition, a feedback loop helps to create a sense of accountability and ensures that issues are addressed promptly. As a result, taking the time to establish a clear feedback loop process with your external partner is always worth the investment, and if the company doesn’t have a clear and established process to receive and implement it into the project, a negative outcome is all but guaranteed at the end.

Nearshore the right way

Nearshore the right way

“In Nearshore development, working with the right company is essential to guarantee the best outcome. The collaboration and communication between the client and the development team are critical, as well as the skills and expertise to meet your specific needs”, explains Luis Aburto, CEO and Co-Founder of Scio. “In addition, the right Nearshore development company will have a deep understanding of the local market, which is essential for success. With the right partner, you can be confident that your development project will always reach your goals.”

So, when it comes to Nearshore software development, working with the right partner ensures a successful outcome if you look for the right “green flags” that a good Nearshore development company offers, guaranteeing the best result:

  • First, collaboration is key. A good partner should work closely with you to understand your specific needs and goals, and then develop a customized plan to ensure that those needs are met. Collaboration ensures that everyone is on the same page and that the final product meets your expectations.
  • Second, communication is key. The right company will keep you up to date on the project’s progress and address any concerns you may have along the way, understanding that effective communication is essential to maintaining a good working relationship.
  • Finally, skill is key. A Nearshore company looking to improve your project will have a team of skilled professionals who are experts in their field. They’ll be able to handle every aspect of the project, from start to finish, ensuring a high-quality final product.

In short, while there is no definitive answer to choosing the right software development partner, due diligence and being wary of companies that make unrealistic promises, seem unprofessional or secretive, or do not have a good reputation in the industry is still the best strategy. By keeping an eye out for these warning signs, you can find the right partner to help you achieve your business goals, choosing a company that has the experience, communicates effectively, and has the best-skilled professionals. Doing so will always guarantee the best outcome for your project.

The Key Takeaways

  • Nearshore augmentation is the best solution if you want to ensure your project has all the talent, skill, and collaboration necessary to make it a success.
  • There are many options out there, so knowing how to look for red flags when choosing a partner is critical to ensure success.
  • Among those red flags, getting unrealistic promises, unclear business practices and a lacking online presence are always indicators of a dubious partner in development.
  • On the other hand, a transparent company with clear communication and collaboration processes like the ones Scio offers can guarantee a smooth development experience, and thus, the positive outcome your organization is seeking.

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

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?

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?

Ghost-Colleagues

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!

Good Test Case design in QA: Quality at every step of the process

Good Test Case design in QA: Quality at every step of the process

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. 

Test-Cases-1

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

Test-Cases-3

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.”

The Key Takeaways

  • 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!

The Flexibility of Nearshore Development

The Flexibility of Nearshore Development

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.

The Flexibility of Nearshore Development

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!

Mythbusting: Are introverts better programmers?

Mythbusting: Are introverts better programmers?

Entrepreneurship, Outsourced Engineering Team

There aren’t many professions without a stereotype attached, and programming is sure among them. But are these ideas about the personality of programmers accurate, or are we missing something else? Let’s look into these old myths, and see if they hold up. 

By Scio Team

When we think about programming and software, we tend to conjure a specific image in our minds, a stereotype that has accompanied the profession almost since the beginning: the image of a coder hacking away at the keyboard, immersed in a world of their own, without the need of much company. 

However, if this was true at some point, it still is? The stereotype of the introverted programmer is an even mix of fact and myth, and here at Scio, where we know perfectly the talent we work with, we want to shed some light on the reality of people applying a special skill to create software.

Is it possible to profile a personality?

Since the days of the classic “Temperament Theory”, which tried to divide people into 4 distinct types (namely: Sanguine, Choleric, Melancholic, and Phlegmatic, which are pretty weird classifications if we are being honest), people had the impulse to try and understand their personalities, where they come from and how they affect their everyday lives.

More scientific approaches to these questions have evolved from the 20th century onwards, and today we understand that personality, affinities, and preferences are more fluid and flexible than we once thought, even if we simplify the whole idea for the sake of practicality.

The Myers-Briggs Type Indicator nowadays is one of the most popular systems to tackle this subject, going more in-depth on the inner workings of a person instead of just focusing on their outward behavior.

Going back to the idea of programmers as introverts, things like the MBTI bring some very interesting insights about this professional field and the people who feel compelled to it. What can we find there?

Mythbusting: Are introverts better programmers?

Let’s define “introversion”

What you need to know right now, is that the “introvert/extrovert” dichotomy is a little outdated, simplifying a vast swath of personality types into two neat boxes with little in-between. What the definition of “introversion” tries to convey under this understanding, is people who don’t have much affinity for a specific kind of social interactions, preferring more individual activities, or with a pretty select group of people. 

Although many probably feel this way, reducing it to only these signifiers leaves a lot out. What the Myer-Briggs does is check the balance between the following:

  • Extraversion (E) versus introversion (I)
  • Sensing (S) versus intuition (N)
  • Thinking (T) versus feeling (F)
  • Judging (J) versus perceiving (P)

What this system maps out is the preference of the person, rather than the ability, so the metrics here assign percentages based on what a person would prefer to do in a given situation, ending up with a combination of 4 letters based on their highest percentages, like INTP or ESTJ. Please take note of the use of the word “extraversion” instead of “extroversion”, which will be important in a minute.

There are pros and cons to this approach, but the important part here is that we have a lot of historical data to see what large swathes of the population prefer, and in programming, the results are pretty interesting overall, challenging many of our notions about the “introvert coder” stereotype.

So… are programmers introverted or not?

We are getting there. First of all, since we are looking into preference instead of abilities, it’s important to note that certain groups, as a whole, will pick one instead of the other; it’s a decision (even if a subconscious one) instead of instinct, or impulse. For programmers, this preference goes towards Thinking (T) instead of Feeling (F), meaning that they like to analyze situations from a more objective point of view, not giving as much consideration to the emotional side of things

Now, this doesn’t mean they only do one of these things. It means that when compelled to act, people will feel more comfortable with a single approach, so if we look at coding, programming, or engineering (where you see lots of interconnected mechanisms balanced between “needs” and “wants”) people prefer Thinking (T) will be better at it. This post, titled “Does being an introvert make you a better coder?” puts it nicely:

“A typical software developer likes there to be a logical consistency behind a decision. It might not matter much what that consistency is, so long as it’s there. By contrast, other people prefer the ‘feel’ of the situation, using empathy and imagining what it is like more from other people’s point of view. In other words, there is a difference between coders and others, in how they tend to justify a decision.”

And as you can see, this has nothing to do with social preferences, or the ability to relate to people in any situation. That’s why this profiling system uses the word “extraversion”, referring to “the world of action, people, and things”, in contrast with “introversion”, or the world of ideas and reflection, both useful for doing complex things such as programming software.

“MBTI introverts prefer fewer, deeper, and more involved interactions with people, whereas extraverts prefer shorter and more frequent interaction. For getting to know users quickly, extraversion can be an advantage, but introverts are perfectly good at deep social interaction”, goes the cited blog. And it’s true; avoiding people has little to do with introversion, and the stereotype comes from misunderstanding what these words try to convey.

An alternative definition of the “introverted programmer”

So, to wrap things up, where does this leave the myth? As we said, maybe at some point in the past, before the development of agile methodologies or the normalization of a remote model of working, the stereotype of the “introverted programmer” was true and functional, but it no longer works that way.

People are more complicated than many of these systems will tell you, and lots of different preferences and abilities are desirable in any well-balanced team. What is true in the age of remote work, though, is that knowing how to interact and communicate well with your coworkers, clients, and managers at a distance are going to be a very valuable skill moving forward, and this has nothing to do with how one approaches the challenges of programming.

So we can leave behind all that and start thinking of the people best adapted to the work of programming in a different way; is no longer an introverted programmer, but a thinking one, whose intuition and affinity for code can be supplemented in a great way by social understanding and the clear communication that only the best Nearshore companies can offer.