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.
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
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
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.
The process of QA testing came into prominence, at least within more mainstream audiences, when stories about it came out regarding the popular (and some might say) infamous videogame Cyberpunk 2077, which has become known as one of the most high-profile disasters of shipped software products.
And as bugs were some of the most notorious problems of this game, it also presents the opportunity to talk about a very important part of software development, which can make or break a product: Quality Assurance. What does a good implementation of QA look like? What does it aim to find, and what are the best ways to go about it? And more importantly, what makes a good QA process?
1. Quantity of over quality (assurance)
An anonymous source within Quantic Labs, one of the firms in charge of QA in Cyberpunk 2077, told journalists about a “bug quota” imposed by management on their testers. With the requirement of reporting at least 10 bugs per day, the logic seemed to make sense: encourage your testers to be as thorough as possible, and thus ensure the final product will have the highest quality. However, if you are familiar with how the QA process works, you are already wincing because you know where this is going.
Quality Assurance is an important part of software development that, by ensuring that code is well-tested and meets standards, helps to improve the efficiency of a development team, and several good practices can help to ensure a successful quality process. Quotas can have the precise opposite effect, slowing down development by flooding developers with meaningless reports. Which, should be said, is no fault of the tester; after all, what is the result if they fail to meet them?
“I’ve worked in QA since 2011, been a Team Lead for the last three years, and bug quotas are a bad system which achieves absolutely nothing good”, explains one of the comments in the aforementioned article.“First, your testers enter a load of unproductive bugs, because they will divide one issue up into as many possible JIRA entries as they possibly can. And on top of that, they don’t have time to properly investigate the more complicated issues that they find — you get a lot more crash bugs with horribly elaborate reproduction steps because testers can’t afford to spend two hours nailing down exactly what triggers them.”
So with measures like these, the management of a project can unintendedly encourage bad QA, as it makes it more about the number of bugs found and less about their importance. So instead of quotas, a better method could be to ensure that everyone knows the priorities of the project, and have a clear definition of what constitutes a bug or issue (to let developers know when they need to fix something). Understand that QA is an important part of the development cycle from beginning to end, and enough time to do proper research and testing on bugs and issues is crucial in the planning of any successful project. Speaking of which…
2. Not a step, but an ongoing process
One of the biggest myths about QA testing is that it’s a one-time event that happens at the end of development. This simply isn’t true. Even if many people think it’s just a matter of catching bugs before a product is released, QA testing is an essential part of the software development process, and it should be treated as an ongoing collaboration between developers and testers.
This means regularly testing code and providing feedback to developers throughout the software development lifecycle; after all, effective QA testing is about making sure that a software application meets the requirements of the end-user. This means ensuring that the app is easy to use, bug-free, and performs well under real-world conditions, and QA testers play a vital role in ensuring that these standards are reached by working closely with developers throughout the whole project.
“Companies that realize the importance of Quality Assurance encourage employees to look at every part of the software development process as a “product” that has its consumer”, is a good explanation given by this blog from the QA firm Syndicode. “Defects are possible at each stage, so it’s important to ensure all participants adhere to the quality standards.”
After all, QA testing needs to be a collaboration between developers and testers, but it can also be heavy on time and resources. One way to improve efficiency and reduce costs is to ensure that a team, by working together, can quickly identify and fix errors, saving time and money in the long run.
3. Good communication between the QA team and developers is everything.
In any line of work, good communication is essential to collaboration, and this is especially true in the field of QA Testing, where clear and concise communication can mean the difference between a successful project and a costly mistake.
This means setting expectations, outlining the scope of the project, and establishing a clear process for reporting bugs and feedback. Without good communication, it can be difficult to get everyone on the same page, leading to frustration and delays. By taking the time to establish good communication early on, you can save yourself a lot of headaches down the road.
Also, this is where the advantages of a different approach in collaboration can shine, like the option of working with a Nearshore organization to find the QA talent your project needs. There are many benefits to this, like the increased diversity you get when expanding your scope (important to get as many fresh perspectives as you can when solving a particularly thorny bug), as well as efficiency and communication. With Nearshore proximity, it gets easier to build strong working relationships with other team members, whose cultural closeness makes work smoother in general, while also being flexible and scalable, making it a good option for businesses of all sizes. This way, teams can work more closely together to identify and resolve issues more quickly.
The result is that, with a Nearshore QA department, collaborative testing can also help to improve communication and build trust between team members; when everyone is on the same page, it leads to better quality software and a better user experience.
QA: More than meets the eye
The case of Cyberpunk 2077 we mentioned at the beginning is a great example of a QA process done wrong, and thankfully, any future product development can learn from it and understand how to approach an area of IT that sometimes doesn’t seem as valued as it should. The main thing is that proper QA is critical for success, and having a good approach towards it is the first step to guaranteeing a useful product that meets the expectations, and preferences, of a user base.
The Key Takeaways
QA is a critical part of software development, and any successful product has a strong quality process in place.
However, it’s very easy to choose the wrong approach to QA, compromising the functionality and success of any application, no matter how good it is.
Collaboration, communication, and a proper system that encourages looking for big issues during development are crucial, keeping everyone on the same page and with the same goals.
And when it comes to remote collaboration, a Nearshore partner is the best choice to bring the best QA talent to your team, as the close cultural fit and ability to communicate are invaluable to ensure a quality application.
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.
1. Why the Junior–Senior Divide Feels Blurry in Modern Engineering
The distinction between junior and senior developers has always been debated, but the past few years reshaped the conversation entirely. Distributed teams, shorter release cycles, and rising expectations for autonomy changed how engineering leaders evaluate talent. The industry no longer accepts years of experience or a long list of frameworks as proof of seniority. Teams need developers who can navigate complexity, collaborate effectively, and make decisions that hold up under pressure.
This is why the junior–senior conversation deserves more nuance today. It is not about showing off technical horsepower. It is about understanding how engineers behave when things get messy, ambiguous, or strategically important. The traits that separate junior and senior engineers live behind the code: how they think, how they communicate, how they balance outcomes with constraints, and how they support others on the team.
Helena Matamoros, Human Capital Manager at Scio, summarizes it well:
“You can’t just link years of experience to the number of different technologies you may know. Being a Senior or Lead developer includes soft skills.”
Engineering leaders in the U.S. understand this better than anyone. Your product moves fast, your roadmap shifts often, and your customers expect stability even as your stack evolves. You cannot hire for “years of experience” and hope everything else works out. You need clarity around what behaviors actually predict senior-level performance.
And it starts with recognizing how the industry moved far beyond the old linear view of growth. A developer with two years of experience today might be working at the same technical depth someone ten years ago reached only after a much longer ramp-up. Meanwhile, a developer with a decade of experience may still be working reactively, solving isolated tasks without understanding the broader purpose of the product. The inputs look similar, but the outcomes tell a different story.
This is why understanding what truly differentiates junior and senior engineers is foundational. It helps engineering leaders set expectations with more accuracy, build stronger career paths, and allocate responsibilities that genuinely improve team performance. For developers, it provides clarity around what to work on next and how to shape their growth into something meaningful.
To frame this difference, let’s start with a powerful analogy from outside the software world—professional tennis.
2. Outputs vs. Outcomes: The Tennis Analogy That Explains Everything
In his classic essay “Loser’s Game,” consultant Charles Ellis breaks down the difference between professional and amateur tennis players. Amateurs try to win by avoiding mistakes. Professionals win by pursuing opportunities and shaping the match strategically. One group plays not to lose, while the other plays to win.
This framework translates directly to software development.
Junior developers usually play a version of the “loser’s game.” Their energy goes into building features correctly, avoiding mistakes, and getting through tasks without breaking anything. They focus on outputs, checking off items in the backlog one by one. Their work is valuable, but their perspective is narrow.
Senior developers, on the other hand, play the “winner’s game.” They understand the broader context of the product and optimize decisions based on outcomes. They take calculated risks. They ask questions that prevent future problems. They anticipate what could go wrong before the team feels the impact. Their thinking is long-term, strategic, and grounded in the realities of complex systems.
A senior developer knows software evolves through iteration. The first version will rarely be perfect—and it should not be. Requirements shift. Stakeholders change direction. Constraints appear halfway through the sprint. As ITNEXT explains, senior engineers do not take this personally. They understand that building the “wrong” version is often part of building the right one later.
Junior developers tend to react differently. They see unexpected change as a sign of failure rather than as a natural part of engineering work. They follow instructions closely and rely heavily on predefined paths. When something shifts, they feel the disruption more strongly because their view is anchored to tasks instead of outcomes.
This mindset difference is not about intelligence. It is not about raw technical strength. It is about perspective, which develops only through exposure to ambiguity, accountability, collaboration, and deliberate reflection.
Once an engineer begins shifting from outputs to outcomes, the transition toward senior-level performance accelerates.
3. The Actual Criteria That Separate Junior and Senior Developers
Years of experience help, but they are not the main predictor of seniority. What matters most is how much autonomy a developer brings to the team.
Helena Matamoros from Scio puts it plainly:
“Being a Senior or Lead developer includes soft skills, such as leading teams, supervising the work of others, assigning tasks, reporting statuses, and visualizing obstacles.”
To understand autonomy better, let’s break it down into distinct dimensions: decision-making, technical scope, risk management, situational awareness, and collaboration.
Below is a simple comparative module engineering leaders can use when evaluating talent:
Comparative Table: Junior vs. Senior Developer Behaviors
Dimension
Junior Developer
Senior Developer
Autonomy
Needs close guidance to ensure tasks are completed correctly
Able to drive tasks, unblock others, and self-direct effectively
Decision-Making
Consults leads before choosing an approach
Makes informed decisions and explains the reasoning to the team
Risk Evaluation
Focuses on short-term safety and predictable outputs
Evaluates long-term impact, trade-offs, and business outcomes
Perspective
Sees features; thinks in isolated components
Sees systems; understands how decisions affect the entire product
Handling Mistakes
Avoids risk; sees mistakes as personal errors
Treats mistakes as learning tools and improves processes
Collaboration
Consumes support from teammates
Provides support, mentorship, and clarity for teammates
These behaviors shape how developers perform in modern product teams, especially in distributed environments where communication, speed, and clarity matter more than ever.
A junior developer might deliver great code but struggle to anticipate downstream issues. A senior developer might deliver the exact same feature, but with guardrails, documentation, testing patterns, or architectural context that prevents costly rework and reduces future technical debt.
What often surprises early-career engineers is that technical mastery alone does not guarantee seniority. You can be an excellent coder and still operate with a junior mindset if you stay anchored to tasks instead of outcomes.
This is why engineers with five or even ten years of experience may not automatically qualify for a senior title. Without responsibility for planning, communication, leadership, or risk evaluation, their work remains task-centric. In contrast, engineers with fewer years of experience but strong initiative, ownership, and collaborative instincts may step into senior responsibilities sooner.
The key is not time. It is behavior.
4. A Practical Framework for Growing From Junior to Senior
If the gap between junior and senior developers comes down to autonomy, perspective, and decision-making, the natural follow-up question becomes: How does an engineer grow into that next stage?
The answer is not a checklist of languages or certifications. It is a shift in how developers think and behave within the team.
A practical growth path includes four pillars:
1. Technical Ownership
Senior engineers have depth in their primary stack and enough architectural awareness to avoid decisions that create instability. They understand why the team’s tech choices exist and how to apply them responsibly.
2. Communication and Soft Skills
Soft skills are not “nice to have.” They are foundational. Engineers must articulate trade-offs, negotiate scope, provide mentorship, and communicate risks plainly to product partners. This is the bridge between technical execution and strategic impact.
3. Collaboration Under Uncertainty
Modern software development is nonlinear. Requirements shift mid-sprint. Production issues appear at the worst time. Stakeholders re-prioritize. Senior engineers stay calm through ambiguity, adapt effectively, and help the team keep momentum.
4. Learning From Every Iteration
One of the clearest indicators of seniority is how a developer handles mistakes. Juniors see mistakes as failures. Seniors treat them as signals. Mistakes lead to better documentation, stronger patterns, new tests, or adjusted processes.
Senior developers do not avoid complexity. They shape it.
To reinforce this distinction, let’s revisit the idea introduced earlier: juniors focus on outputs, seniors focus on outcomes. A junior developer completes a task. A senior developer ensures the task supports the right business purpose, aligns with the architecture, and reduces friction for the rest of the team.
This mindset shift is what turns “more experience” into deeper expertise.
At Scio, this is exactly why engineers grow through collaboration, cross-team exposure, and guidance from more experienced developers. It is not about memorizing a toolset. It is about learning how to operate as a trusted contributor inside a product organization.
5. Final Thoughts: Seniority Is Built, Not Granted
The blurry line between junior and senior developers becomes much clearer when you look past technical checklists and focus on how engineers behave inside real product environments.
Seniority is earned by:
Making decisions that hold up over time
Understanding the whole system, not just a task
Supporting teammates and reducing friction
Managing uncertainty without losing momentum
Learning continuously and applying those lessons with intention
Technical skills open the door, but autonomy, communication, and perspective define the rest of the path.
This is why engineering leaders must treat seniority as a holistic assessment, not a static number of years. And why developers who want to grow need to work on how they think, collaborate, and contribute to shared outcomes—not just on adding another framework to their résumé.
Growing as a developer is a lot like growing into adulthood. You gain more responsibility, make tougher choices, and learn to see the bigger picture. At some point, you stop waiting for instructions and start shaping direction. You start seeing the entire product, not just the feature. And before you know it, you are leading the way for others.
The question now is simple: what step will you take next?
FAQ
Developer Seniority & Growth – FAQs
How engineering leaders should think about seniority beyond years of experience or tools.
No. While technical breadth can help, seniority is primarily reflected in autonomy,
decision-making quality, communication skills, and the developer’s overall impact
on team outcomes.
Yes. Developers who consistently demonstrate ownership, strong judgment,
and system-level thinking can reach senior responsibilities regardless of
total years in the industry.
Certifications can support learning, but seniority is earned through applied
experience, collaboration, and the ability to navigate ambiguity and complexity
in real-world systems.
By observing how they make decisions, handle risk, support teammates,
communicate trade-offs, and take ownership of outcomes—not just tasks.
Senior readiness shows up consistently under pressure.
When we think about the landscape of software development, it’s easy to fall into a binary view: people either work at a tech start-up, with the allure of innovation and cutting edge technology, or they work with a corporation like Google, Microsoft, or Amazon that promises stability and long term rewards in exchange for creating products with a more incremental and risk-averse pace.
There’s plenty of content about what it is like to work in both kinds of organizations, with lots of writing devoted to discussing the virtues and drawbacks of each, but are those the only two options in software development? What happens with mid-sized software companies, and in which ways do they distinguish themselves from either start-ups or big companies?
Outputs and outcomes
Let’s try and define the actual differences between these three types of companies, specifically in regards to how they view and measure product development objectives. After all, a software organization can be defined by the outcomes they want to achieve, and the outputs they decide to focus on to reach them. But what do these terms mean? In the words of Kirstie Magowan, from the BMC Blog:
The outcomes are what the business wants or need to achieve.
The outputs are the actions or items that contribute to achieving it.
Or in other words, “outcomes are the results, and outputs are the activities that support the desired results”, and clarity of purpose for both of them defines what a given organization focuses on to develop the best possible products.
So, within product development for software companies, outcomes are things like new version releases, new features implemented for the users, faster development cycles, improved quality, etc. On the other hand, outputs are things like software requirements/user story documentation, UI/UX prototypes, code, database scripts, test cases, DevOps scripts, and so on.
However, some nuance needs to come into play at this point since we can imagine that organizations of different sizes and maturity cannot all seek the same outcomes. We’ll explore it in more detail, but in our experience, the main force that drives start-ups, mid-sized companies, and big corporations is that their target user bases have different expectations of their respective products.
The weight of expectations in development
“The top desired outcome for a start-up development team, working on the early stages of a new product, is to build an MVP as fast as possible so the company can launch it and attract enough early adopters to keep iterating an idea”, says Luis Aburto, CEO, and Co-Founder of Scio, about his experience working with companies of all sizes. “At this point, you have a ‘forgiving’ attitude among the user base if the product shows enough potential. Early adopters will frequently overlook some issues if the value they get in return is enough and the product has a clear roadmap of features and functionalities that will improve the final version in the future.”
So the challenge for a start-up is to iterate a product fast enough to establish itself before interest dries up. After all, if we define a start-up as “a temporary organization designed to look for a business model that is repeatable and scalable”, the push for innovation is always running against time, looking to please early adopters enough so the product gets accepted in the mainstream. That way, you get organizations more willing to bend the rules, avoid the bureaucracy that comes with very defined processes, and overlook some production requirements (like documentation) if the team is small and their output is focused on delivering a product.
“In contrast,for a big company”, Luis continues, “every time you implement a new feature, you have an opportunity to either delight your users or cause a catastrophe. Suppose you are an organization that has maintained a product for 10 or 15 years. In that case, there are a lot of dependencies and expectations that come along with that, and if you are not careful, test everything closely, and research your market fully, you can end up in a position where you can damage your clients and users. What if they depended on certain features or functionality for their jobs, or had important data stored inside the product? The outcomes here would look very different, as the “forgivingness” of your user base gets lower the more mainstream it is.”
These expectations, then, dictate the best outcome for a given organization, and in turn, these outcomes will dictate the outputs needed to achieve the goal. However, the unique challenge here is that, while outputs can be defined and measured easily, the outcomes seek to “change a behavior in the user”, which is a much more subjective and nebulous goal. To this end, Natalie Diggings, of OpenView Partners, proposes a set of questions to evaluate the performance of any given team with an outcome-focused mindset that can help engineering teams and management alike to keep their goals aligned:
Are you delivering value for the customer?
Are you delivering results each quarter that will help grow the business?
Are you mitigating risk?
Do you know the ROI of the features you’re building?
Did you ship when you said you would ship?
“What we try to do at Scio, by implementing the Agile methodologies in every project we work on, is to establish a minimum of processes and continuous communication to ensure the output our team contributes to the desired outcome for the product, avoiding misaligned expectations and other issues”, continues Luis about Scio’s experiences working with start-ups. “And for a big company, we try and secure a seamless on-boarding of our developers, as these organizations have clear and defined processes that we like to follow to a T to fulfill these same expectations.”
Mid-sized companies: Hitting the sweet spot.
However, Scio’s area of expertise is a segment of the software development industry that doesn’t seem to have that much attention directed at the mid-sized range of companies that hit the balance between a start-up and a big corporation, which has some unique benefits worth exploring.
For example, if we go back to expectations, outputs, and outcomes, an organization of around 50 to 100 people is still guided and directed by the vision of its founders, which seems to bring some advantages that balance out the issues of the other two types of companies.
“Working with a big, Microsoft-like corporation seems like a no-brainer, but at that size, and the bureaucracy that comes along with it, there’s a very limited impact you can have in a given project. But with a medium-sized organization, where you still have the opportunity to work directly with the founders and share and understand their vision, alongside an organization still looking towards the same clear goals, collaboration becomes a more personal matter. Is a business with a human element still felt”, Luis concluded.
These kinds of connections are important when you look for a partner to help you reach a specific outcome, as a “clarity of purpose” can still be shared among the development teams, executives, and product owners, with the benefit of the structure, processes, and methods of a mature organization. After all, before hitting the “millions of users” metric, a mid-sized company still has the chance to push innovation forward with minimal risk.
This is also another big difference between these three kinds of organizations; for a start-up, risk in pursuit of innovation is the name of the game, and for a big corporation, incremental improvement with stable growth is the norm. Having an approach that can still make use of both perspectives is what makes working with these companies so interesting.
“On the business side, a mid-sized organization still looks to grow, but the relationship with their users and clients still has a personal touch, with support and communication at a human level, which allows them to get new clients more easily while still maintaining their current ones. And in the development size, the cohesion between collaborators, both in-house and outsourced, still has a clarity of purpose in their outputs.This is the way Scio functions, and also why we like to offer their support to mid-sized companies; our communication, collaboration, and goals always come hand in hand during a project. With this, the best outcomes are more measurable, reachable, and all in all, understandable”, concludes Luis.
The Key Takeaways:
An outcome is defined by the expectations of the clients of a given company, which should be taken into account in every development cycle.
Clarity of purpose is critical; if your dev team doesn’t know where their work is pointed towards, then it’s difficult for the output to match the outcome, which can vary heavily depending on the age and size of the organization.
Companies of different sizes have different strengths and weaknesses, but a mid-size company can have the best of both worlds: the processes necessary for a project to succeed, while still maintaining cohesion among its collaborators.
The personal relationships that can grow during collaboration are important for the outcome of a project, as they make it easier for a team of collaborators to share a vision and purpose in their outputs.
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.
The idea of a future when AI can perform all sorts of tasks, even programming, is irresistible, but is it something feasible? Is programming a job that can be done by machines, and if not, why?
By Scio Team
One of the biggest leaps of these past two decades, and indeed the most intriguing technology development of the 21st Century, is the advancement of Artificial Intelligence that seems to occur every day. It is understandable why; science fiction technology has a sort of magnetism that attracts all kinds of engineers, entrepreneurs, and visionaries, many of them with the cash to back up the R&D necessary to bring these visions to life.
AI also has the allure of being potentially implemented anywhere, automatizing plenty of daily tasks to free up our time. It’s also attractively dangerous, as countless Terminator jokes can attest every time a new development hits the news.
However, what is actually feasible for AI to accomplish? What are its real applications, at least for now? For the last 7 years or so, there have been some talks about AI being capable of performing more intensive labor, programming, and development among them, but is the job of the programmer in danger of being done by a robot?
It’s easy to imagine, at least. Plenty of tools already use some measure of AI to function, and interesting experiments crop up daily, from intelligent chatbots to autonomous machines. But are those tasks comparable to the actual job of programming in any way? Because as an engineer or developer knows, writing code is just a small part of the whole process of creating software.
“Processing large amounts of data? Software’s great at that. Figuring out what a human wants, or what a usable UI is like, or what the real problem you need to solve is… those are hard”, says an entry in the blog Code Without Rules titled “When AI replaces programmers”, which goes directly to the big issue in a future of machine-produced code.
Although there have been some advancements on the idea of teaching an AI to write code and produce entire programs, like the experiment done by Andrej Karpathy in 2015 where he trained a neural network with GitHub’s Linux repositories to write its own code, the results are still mixed. According to the site Perforce.com:
“[The] AI generated code (including functions and function declarations) overnight. It had parameters, variables, loops, and correct indents. Brackets were opened and later closed. It even had comments. However, the AI produced code had syntactic errors. It didn’t keep track of variable names. Sometimes variables were declared but never used. Other times variables were used but not defined.”
Of course, this was way back in 2015, and the technology behind these networks has only improved since then, but the actual viability of letting a machine program by itself one day, especially for more critical areas like Defense, Finance, or Healthcare, it’s still far away and will still be at the mercy of human instruction.
The advantage of outsourcing these kinds of tasks, be it to a remote developer or an entire Nearshore company, is the ability to communicate clearly anything you may want in the software produced. Collaboration is constant, communication is key, and the skill to apply different ways to solve issues is a given in any valuable development team.
This is to say, the “creativity” involved in these kinds of efforts is still a long way off, and having this skill while programming is critical to producing code that solves actual problems and accomplishes the expectations of both clients and final users.
“There have been some experiments before, even since the 90s, with tools whose purpose was to generate applications”, explains Adolfo Cruz, Scio’s Project Management Director, and the best person to have an idea of where this technology is going. “If you wanted to generate a User Form, for example, you defined the parameters (first name, last name, age, date, etc.) and these programs delivered a simple but functional result.”
“Those very early tried, but they worked and now it’s evolving to full-on Artificial Intelligence. However, if these tools become a reality, they’ll probably lack the spark of human imagination. During development, a programmer sometimes gets ideas about cool features that could add value to a project, and these kinds of things will be difficult to achieve for a machine.”
“But beyond that, I think we’ll see software coded by machines. Maybe there will be a point when an AI can understand and interpret the user, getting a command like “create a chat program” and propose three options, which can be narrowed by the user.”
For sure, these three options would not take any time at all for a machine, but deciding which path to take from there, refining and redefining options, could be a tiring process, although, in terms of man/hours invested, it’ll need a lot less effort than having multiple people working on this same project.
“Still, there are a lot of questions unanswered”, Adolfo concluded. “How long would it take to explain exactly what you want, what frustrations would that cause, and how that impacts the adoption of this technology is a whole discussion to have. It’s not simply about technical feasibility, but acceptance among the public.”
