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.
with contributions by Ivan Guerrero Cardoso & Víctor Ariel Rodríguez Cruz.
It may seem like a pretty simple question, but how will your career look five years from now? What is your current goal? Because no matter if you are a junior, senior, or lead developer, the landscape of career progression is looking less like a straight path, and more like an open field of possibilities in which unexpected talents and skills can flourish.
So even if you are just starting out and trying to figure out your best course of action, or are a veteran whose path was full of unexpected twists and turns, we would like to ask you: what’s the shape you want your career in to take?
The Peter Principle
Now, before we start, here’s some context on why career paths have been getting more and more fluid, with skill sets becoming more diverse than ever during the last decade, and a good starting point is the infamous “Peter Principle” described by the Canadian educator Laurence J. Peter, which analyzes an issue that companies and organizations have been struggling with since times immemorial.
To put it in simple terms, the Peter Principle states that “a person that keeps getting promoted will eventually end up in a position beyond their competence, which will prevent them from further promotions, and thus keeping them in positions they fail at”, meaning that we all have a “competence ceiling” in our talents that we’ll probably hit sooner or later, depending on the career progression chosen. In more traditional companies this was a common issue when promoting people to a leadership position, like Management, where the best worker in a given department (let’s say, Sales) will be the first in line to get promoted when the opportunity presents, even if their best skill (selling) has nothing to do with the responsibilities of the promotion (in this case, managing people).
However, since this was the obvious career path for such a job, and rarely there was an alternative within the same organization, this meant that a person would have to “climb up” even if they had to stop doing the thing they were good at. Sometimes it worked out, sometimes it didn’t, and you can still see it today in programming and software development, where your best engineer, coder, QA, or tester excels because they are good and passionate at what they do, but, unless they explicitly seek to become leaders or managers, there is no guarantee of good performance in a new role with very different responsibilities.
Good companies, though, recognize this pitfall. “Careers are more organic today. Many organizations need a greater breadth of expertise and are encouraging employees to branch out, experiment with different functions, and become generalists rather than specialists. All of this opens new – and more – opportunities for people to grow, become engaged, and thrive at work”, says Skip Richard about the new realities of careers in the blog “Promotions are so yesterday”, which analyzes how career development is getting away from these traditional models, towards a more flexible approach. But what does this flexibility mean, and what does it look like in action?
The new realities of a career
What a lot of modern workplaces are trying to do nowadays is to get away from a linear concept of progress, offering their collaborators the chance to explore and develop new skills along with the flexibility to put them to use during a project. What if, for example, a senior Full Stack developer is interested in branching out to QA? Or if a member of the IT department wants to get into programming? Or what if a member of the marketing team is interested in learning to code?
“Career development used to be linear. It was all about that upward progression. Lateral – or God forbid downward – moves frequently reflected poorly upon ambitious professionals. […] Now, career development is much squigglier. People can move up, down and all around. They can go away and return – not something that was typical in the past”, continues the aforementioned blog.
And we are sure you have a pretty good guess on why this is the case; our relationship with work (and thus, careers) is changing, and following a single, inflexible path “forward” is less practical and realistic in a world that requires so much more from us, and the smartest organizations are those realizing that offering opportunities to explore new paths benefits us all.
“Until recently, I’d heard stories on the internet about software developers with peculiar paths, but never knew anyone like that. But then, one of my friends from high school, who studied Automation Engineering, started working as a software developer. Our CEO [Luis Aburto] has a background in Environmental Engineering, and some of the developers giving classes on the Apprenticeship told us about a couple of developers here with non-traditional paths, coming from Accounting or Chemistry. All these persons have inspired me to keep pursuing the career change I want”,says Iván Guerrero Cardoso, a Pharmaceutical Chemist who is currently an Application Developer Apprentice, a career he was able to pursue at Scio after discovering (and falling in love with) software development.
Stories like these are not uncommon at Scio and the software industry at large, and we will start to see how the ability to change paths not only will result in stronger organizations but in people less likely to get trapped in the Peter Principle, giving alternatives that let them explore their talents thoroughly.
“About a year and a half ago, I didn’t know anything related to software development as a profession — although I was already programming since a few years ago — and I found in Scio a place to learn, practice, and develop my skills even further. I’m also a follower of different web development personalities who has inspired me to try new things; I’d love to explore Web Development fully, Cyber Security is a topic I want to start leaning towards, and Videogame Development is an area where I’m constantly in the loop of the newest technologies”, says Víctor Ariel Rodríguez Cruz, a full-stack Application Developer at Scio, which touches on why this diversification is so attractive, beyond pure technical prowess: it lets us be part of a bigger whole.
The many dimensions of a career
“Humans have a deep need to connect, build relationships and be part of a community. Approached with intention, this can drive powerful career growth”, says Richards, and in the case of Scio, this idea of human connection [LINK] drives a lot of what we try to accomplish as an organization.
The reason is simple: in today’s world, where the ways we approach work are becoming more diverse than ever, Scio believes that investing in the personal growth of our collaborators, offering, among other things, paid technical courses, technical certifications, English classes, and our very own Leadership, Apprenticeship, and Sensei-Creati Coaching & Mentoring Programs to develop the hard and soft skills necessary to ensure the best collaboration between every developer, is the best way for a Nearshore Software Development company to foster the very best talent in Latin America.
This is a core part of the ways Scioneers can build their career prospects, encouraged by a culture of mutual support were learning a new skill can go from full-on coaching with someone with a vast experience to draw from, to simply asking for tips and pointers at informal meetings.
“Let me highlight the development dimension of ‘connection.’ This is one of my favorites, in large part because it’s become increasingly important in today’s distributed workplace”, continues the article by Richards. And this connection is built by also offering ways for our collaborators to develop the soft skills necessary to work on, collaborate or lead a team. Coming back to our example of the salesman becoming a manager, would it make a difference if such a promotion came with the coaching and tools necessary to learn how to handle a leadership position? The best way to give feedback, offer criticism, correct the trajectory of a project and balance the wants and needs of a team is not innate to many people, but that doesn’t mean it can’t be learned and developed.
Careers now need more than one dimension of growth, and Scio tries to offer the support to do just that: grow in the areas you want to.
Or as Ivan Guerrero puts it, about his own experience in the Scio apprentice program: “Not every company opens its doors to people without a strong computer science background, or without a related degree (which I understand, as it could be risky), therefore I’m hugely thankful with Scio for letting me join the team of apprentices where, as I see it, how passionate and willing we are to learn matters more than having an enormous amount of previous knowledge”.
The Key Takeaways:
Hitting the “Peter Principle” meant that a company didn’t offer enough options to choose from to advance a career, and that could lead to poor outcomes.
Today, a good company has multiple paths a collaborator can take, from traditional career advancement to coaching, to giving the opportunity to explore alternative options.
Career growth cannot happen in a vacuum either; a culture of collaboration can foster relationships that cross-pollinate knowledge and helps to open new paths to explore in a career.
Untangling how deeply our life changed during the Covid-19 pandemic will take a long time, and while we are still dealing with much of its aftermath, the process of planning the future doesn’t stop, even if we aren’t quite sure of what’s next for the industry.
“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.”
— Helena Matamoros, Human Capital Manager at Scio.
When it comes to the difference between junior and senior developers, drawing a clear line of separation is more difficult than you would think. On one hand, a developer with two or three years of experience could still be learning the ropes of different roles, while on the other, a developer with between 5 and 10 years of experience keeps learning new frameworks and technologies every day. So if years of experience alone aren’t the most reliable metric, what concrete characteristics differentiate between a junior and a senior?
This is an important question because determining where you stand is the first step to knowing where to take your career and how to make it happen, even if you find that an answer is not as easy to find. Forbes magazine in this article, for example, begins by analyzing knowledge as a metric of seniority:
“Career growth in software engineering (and many other areas) is determined by the depth of knowledge and the breadth of expertise. A project can scale both horizontally, and vertically – which requires a different set of skills and experience in practical applications following both patterns”, notes the article.
However, defining what this “knowledge” means and entails goes beyond mere technical proficiency; how both kinds of developers handle a project, their approach and the outcomes they offer have as much weight as everything else: “In practice, a senior developer […] can assess the risks, ask the right follow-up questions, determine the right workflow, analyze the possible bottlenecks and deliver a stable solution. A junior developer can solve a limited set of problems with a smaller subset of alternative solutions.”
Just like playing tennis
This concept of knowledge reminded me of an interesting essay about tennis that can help illustrate this idea more easily. Called “Loser’s Game”, and written by investment consultant Chares Ellis, this text evaluates the difference between professional and amateur players, sheding a light on the psychology of a person trying to master a skill.
In short, a professional tennis player wins by earning more points than their opponent during a match (playing a “winner’s game”), which seems to be a sensible strategy for a competitive sport. However, it comes into focus when you learn that an amateur player has the exact opposite attitude: they try to win by losing fewer points than their opponents, playing a so-called “loser’s game”.
In other words, a professional tennis player tends to be more offensive, risking more for higher rewards. An amateur player is more defensive, setting on “safe” strategies that result in fewer risks and thus, lower rewards. And this mindset comes from both players having very different perspectives on the game: a professional plays long term, focused on the final result only, while an amateur focuses on each play, paying more attention to the short term gains.
Translating this to software development, we can say that a professional focuses more on outcomes, or the final result of the development process, while the amateur deals in outputs, or the result of each individual step of the project, and one of the key steps in the path of becoming a senior developer (or tennis player, for that matter) is recognizing and overcoming the difference between both approaches.
“Senior developers realize that software is very complex. It’s not possible to identify all the requirements upfront, they will change, there will be more requirements found, and know the project is not likely to hit the deadlines, or the software will be wrong on the early iterations. This isn’t because of bad development, it’s because of the creative process of creating software. Junior developers take “wrong” software personally, even if creating the wrong software is the path to creating the right software”, explains the blog ITNEXT in their article about this topic.
This, more than anything else, is where a line can be drawn indicating the difference between Junior and Senior developers; beyond just knowledge (which informs every individual approach), the way both types of developers conceptualize development, as well as how they collaborate with the rest of the team, is the threshold.
“This question is somewhat difficult to answer”, says Helena Matamoros, Scio’s Human Capital Manager, when presented with the question of how Scio defines the required seniority for different positions. “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, such as leading teams, supervising the work of others, assigning tasks, reporting statuses, and visualizing obstacles in development, among other things. If you have been a developer for 10 years without these kinds of responsibilities, at least for Scio, you cannot be considered Senior.”
A quick start-up guide to seniority
Following this logic, then, we can begin to define a junior and a senior by the level of autonomy they can have during the development cycle of a product. This autonomy can include everything from technical knowledge (that is, how much supervision a given individual needs to complete a task), to their capacities to see the full picture of development (especially what concerns decision-making and direction of the project), so we can go back to the framework that the “Loser’s Game” essay defines for tennis players, as well as the characteristics defined by Helena, to start painting a broad picture of both types of developers:
Junior Developer:
Requires a higher level of support from their teammates.
Avoids making decisions without consulting superiors.
Weights risks in terms of outputs.
Prone to fixate more on the features of the product rather than its value as a whole.
Consider their mistakes a failure to avoid at all costs.
Less than five years of experience in a professional setting.
Senior Developer:
Requires a lower level of support, and may bring it to their teammates.
Is capable of analyzing the project and making their own decisions about its direction.
Weights risks in terms of outcomes.
Tends to consider more the value of the product as a whole.
Considers mistakes as a normal part of the process, and learns from them.
More than five years of experience in professional settings.
The last points in both definitions are included because even if the experience doesn’t dictate seniority, the skills necessary to act with autonomy, technical expertise, and leadership need time to develop, so engineers, programmers, and developers with a few years in their resumes are more likely to have the practice necessary to master this level.
This, however, is not a definitive list of characteristics, but an assessment of the behaviors that result from experience developing software, and it doesn’t even go into depth about the skill sets and knowledge that come from years of collaboration to bring the perfect outcome.
What we are trying to convey is that technical know-how is just the starting point; in collaborative environments where a team works with a client to achieve a specific goal, honing soft skills, getting comfortable with mistakes, bringing every learned lesson to the next project, and knowing how to manage expectations, resources, time and outputs is what a Junior developer needs to take the next step in their careers.
After all, growing as a developer is similar to growing as an adult; responsibilities get more important, you start paying attention to things you didn’t before, and before you know it, you are making your own way in the world. So what’s the next step you want to take?
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.
