The way we conceptualize work is changing, first as a result of the pandemic, and second as a result of technology letting us do something unthinkable a mere five years ago. The result is a landscape where a lot of organizations are more willing than ever to adapt to their collaborators, offering ways to work that strike a better balance between their personal and professional lives.
However, what does this balance mean? Because the more we think about changing our actual practices, the more challenges and conundrums appear in the need of a solution. And the software industry, as one of the leaders in this evolution of the workplace, is experimenting with ideas more than ever to hit the specific balance between work, personal life, and the needs of a given project.
A right to disconnect
A lot of buzzes were heard when France, back in 2018, began to implement the so-called “Right to Disconnect”, a legal framework aimed at protecting workers from retaliation if they choose to not attend calls after their shifts. As proposed, this regulation showed that “work” as we knew it was starting to evolve, as more and more tasks in a company started to need a kind of specialization that sometimes could not be accomplished in the traditional 9-5 office hours.
This fostered a culture of being “always-on”, which could not be healthy or sustainable at all in the long run. After all, a good outcome for any project could come from an exhausted team that always had to be ready and reachable? The Right To Disconnect tried to solve this, with mixed results.
“We have our best ideas in unexpected places, at unexpected times. Excelling in today’s economy thus demands short bursts of intensive thought followed by seemingly unproductive – yet necessary – lulls. Nourishing such approaches requires workplace flexibility, not regulatory rigidity; depriving skilled professionals of these practices by telling them exactly when and how to work also deprives them of potential opportunities to create value”, says this article by the non-profit policy research organization R Street.
So, even if the intent of these legal frameworks is desirable and necessary, it could be argued that they also fail to solve many of the intricacies of working in industries like software, where different dynamics are at play. Programming, for example, is as much of creative activity as it is a technical one, trying to solve complex puzzles as efficiently and elegantly as possible in a given timeframe.
This means that, even if everyone obviously needs time to rest and relax, the idea of rigid boundaries to solve a programming challenge during a project is closer to the idea of “mandatory fun” than keeping a healthy boundary, with some companies even going as far as disabling emails and chat programs to ensure their workers comply.
“While some procedures, like taking the email server offline, will help to ensure that all employees are on equal footing, this approach may have unintended adverse consequences on employees with flexible work arrangements. Many caregivers, for instance, handle family responsibilities during the day and resume work after hours. IT departments will need to navigate these issues with human resources and user departments”, claims the HR blog First Reference in this article.
This same quote, however, points out a solution that can keep boundaries clear, without enforcing a total disconnect that can result in counterproductive outcomes: flexibility. As the pandemic rages on, and we rethink what work is, the idea of flexibility starts to become more than choosing to work from home or going to the office on a given day; is the ability, up to a point, to set our schedules, our times, or to select to collaborate with an organization that closely aligns with ourselves.
We’re here for you
Thanks to the rise of remote work, the possibility of working with clients abroad in tech hubs like Silicon Valley and Austin without having to lose boundaries or sleep is closer than ever thanks to Nearshore development companies like Scio. But what distinguishes a Nearshore, exactly?
Nearshore companies are getting popular lately, and it’s easy to see why: the whole idea is to offer outsourced development services within the time zone that matches the clients as closely as possible. Being located in Mexico, Scio works mainly with clients based in the US, collaborating with tech firms on projects with all kinds of challenges to solve, without needing the odd working hours that might result from working with a client in Europe or Asia.
This results in a close collaboration that still leaves room for boundaries, as the working hours of the team and the clients are the same; in fact, the schedules offered by Scio make sure there’s overlap in the middle of the day while leaving every developer to choose when to begin and stop working.
“Some of our clients realized that their developers not only can come from Wisconsin, Wyoming or Missouri; they are finding an enormous amount of talent available in Mexico and other LATAM countries that have no problem whatsoever connecting remotely to collaborate”,
“We can see that in our more recent applicants, who value these opportunities and are more than ready to join from anywhere in the world. Our focus is on certain time zones that are not too far apart from our clients, but Latin America as a whole has opened as a software development possibility like never before.”
Tells Rodimiro Aburto, Service Delivery Manager at Scio.
This results in the possibility of expanding the scope of things you develop and learn from, while still maintaining real-time communication with clients in other countries entirely, and without having to adjust your working hours to maintain the same boundaries you are used to, because of the idea of a Nearshore company is to offer convenience in collaboration and communication for both clients and developers, giving you the space to work as you feel best, while maintaining the excellence in outcomes that’s expected in these projects.
“So, what Nearshore comes to offer is the flexibility in which a Development Lead can chat in real-time with a collaborator in Mexico, Chile, Argentina, or Honduras, for example, as a full member of their team while keeping the healthy boundaries in hours that having the same time zone brings”, finishes Rodimiro.
We hope that this article has helped to introduce you to the possibilities of Nearshore outsourcing and shown you how Scio can provide a valuable solution for your business needs. Our team is passionate about creating healthy boundaries for our collaborators while still providing the flexibility needed in the modern workplace. If you are interested in learning more, please send us a message. We would be happy to discuss our services with you and answer any questions you may have. Thank you for taking the time to read our article!
Whether you are coding software or managing a company that creates software, the name of the game is optimization: there’s always a better way to do things, a wrinkle to iron out, a bump to flatten quickly. However, even if we somehow reach a perfect process, it will probably not last long. Technology is always moving forward.
Then why is it often difficult to adjust your development practices to ensure you always obtain a better outcome? Why is it so hard to leave behind “tried and true” methods of development to try new ideas to better the efficiency of any process?
It’s not surprising to find out that the root of a lot of these issues lay within human psychology, specifically a phenomenon that can help us understand how we conceive our practices, and the sooner we can work towards mastering how it works, the better our outcomes will become: cognitive inertia.
The human side of change.
Cognitive inertia” is a term gaining popularity in software development, and with a good reason: it aptly describes why it might be so hard to change approaches to development, even in the face of an evident need of trying something else:
“Changing management is an age-old problem; migrating to a new process with new technologies can represent a big change. The management teams are met with cognitive inertia and a long list of reasons why new methods and technologies will not work. So, instead, they work harder, and the harder they work, the farther behind they get”, points out Barry Hutt, CRO at Viviota Software, in his post “Cognitive Inertia a great challenge to innovation.”
It’s a paradoxical outcome, but to begin to understand this issue, we should define clearly what “cognitive inertia” is. Cognitive inertia is not “belief perseverance”, or the phenomenon of maintaining the same belief even when presented with new information. Instead, cognitive inertia is the inability to change how a person processes information, which is a much more complicated framework that involves motivation, emotion, and developmental factors.
Its consequences can be seen easily in software development when we think of practices like testing or brainstorming, which makes the old adage “work smarter, not harder” a difficult one to implement, especially as a project or an organization grows in complexity.
“Cognitive inertia evolved because the brain optimizes energy efficiency. If you keep the same behavior and don’t question it, your brain conserves space and can make faster, simpler decisions. On a social level, maintaining consistent behavior preserves social cohesion by maintaining social roles and responses”, explains the blog “Cognitive Inertia: The Status Quo Bias” by Joseph Adebisi.
However, it’s obvious why in a field like software development this can bring problems in the long run. After all, even if roles in a development team are clearly defined, the multitude of solutions that need to be reached at every step of the process (from the ultimate goal of the client to fixing the smallest of bugs) benefit from the creativity that surges from having multiple approaches.
Smarter software delivery starts with questioning assumptions, not just repeating past solutions.
The key to collaboration
The approach of Scio to this issue, both internally and in the work, we do with our clients, is knowing that a “solution” is more than having the seemingly right answer for everything; it is developing a process that lets you question and rework the methods you used to arrive at to fine-tune the outcome.
“When you build walls, it’s easy to keep piling bricks on, one after another, in every house you build. That might work for a while, but if now you are looking to build something with a different purpose, like a cathedral or a hospital, will that approach still be the best?” comments Luis Aburto, CEO, and Co-Founder of Scio. “What happens when you partner with someone that comes and says ‘hey, maybe this bricklaying will not support the multiple stories we need for a hospital, so what if we try this instead?’”
A culture of constant sharing through collaboration, then, might be a way to avoid the pitfalls of cognitive inertia. After all, cognitive inertia, as real inertia does, keeps the same trajectory if nothing initiates a change, so the more different perspectives you have, the stronger the final product may be.
“Human beings love to help. Doing it productively and seeing people overcome obstacles it’s a very rewarding experience, and at a company like Scio, where collaboration is a key part of us, you also get the benefit of cross-pollinating different parts of your organization”, says Yamila Solari, Co-Founder and Coaching Leader at Scio. “If you create a culture of mutual help and support, where one person talks to another and so on, your culture is always enriching itself.”
This makes coaching one of the best tools Scio has to keep our organization moving forward, making sure that knowledge gets shared around between collaborators to strengthen the outcomes of every person and every team. This circles back to our earlier article about outputs and outcomes in software development, where we try to understand the purpose and goals of any project we collaborate with before deciding on the approach that will work best for that specific job. Sometimes laying bricks in the usual way will be enough, but that doesn’t mean that developers shouldn’t have an open mind to try new things if they hit a snag during development.
Disruptions in daily workflows compete with the same mental resources needed for critical tasks, reducing efficiency.
Cognitive inertia in the day-to-day
However, one should not assume that the issue of cognitive inertia only affects an organization at the macro level, or that it is always a bad thing; it’s part of our daily work whether we notice it or not. For example: if you are focused on a task, and an interruption comes (be it a software update, an Internet outage, an unforeseen meeting, or even a coworker just stopping by to ask something), how difficult is it for you to resume your rhythm at full speed?
Martin Cracauer, CTO of the software development firm Third Law, holds the opinion that the way our brain absorbs information and uses it in the short term is a form of cognitive inertia, and keeping information properly compartmentalized is a way to ensure a task, or a whole project, doesn’t get derailed:
“A lunch break absorbing lots of information that has nothing to do with your work task is relaxing because it does not compete with the work task memory. But a work meeting that touches actual work stuff competes for the same cognitive machinery. […] Your Company makes its money on the programming tasks that are completed today, so you just traded away the brain state needed for Today’s Task in favor of some imaginary later benefit.”
What this means is that some form of cognitive inertia (the one that puts a developer “in the zone” when writing code) can be used to the advantage of the development cycle if we structure the project with clear goals and purposes that need minimal interruptions, and let the developer to fully focus in the day to day progress.
The Agile methodologies, when well implemented, help with this as it lets organizations like Scio maintain a high level of cohesion in the development cycle that doesn’t give enough space for distractions. A well-managed team knows its goals, the potential pitfalls, and biases that can surge in development, and has the support to focus on the tasks that actually get things done, letting the outcome dictate everything else the product might need.
Cognitive inertia, then, is not inherently a good or bad thing in software development; a well-balanced organization can manage, and even use it to its advantage. After all, the software is not about working harder, it’s about implementing the smartest approach and letting the results speak for themselves.
How Cognitive Inertia Impacts Software Teams
Behavior
Impact on Development
Solution (with Nearshore Partner)
Reusing old tech stacks blindly
Missed opportunities for speed, cost, or scalability
Cultural alignment enables conversations about alternatives
Fear of questioning decisions
Blocked innovation and low morale
Nearshore teams trained in collaborative communication
“We’ve always done it this way”
Slower delivery and tech debt accumulation
Fresh perspective from outside the company mindset
The Key Takeaways:
1.
Cognitive inertia is not stubbornness, it’s the way some people get used to processing information in their day today.
2.
Changing this inertia can be difficult, but is not an insurmountable problem, and it’s a critical need for software development.
3.
Collaboration and tools like coaching can be effective in mitigating the effects of cognitive inertia, feeding constant new information to avoid settling on a single approach.
4.
However, cognitive inertia is not all bad; it helps a developer to focus as long as interruptions and problems derived from sudden changes of course are avoided.
5.
It all comes down to good management. Being aware of bias and cognitive traps, constantly encouraging new knowledge between collaborators, coaching and a good implementation of Agile methodologies can result in a healthy development environment that guarantees a good outcome.
FAQs: Cognitive Inertia in Software Development
Q1: What is cognitive inertia in software teams?
A1: It refers to the resistance to changing existing thinking or methods, even when better alternatives exist—common in both in-house and outsourced teams.
Q2: How does cognitive inertia affect software outsourcing?
A2: If the outsourcing partner simply follows orders without challenging assumptions or proposing alternatives, innovation suffers and delivery slows.
Q3: How can nearshore teams help break cognitive inertia?
A3: Nearshore partners with cultural alignment and agile maturity can question outdated practices, propose improvements, and collaborate effectively in real time.
Q4: What signs indicate cognitive inertia in a dev team?
A4: Repeated use of legacy code, resistance to change, and pushback on new processes or tools are red flags.
Q5: Why is cultural alignment important in addressing cognitive inertia?
A5: Teams that understand the client’s mindset, but aren’t limited by it, can offer a balance of challenge and empathy—critical for breaking inertia productively.
Final Thoughts
Cognitive inertia isn’t usually intentional—but it can quietly slow things down. Whether it comes from habits, old processes, or just being too comfortable with the way things have always been done, the result is the same: missed opportunities, delays, and projects that don’t reach their full potential.
In software outsourcing, this kind of “auto-pilot” thinking is especially risky. When your team doesn’t feel empowered to ask questions or suggest better ways of doing things, it’s hard to move forward.
To truly work smarter, you need a partner that brings more than just technical skills—you need someone who can offer fresh ideas, challenge assumptions, and help your team grow.
Work With a Nearshore Partner That Helps You Think Differently
At Scio, we’re more than just developers. We’re collaborators, advisors, and partners in building great software. For over 20 years, we’ve supported U.S. companies—especially in places like Austin and Dallas—with nearshore teams that understand both the tech and the people side of development.
If you’re ready to break the cycle and build a team that truly works smarter…
Let’s talk and explore how Scio can help your product—and your team—move forward with clarity and confidence.
How to measure productivity effectively? Adolfo Cruz, Scio’s very own Project Management Office director, offers insights into a question many in the business have in their minds all the time.
By Adolfo Cruz.
Building an exact image of productivity is a question with no definitive answer yet. Defining what “productivity” means for someone starting a business for the first time is a complex process. From everything I’ve learned these 14 years at Scio, each person needs to discover what works for them, considering the specific context in which they are trying to succeed.
The thing is, when trying to measure productivity in something as fluid as software development, every seemingly useful metric comes from a different perspective (be it from the client, the developer, or the managers), so if you want to establish a baseline, I would recommend defining priorities first, taking into account your business needs.
How do we measure productivity in Scio?
Early in Scio’s history, around 2008 or so, we tried to implement Agile Methodologies along with some number crunching, like the hours put on a project or the number of bugs, to know exactly how productive our teams were. However, the number of variables involved, like realizing that a specific team had better outcomes because they had certain chemistry between them, made it difficult to translate the results into measures that could be implemented in any project.
So we moved away from that, instead of looking at the results from the client’s perspective, thus defining our productivity as the value our developers are adding to a product during development. Our measures became more focused on people than metrics because helping a client to build a product, adding value at every step, and therefore growing their business, was our main priority.
To this end, building a perfectly calibrated development team that proposes new things, learning and evolving together was the best approach for Scio. A lot of the time it’s not even necessary to keep a register of everything happening during development because the team itself realizes when something’s not right and works out any issue; a team of developers capable of self-management is always a good sign.
If you achieve such a team, you don’t need to measure specific metrics for each collaborator, instead, you evaluate the team as a whole, looking for relevant information that can help them grow, so you should think of questions that help you get the information you need.
For example number, many User Stories were completed in a given time?
Was there any serious bug in the development of the product?
How many bugs surfaced?
What priority did these bugs have?
How did the team respond to them?
How long did it take?
However, these questions need to be constructed with the project’s context in mind; although there are a lot of metrics you can use to generate specific “productivity” numbers (like the Personal Software Process popular in the 90s that tried to define productivity through the number of lines of code written), if they don’t reflect reality, then the team will not know how to use this information, as many of the challenges they face can be subjective.
So avoid trying to arrive at exact numbers, and instead, I recommend you to look at the trends emerging from one project to another. A trend interpreted correctly should give you a “big picture” of both performance and productivity, showing places where your attention or some improvement is needed.
First, look for a certain range of information in a development cycle; If the team completed between 5 and 10 stories in a sprint, but only 1 or 2 the next one, there’s probably a red flag somewhere in need of attention. Then dig a little into it, and maybe you’ll find some unforeseen challenges the team needed to prioritize to keep making progress. And finally, make a note out of it, so you can improve the circumstances around an issue so it doesn’t reappear later; that’s how an understanding of productivity begins to emerge.
Most of the trends we watch at Scio are about how our developers contribute to our client’s goals, and we developed some tools to measure that. For example, we use the Team Self-Assessment, a guideline for collaborators to reflect on their work, that we adopted and modified according to what our experiences and specific contexts dictate.
In our TSA, there’s a section where we inquire about bugs surfacing during development, asking how they are preventing issues during development, if they are doing Pair Testing practices, if they are showing their additions to someone else before moving on, and generally if they are focusing on things that matter.
When a team reviews these questions, they realize their areas of improvement, and we work together to avoid falling into them again in future projects, because what you want to do is push your teams into adopting excellence as a natural part of their processes, encouraging them to add their experiences and expertise to the final product.
The subjectivity of a productive team
Productivity is not always a purely technical approach; sometimes you need to look at the business side of things, involving the stakeholders and product owners in the creation of the product to reconcile a multitude of perspectives, converting them into priorities to define the best course of action.
Just remember that you need to experiment in software development, build an iteration of the product to validate its potential, and look for features that can be improved to maximize its success. Your development team will probably need to go back and rework a lot of stuff, updating their methods to create a more efficient version of the product, so your definition of productivity here has to account for it; if stuff is being redone, at least quality should always be improving.
So, to recap, a good measure of productivity is established by defining your business priorities and then choosing the metrics that best reflect the context in which the product will be built. A productive development process gives enough flexibility to iterate and experiment without neglecting business needs, and having your client’s goal as the focus of your team is a great starting point.
Just remember that if you aren’t adapting what you learn into your specific context, capturing the information your team needs, then productivity might suffer. Software is mostly a creative enterprise, so some subjectivity will always be needed to properly define what makes a successful project, fine-tuning every cycle to achieve the value you want for a specific product. With an approach like that, you can be sure your organization will always be improving.
Last time, we discussed the skill necessary to work remotely with Jesús Magaña, one of our Project Managers here at Scio. But, as you might think, setting up a home office is another story entirely. How to manage it? We hope this second part of our chat sheds some light on it.
by Jesús Magaña
Working from home is a challenge.
I spend most of my time on calls and video conferences. When the pandemic started and we had to go home, it was somewhat uncomfortable. “Oh, they are going to see my house”, or my wife or children would pass behind me inadvertently, or you would probably hear someone ringing the door or yelling, and other considerations you never had before, but you learn to deal with them day by day.
But after almost two years of that, I like the way we are working now. I feel the team is more productive and accomplishes a lot more, and although I miss the old office dynamic of arriving and greeting everybody by hand, remote work opened a ton of connections and made a lot of changes to my personal life.
I can have lunch with my kids every day.
For example, do you want to know something cool about working from home? I can have lunch with my kids every day. Just like everyone else, I used to eat out of a Tupperware container at the office, but now that hour also works as a break where I can spend more time with them.
Also, it’s an interesting feeling to be aware of how your kids see you while you work, and how you express yourself with the people you work with, even if you have your door closed. I think that for a Project Manager, it helps to be working in an environment like that. If you were not a very good PM, screaming at people and whose attitude is less than ideal to collaborate, would you behave the same way in front of your family?
People learn a lot by imitation, and promoting a good culture of working, is easier if they directly see you. It can also help you to detect some vices you may have when you realize you are about to do things you don’t want them to see you doing.
You see, one of my main responsibilities is transmitting the culture of Scio to our apprentices and every new person that joins the team. Culture can have an effect at home too because it is a similar process to teaching your kids the kind of attitudes you want to see in them.
So, if your kids see you dealing with people in a professional, empathic, and understanding way, they are probably learning something valuable about collaboration and relationships.
The home office can humanize a collaborator.
They can take a peek into your inner life, the things you have at home, the people there with you, and you can learn more about their hobbies that you may never know otherwise.
All these kinds of things give you more context about others, and you can generate more personal connections because, when you turn your camera on, you let them enter your home, and that shows the human side of your coworkers.
As you can see right now [during the Zoom interview], I have a blurred background, because I moved out recently and I don’t want all those boxes to show up and that, but that’s a normal part of a home office.
Still, the challenges go beyond that. In the beginning, when I started to work full time from my home, the balance between my personal and professional life was non-existent, “I’m already here, I don’t have anywhere else to go”, and without a clear line during the day at which to stop working.
Of course, I noticed that wasn’t right, but I still reached a limit. There was a certain feeling of tiredness when you don’t have a clear dividing line between both sides of my life; it was easy for me to stay an extra hour to finish late stuff, but I got to the point where I was just going through the motions the day.
And that affects your work. I started to become more easily distracted, and without that urgency I had in the office to finish stuff and go back home, getting burned out was easy. After all, I was already in my house and any concern about returning late had disappeared.
So I started changing my attitude about it, first by trying to schedule things to do in the afternoon and to always have something to do, be it just riding my bike, going for a run in the park, or things like that.
I try to be consistent with it, and disconnecting completely at the end of the day makes it easier, even if I have to play up the change of context by walking around the block or something when I finish? or start my day. It works for me and lets me know when my day has finished and if I should stop.
If someone asks me these days for advice about being a Project Manager, first I would like them to consider why they want to do this kind of work, to see if their idea of a PM is realistic. You are in a very critical position of responsibility, and I recommend they develop some great social skills and know the entire development cycle well.
These days, my routine is very well defined, and that’s important for someone who wants to follow this career path from now on. I spend all my morning on calls, updates, and client meetings, probably around 40% of my time goes into that, leaving the afternoon to deal with the specific needs of my team, from getting a new mac for them, to define parameters and functions of everyone involved. And after doing it all from the comfort of my own home, I cannot imagine doing it any other way again.
Is technical debt a recurring problem you face, or is trying to future proof the software you write the best course of action? Today, we take a look at one of the most complex problems when creating software, analyzing the pros and cons of both approaches.
by Scio Team
Software development is… complex. At its core, it’s an interesting challenge where improvement and evolution happen alongside the construction of the software itself, with the possibility that it changes course when you learn new things, get a new perspective, or bring diverse points of view to the table.
As we said elsewhere, developing software is very similar to writing a novel, or painting a picture: it’s as much of a discipline as is a creative exercise, borrowing and modifying itself throughout the project. However, there’s a big difference between a book and software; the software is part of an infrastructure, meant to interact with a user, across an undefined period, which gives this profession a unique challenge: what happens to the code I’m writing today when tomorrow arrives?
A debt to ourselves
“It’s OK to borrow against the future, as long as you pay it off”, are the words of Ward Cunningham, one of the authors of the Agile Manifesto, which revolutionized the way we look at software development. We all know how borrowing money works in our daily life, but what he referred to is a specific concept many in the software industry are aware of: Technical Debt.
As you may know, technical debt is “the implied cost of future refactoring or rework to improve the quality of an asset to make it easy to maintain and extend”; is the knowledge that certain parts of a program may require to be fixed at some point in the future.
There are plenty of reasons why a dev team may incur this “debt” (be it for budgeting, skill, or deadline reasons), but the nature of its payment is stumbling onto issues that need to be fixed quickly, which may bring more issues later that will require further fixes and so on, effectively like trying to pay a loan with a high-interest rate. If you are not careful, you will end up paying it perpetually.
Technical Debt is considered a serious problem and plenty of literature and management advice have been written to mitigate its effects, but like with any kind of loan, it can bring plenty of benefits if chosen and managed correctly. After all, if we take on a debt, it is for something in exchange, be it having cash on hand to accomplish something, or achieving working software to solve the issue at hand.
And the proper way to deal with debt, be it technical or otherwise, is to pay it on time, which in software development means refactoring a lot of the work done.
However, depending on the level of debt accrued by a team, this refactoring may bring a hefty tag, especially if the time between creating the program and improving it allowed many dependencies to flourish, or some of the knowledge behind the construction to get lost (such as the original team changing), so you may want to avoid the need of refactoring as much as possible because you don’t know the context in which the program will be improved. So what then?
A proof of thinking ahead
Futureproofing may be the answer. What futureproofing tries to do is “anticipate and minimize the effects of shocks and stresses due to future events.” This practice is not limited to software, but it can help to try and mitigate some of the problems technical debt will bring, especially if we are thinking ahead of the need for refactoring at a certain point in the future or having to deal with legacy software inside critical systems in any organization.
However, saying it is much easier than doing it, and any approach to futureproofing a system, so it can be tinkered with or without issue decades from now, is a tenuous art at best. After all, how can anyone predict what software will look like in 2050? The solutions we implement may make sense today, but will probably need some explanations later.
A solution could be, to create software that follows a pattern, so its logic can be easily deduced by a future dev team, as well as taking the proper due diligence when choosing tools and frameworks that have a better chance to remain supported or at least accessible in the coming years, or avoiding “monoliths” where a single application is responsible for tons of functions, but one can still get blindsided by a development impossible to foresee.
This brings an interesting conundrum for many developers trying to find the right approach: is it better to futureproof software to try and avoid technical debt, or is better to acquire some debt if that means having the flexibility to refactor software at some point in the next few years?
Two sides of the same coin
The reason is very simple, yet has lots of implications: if you acquire technical debt, you cannot futureproof because you are assuming you will need to change things. If you futureproof it, then you are making stuff that will greatly resist refactoring, making it likely to turn into “legacy” software.
A good approach to finding a solution to this is developing products with a few things in mind, mainly no software product is forever, and everything has a shelf life that we will need to wrestle with at some point.
“Generally, it is not until something breaks when a team realizes they have a big debt needing to be paid”, commented Scio’s PMO, Adolfo Cruz, about this issue. “It’s more common when a product is brand new and it’s still building its user base. The volume of transactions is low at first, so you may not see any problems, but if the scalability wasn’t planned well, then it’s more likely that debt will flow under the radar until it’s too late, so it’s important to take steps to prevent this.”
The trick is trying to push back that point as much as possible, having the proper procedures to ensure the code can be fixed. A good commenting discipline, for example, can save a lot of headaches while refactoring an application, letting whoever has to modify it knows what can break and what depends on every function. This can work as futureproofing without going into a lot of technical debt, as many of the problems when trying to refactor old programs is the fact that the code sometimes is not very clear, and in places of a lot of personnel turnover (like a government agency), it’s easy to let cracks grow.
The useful approach, then, is considering both of these concepts as the two sides of the same coin: the delicate balance that is developing good software amidst the needs of the now and the later. A great software development team should strive for products that pass the test of time, while also knowing that nothing is perfect, and using the need for refactoring as a tool, not only a problem.
What do you consider is the best approach when creating software? An application with some debt that will let you fix it in the future if it needs to, or building something hard to repair that may stand the test of time?
