The Great Resignation and the future of corporate cultures: Rebuilding a better software industry for all

The Great Resignation and the future of corporate cultures: Rebuilding a better software industry for all

Outsourced Engineering Team, Product Development, Project Management

Curated by: Sergio A. Martínez

The events at the beginning of 2021 set ablaze a revolution across the corporate world like never before. Companies that were once dormant in their response to messages from employees and people impacted by their decisions woke up with a start, quickly realizing that the rise of Great Resignation had an impact on more than just the individuals that left; it prompted corporate culture to shift within different organizations and led to an evaluation from both leadership and followers alike. Furthermore, it changed people’s ideas about where power truly lies and how one opinion can shape a large organization’s future.

The Great Resignation and the future of corporate cultures: Rebuilding a better software industry for all

After all, its aftermath has done a remarkable job of putting corporate culture in perspective. Gone are the days when tradition and status were the only things that mattered, and staff felt stifled by top-down approaches to decision-making. Today’s corporations devote much more effort to nurturing an atmosphere of collaboration, inclusion, and meaningful work experiences by leveraging modern communication technology and encouraging personal development. The Great Resignation was a major event that undoubtedly left its mark on the corporate world, particularly in terms of expectations for staff morale and development. 

Companies have increased the focus on employee engagement, introducing initiatives like flexible working hours, health benefits, and team-building days to ensure their workforce is both productive and content with their situation. While there’s no denying that working in a big corporation can be challenging, today employees benefit from more attentive management and a much greater appreciation of their efforts.

A new perspective on work

The Great Resignation and the future of corporate cultures: Rebuilding a better software industry for all

The early 2020s in the software development industry will be remembered as a turning point that, arguably, was sorely needed. Many key engineers and developers decided to abruptly leave their companies, sometimes abandoning projects of enormous complexity, with significant economic repercussions that become the foundation for innovation in the cultural side of things. This undoubtedly caused strife for many businesses that had difficulty adapting to this new normality, shifting new technology and approaches that might change the industry for the better. And despite the initial turmoil, the long-term impact of these resignations may bring more stability than harm. By creating environments with a focus on job satisfaction, we can ensure employees are not simply productive but also happy with their positions. 

However, after the shocking impact of the Great Resignation, many companies still have found themselves scrambling to rebuild their corporate culture. Leaders have had to get creative when it comes to rebuilding trust, setting new boundaries, and planning for potential resiliency in the future, with many opting to invest in employee incentive programs that focus on building relationships, regular check-ins to make sure everyone feels heard and supported, and flexible work schedules that prioritize people over productivity.

This can be a daunting task, of course, but it’s also an opportunity to create something innovative and unique. The first step will be evaluating the processes and systems in place that created the need for such a large group of employees to leave, as they could indicate larger systemic problems, so the team should make sure to look at all possible root issues. From there, leadership needs to start discussing ways to incorporate improved communication between management and staff, diversity in hiring practices, feedback loops for employees, and goal alignment across teams into the new culture. And it’s important to bring everyone on board, from executives to frontline staff, to implement these new procedures and standards. Creating buy-in from every level sets companies up for success.

“After such a significant departure, it’s important to focus on fostering positive energy and morale in the remaining company staff. The Scio way of doing things has always included creating a welcoming atmosphere, as well as creating clear company protocols for respectful and open communication between superiors and subordinates”, says Helena Matamoros, of Human Capital at Scio. “A sense of trust needs to be established by keeping everyone informed about any changes that might come, and this is best done via regular meetings and feedback sessions where everyone has a voice. A good company culture knows the value of its people, and it gives them tools to create a dynamic where collaboration is at the front and center.” 

Having an open dialogue within the company and getting feedback from everyone on what kind of company culture would best fit the current business needs is a must. This should also include input from members of different levels within the organization — both executives and employees. From there, it is important to set expectations and be transparent when making changes, making sure that all employees understand how their roles fit into the new culture so they feel like their work contributes meaningfully to achieving the organizational goals. In other words, the goal is to create an environment where change is welcomed, not feared, providing a safe space for anyone who may have questions or suggestions as the transition process unfolds. If approached correctly, establishing this new culture can be a positive experience for everyone involved.

What will come next?

The Great Resignation and the future of corporate cultures: Rebuilding a better software industry for all

Ultimately, the effort should be invested in presenting your business as an inviting environment that encourages career growth and puts it front and center. If the staff feels encouraged to grow, it strengthens both themselves and the organization as a whole, because learning new skills can help people feel empowered and give them confidence when tackling new projects or ideas, contributing to a vibrant atmosphere of goodwill that helps drive innovation and business success.

The impact of the Great Resignation on the software development industry has been immense, and tech companies had to rapidly pivot and restructure to manage the mass exodus of talent. As a result, employers have had to get creative with their hiring strategies to find new developers, often having to look far beyond traditional sources like universities or job postings. This sudden shift in the way people approach jobs has allowed the software industry an opportune moment to reinvent itself and its culture, sure to keep evolving even after things settle down.

After the Great Resignation, companies need to focus on honest communication, respect for individual talent, and a conscious effort to foster diversity, taking an intentional stance toward embracing both creativity and collaboration in workplaces while allowing employees to perform their best work. Forward-thinking companies place a priority on creating an environment where everyone’s ideas are heard, everyone’s skills are valued and everyone feels valued, which leads to a stronger outcome each time. If the tools of technology can help propel business success, then it only makes sense that the cultural products of technology – collaboration, creativity, and diversity – must be at the core of that success as well. Only by doing this will the next step for software industry culture be one moving forward.

The Key Takeaways

  • Building a corporate culture that puts people first and foremost is already a complicated (but rewarding) task, as it leads to better outcomes in the development process.
  • However, rebuilding a culture after a massive shift (such as the Great Resignation) can be an even greater challenge because it involves getting back lost trust, and the need to leave certain practices behind.
  • This process should involve everyone in the company, and leadership should make the effort to keep a better balance between people and business.
  • Doing so can lead to a better software industry, with a more people-centric approach, that can only result in better innovations that benefit us all.

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!

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.

Product Development, Project Management, Software Development

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.

Why-will-platform-engineering-and-self-service-be-two-of-the-biggest-trends-in-2023-icono

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.

Product Development, Project Management

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.

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

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!

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!

Developing FinTech applications: A puzzle of high stakes and many pieces.

Developing FinTech applications: A puzzle of high stakes and many pieces.

Product Development, Technologies

Curated by: Sergio A. Martínez

When it comes to software development, the core principle of “Know Your Customer” is as important as ever; after all, you can’t develop a truly useful application without a deep understanding of your user base. And when it comes to the world of Financial Technology, this is especially true, as the stakes are higher, so to ensure safety in your product, there’s simply no substitute for due diligence. And by collaborating closely with our clients and understanding their unique risks, we at Scio can develop FinTech applications that are both useful and safe.

DevOpinions Is the Python language here to stay

“With FinTech apps constantly flooding the market, FinTech app design might seem like a pretty sweet and easy job to do. But, in reality, designing a FinTech app is probably one of the toughest jobs out there, as it carries a number of unique challenges that can significantly impact the efficiency and adoption of the final product. One such challenge is the “KYC” or “Know Your Customer” requirement that all financial services providers need to comply with”, explains the article “The pain of KYC in FinTech”.

In other words, developing financial software is a challenge that requires regulations and laws that avoid any serious issues for the user. It’s a puzzle of many pieces, and getting them to fit together can be a tricky situation, but when everything comes together, the result is a beautiful thing. So by taking the time to get to know your clients inside and out, you can develop a much better FinTech application that meets their needs and exceeds their expectations.

However, when it comes the time to expand your team, and choose to collaborate with a Nearshore partner like Scio, what are the challenges faced during the project by our teams, and what are the best ways to ensure the products we helped create are the best they can be, and guarantee that KYC checks are followed properly?

Keeping Your Compliance: The other meaning for “KYC”

Keeping Your Compliance: The other meaning for “KYC”

Very few industries have higher stakes than FinTech, and that’s a core belief that any team developing financial service software has to internalize down to instinct: money is no laughing matter. Be it transferring, keeping it, or doing important operations with it (such as insurance, or billing), regulations on money and banking are an issue taken seriously by all, both private and public organizations. This is, then, what poses the biggest challenges faced when developing FinTech products, summarized so well in the initialism “KYC”: Knowing Your Customers.

“KYC is a regulatory requirement for financial institutions. By law, they are obliged to verify the identities of their clients to prevent fraud and constrain the service access of users who don’t fulfill certain standards of credibility”, says the article Keep Your Compliance: The FinTech’s Guide to KYC. “But Know Your Customer policies are not just regulatory boundaries. They also act as competitive factors. KYC yields insightful data on one’s own services and customers.”

So mastering KYC is critical for any FinTech related-product, although it should be noted that this concept doesn’t establish a concrete set of guidelines, and different types of clients (from a single person to an entire corporation) may have different requirements for their projects, with varying levels of detail, based on the type of transaction needed from the application. This, in turn, can have an extra layer of complexity by building an application meant to work in different territories, each with its regulations, laws, and context, which means that profound knowledge of the financial sector is often required to successfully develop such products.

And although following KYC to achieve the best outcome in FinTech products is necessary for any successful project, the truth is that the costs of these procedures add up, with the average cost of a single KYC check between 13 and 130 dollars (depending on the personnel number, as well as the cost of the particular platform used to do the checks), and up to 25% of FinTech platforms abandoned it due to friction in the customer’s end, which can require a long process to verify one’s ID. 

This poses FinTech as a notoriously risky venture, where tight regulations, costs, and market demand for easy interaction that, nonetheless, also require a rigorous procedure to avoid issues like fraud and money laundering, so any organization attempting it is incentivized to look for any help that might alleviate development, and Nearshore development might hold an answer.

Nearshore and FinTech: Easier than you may think

Nearshore and FinTech: Easier than you may think

When it comes to software development, a FinTech company has options; either choosing to do everything in-house or looking to augment their team with the help of a Nearshore organization. There are pros and cons to both approaches, but it can be a particularly good option for FinTech companies, helping them access the expertise they need to build a successful product by working with a partner with a deep understanding of the financial sector, with the skills they need close by. 

Opting for team augmentation this way allows companies to tap into a larger pool of talent, or “Adding workforce the Nearshore way” in the words of Rod Aburto, Service Delivery Manager, and Co-Founder at Scio, ensuring that communication and progress overview is done in a timely and convenient manner. This ability to collaborate in real-time is another key advantage of Nearshore partnering, and critical to ensuring that KYC is followed, with the final product meeting all the requirements needed. 

Ultimately, there are many reasons why these partnerships are a good idea for FinTech companies, and the biggest one is that you can get the best of both worlds: someone who knows the ins and outs of the industry and can help you navigate the regulatory KYC landscape and also shares a passion for developing amazing software.

After all, FinTech companies are under constant pressure to release new features and products quickly, without compromising on quality or security, so to meet these demands, many firms are discovering that by expanding their team resources with a Nearshore organization, a Fintech company can access some expertise that might otherwise be unavailable, and in the case of the financial sector, the proximity between the US and LATAM means that companies like Scio already have a close understanding of all the culturally and legally relevant details that are so important for the correct implementation of KYC checks.

As a result, FinTech companies stay ahead of the competition, speeding up the development process, easing the costs of KYC in the project, and all in all, getting all the talent and expertise you need to develop FinTech applications. So if you’re looking to develop FinTech applications, don’t be afraid to reach out and collaborate with a Nearshore partner: with the right team in your corner, anything is possible.

The Key Takeaways

  • Although FinTech solutions are in high demand, developing applications for it is full of challenges and obstacles that need a critical eye.
  • One of the biggest is KYC, or Know Your Customer, which dictates plenty of the requirements of any software, platform, or app.
  • KYC can be costly, so most FinTech organizations need to proceed with development in an especially careful way, and seek the best support available. 
  • Nearshore development can offer plenty of solutions for the FinTech sector of the US, as the geographical, economic, and cultural proximity between North America and LATAM can ease many of the challenges of KYC.

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!

The significant impact of Green Coding on the environment: Is balanced software development possible?

The significant impact of Green Coding on the environment: Is balanced software development possible?

Product Development, Technologies

Curated by: Sergio A. Martínez

With the need to be more environmentally focused every day, we look at an approach to software development that can help our industry utilize its resources better and more efficiently: Green Coding.

With the need to be more environmentally-focused every day, we take a look at an approach to software development that can help our industry to utilize its resources better and more efficiently: Green Coding.

When it comes to good practices in software development, there’s more to it than just efficiency and delivery of results during every sprint; there’s also a lot to consider about the impact caused by the products we make, both for our clients, final users, and the world at large. 

After all, we all know that software development can be a resource-intensive process. First, it generally requires a significant amount of development time to create robust and efficient applications. And second, developing software often requires the use of multiple tools and technologies, which can add to the cost of development. However, beyond these normal cases of resource investment from any software development company, what many people don’t realize is that coding can have a significant impact on the environment. After all, software development has always been a complex and time-consuming process, but in recent years this process has come into sharp focus, as the effects of global warming (and the time we have left to mitigate its effects) have become more and more pressing. 

In the case of technology, the creation of new software often requires the use of powerful machines, which consume large amounts of energy, and generate considerable amounts of heat and noise, in addition to the involvement of dozens or even hundreds of software development tools, each of which has a footprint. As a result, the environmental impact of software development can be significant.

Fortunately, there are several ways to reduce the environmental impact of software development, like using more efficient development tools that consume less energy or developing software in collaboration with other developers, which can help to reduce the overall number of development tools in use. However, all this could be for naught if our approach to software development doesn’t include a responsible mindset, which is the origin of a new way to approach the creation of new applications: Green Coding.

Green Coding: Efficiency in balance

The significant impact of Green Coding on the environment Is balanced software development possible

By taking these steps, developers can help to protect the environment while still creating high-quality software products, which is why more and more companies are adopting “Green Coding” practices. Green Coding is all about developing software in a way that minimizes its environmental impact, and that means anything from using energy-efficient hardware to writing code that is easier to recycle or reuse.

There are a lot of reasons why green coding is becoming a necessary practice in the software industry. For one, it’s simply the right thing to do: we have a responsibility to take care of our planet, and Green Coding is one way we can make a difference. But there are also practical reasons for adopting these practices; energy-efficient hardware, for example, can save developers money on their electric bills (an essential concern in remote setups), and code that is easier to reuse can save time and resources in the long run. So no matter what your motivation is, there are plenty of ways to go, so let’s review some techniques to ensure your code is as environment-friendly as possible.

  • Efficient writing: Before going into coding itself, let’s take a step back and think about the physical tool you use to write: your keyboard. How much energy does your keyboard spend during the day? Although the amount might seem negligible (around 1W per hour on average, maybe even less), most USB keyboards increase around 5 times the amount of energy they consume the older they get, depending on their build type and brand. And going along with the energy used by the whole computer setup, this energy adds up, which is why using wireless, rechargeable keyboards is getting popular in Green Coding circles, as it only needs a single 3-hour charge to work most of the day, and doesn’t consume energy directly while you use them. It may seem like a very small change, but considering how, on average, 600,000 people hit a space bar at the same time every 1/10 of a second, saving energy will have benefits in the long run.

  • Efficient coding: “Coding, for the most part, can become greener almost instantly if we adopt the same software development processes as our industry did 20+ years ago, when coding was confined to strict lengths and sizes”, is an interesting point mentioned by Dean Clark, Chief Technology Officer at GFT, regarding the idea of implementing Green Coding practices. The truth is that, while our ability to code today is virtually limitless, the lean way of writing code when you had to make the most with limited space also meant that no waste of resources was allowed, and optimization was a day-to-day practical concern. “Nowadays, with a lot more leeway in the way we write code”, says Adolfo Cruz,  Project Management Officer, and partner at Scio. “And these approaches to making software could still teach us a thing or two in regards to taking care of our resources, allowing us to create more environmentally-responsible applications whose efficiency could save us a lot of energy and time in the long run”. 

 

  • Efficient debugging: “Coding will inevitably result in bugs, and the act of debugging is, by itself, a way to improve the energy efficiency of software”, is the opinion of the blog TechXplore, which is why having a strong QA department with the appropriate tools is so important to achieve a true Green Coding approach. Following the last point, making sure that our applications are using resources responsibly, and wasting the least amount of energy possible at every step, could go a long way toward making software development more friendly to the ecosystem, and leading to more environmentally responsible practices overall. 

Collaboration as a key to Green Coding

The significant impact of Green Coding on the environment Is balanced software development possible_2

So to recap, Green Coding is the process of developing software in a way that minimizes its impact on the environment. We already mentioned some ways to achieve it, but a key practice in environmentally-friendly coding includes collaboration, Nearshore development, and expertise sharing. Collaboration is essential to Green Coding because working closely with others helps to ensure that everyone is on the same page and that no one is duplicating effort, allowing for more efficient use of resources, which can help to reduce a company’s carbon footprint. 

In the specific case of Nearshore development, working with developers in countries closer to their clients and end-users helps reduce travel emissions, allowing you to take advantage of different time zones so work can be done around the clock, which combined with good Green Coding practices, can make a difference when it comes to leaving a carbon footprint. 

“You might not think that Nearshoring your software development would have anything to do with the environment, but the truth is it can be very beneficial, helping to improve efficiency and cut down on waste”, is the summary Adolfo Cruz offers about the advantages of collaborating within your same time zone, as expertise sharing is crucial to Green Coding, helping to raise the overall level of expertise in the industry to not only improve the quality of software but also help it reduce the need for training and support. 

Development involving a team of experts can often get the job done faster, with fewer errors, and less need for constant testing and development, saving a lot of time and resources. As a result, expertise sharing is an essential part of green coding. All in all, there are many good reasons to consider outsourcing your software development – even if you’re worried about the environment.

In the software development industry, going green is not just about being eco-friendly; it’s also about being efficient, effective, and collaborative. When development teams adopt Green Coding practices, they can work faster, and more efficiently, and as a result, have a positive impact on the software development process. In addition, by adopting green coding practices, development teams can help to make the software development industry more sustainable, and in turn, help the march towards a better future.

The Key Takeaways

  • The technology industry as a whole is very resource-intensive, and thus, a good starting point for more environmentally friendly practices.
  • However, beyond adopting hardware that spends less energy overall, there are practices in the software side of things that could help to be more responsible with resources.
  • Green Coding is an approach to software development where code is as efficient, light, and bug-free as possible, helping to run applications that overall leave a smaller footprint in the environment.
  • Nearshore development is a good approach to green coding, reducing the need for long travels (and thus, the emissions they involve), as well as sharing the necessary knowledge to always improve software, achieving a better balance with our environment.

Scio is an established Nearshore software development company based in Mexico that specializes in providing high-quality, cost-effective technologies to help you reach new heights. We have been developing 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’ll be happy to help you achieve your business goals.