The impact of empathy in software design: Is a single perspective always enough?

The impact of empathy in software design: Is a single perspective always enough?

Curated by: Sergio A. Martínez

Imagine you’re trying to use a new piece of software, but it’s just not working the way you want it to. The buttons are in the wrong place, the interface is confusing, and you can’t figure out how to do what you need to do. Now imagine that the person who designed that software is sitting right next to you, watching you struggle. How would that make you feel? Most likely, it would be pretty frustrating and uncomfortable.

Best-FinTech-Companies-in-2022

Now, imagine that same scenario, but instead of the software designer being a detached observer, they’re genuinely empathizing with your experience. They understand how frustrating it is to try to use something that isn’t well-designed, and they’re committed to making it better. They care about your success, and they want to help you achieve your goals. That’s the power of empathy in software design.

When designers take the time to understand the needs and goals of their users, they can create products that are truly helpful and easy to use. Empathy leads to better design decisions and ultimately results in a better user experience because good software design is about more than just writing code that meets the requirements of a project. It’s also about creating an experience that meets the needs of users, through empathy with their expectations. Empathy allows designers to put themselves in the shoes of users and understand their perspective to create products that offer a solution instead of making a problem worse. Without empathy, designers are more likely to create software that is confusing and difficult to use. Simply put, empathy is a crucial element of good software design.

However, how can a designer use the element of empathy properly? And what goes into understanding the perspective of a hypothetical user to create the best product a designer possibly can?

What is empathy?

Empathy Design Disorder 1

In today’s world, we are increasingly reliant on software to get through our daily lives. From ordering a coffee to communicating with our loved ones, there are few aspects of our lives that don’t involve some form of software, and thus, require a level of technology literacy that can overwhelm the average user if they are not used to it. With this level of dependence, software must be designed with a few things in mind. 

This is where empathy comes in. When we talk about empathy in software development, we are talking about the ability to see things from a perspective outside of the product itself. It’s not just about understanding what they want, but also why they want it. And it’s not just about users, but also stakeholders, project managers, and clients; they all have different roles to play and different perspectives to bring to the table, so empathy is essential for bringing everyone together and getting everyone on the same page. Only with this level of understanding can they create truly user-friendly products.  

Poor outcomes are more likely because the developers are out of touch with the users of their solutions. Like many who claim to be software “engineers”, they are not engaging in deep user empathy which ultimately leads to unappealing solutions. These engineers are implementers who are insensitive and largely oblivious to the people who use these tools and most important – why they need solutions. […] In my view, these “implementers” cannot work alone; they must be led and fed every element of the business and technical requirements with precision and detail.

This holistic view of development is what enables the creation of truly great applications. And in an age where we rely on software for everything, this empathy is a crucial element to reach the most successful outcome possible. Furthermore, anyone who has ever tried to use a piece of software that was clearly not designed with the user in mind, or when unclear communication throws a wrench that can derail a whole project, knows how frustrating it can be. 

These disconnects between the designer and the final user and everyone involved in a software development project, have been called Empathy Design Disorder (EDD) by Bill French, Chief Analytics Officer at Stream It Inc. In short, EDD stipulates that “user empathy is a fundamental part of building meaningful user interfaces. For some engineers, though, developing a highly sensitized capacity to inject the feelings and state-of-mind of a user can be challenging.

Getting into a different headspace

Empathy Design Disorder 1

But what does it mean to design software with the user in mind? Because it’s not just about making sure the software is easy to use; it’s about understanding how people think and what they need, getting into their headspace to discover which pain points are more likely to occur during the development and use of a software applications. This means constantly testing and iterating on the design, and when done right, user-centered design can make a big difference in the success of a software product.

Think about how the user is going to interact with it. What are their needs and how can your design meet those needs? It’s not enough to just create something that looks good on ‘paper’; you need to get into the headspace of the user and think about what they’re going to want to do with your software. This means considering things like usability, functionality, and even the emotional response that your design is likely to evoke. After all, they’ll be the ones using your product day in and day out, and you want them to have a positive experience. To that end, here are some starting points to use empathy in a software development environment: 

  1. Put yourself in your users’ shoes. Designing software with your user in mind can be challenging, as you may not share the same perspective, so thinking from the end user’s point of view is the only way to go. Ask yourself these questions: What do they need? What are their expectations? Do your best to answer these questions, so that your design meets their needs. You should also look for ways to add a personal touch to the design and make it easier for them to interact with your product or service. Overall, by taking the time to think from your user’s perspective, you will create something that will help build a strong bond between you and them.
  2. Pay attention to the details. Attention to detail is so important when it comes to the user experience of an application. Small details can make or break the usability of an application – after all, a great user experience needs to feel effortless and intuitive. An application that pays attention to even the smaller elements of design, such as how easily navigable its menu is or how visually pleasing it appears on different devices adds immense value for users. When designers are considerate enough to pay attention to these types of details during the development process, they end up creating applications that have the potential to become part of a user’s daily routine. Simply put, with great attention to detail comes greater success.
  3. Be responsive to feedback. If users are having trouble with your product, listen to their feedback and make changes accordingly. As a software designer, it’s essential to prioritize attending to the users, and taking time to consider the opinions of those who are using it, which is key in creating something that fits within their parameters. Listening to feedback also helps designers gain insights into how users approach solving problems and can help inform future design decisions. At times, it can be difficult to stay open-minded, but being proactive in addressing suggestions and concerns provides an excellent opportunity for creating even better applications. Ultimately, the success of any application depends on its users, so hearing them out is critical in making sure their expectations are met.

Empathy as an outcome

When developing any software, it’s easy to lose sight of the people who will be using the product, which is why empathy should be a core part of any software development project. After all, software developers create programs that are meant to be used by people and it’s important that these people feel genuinely understood. By baking-in empathy into the development process, developers can access a greater level of insight into what users want and need out of their experience with the software. This helps to ensure the product does not just solve problems, but also can be integrated into the lives of the users, making individuals feel appreciated and respected. Empathy in combination with skillful development leads to robust, user-friendly software that a wide range of users can enjoy and benefit from.

In other words, technology is meant to improve our lives, so by taking the time to understand what users need and how they may interact with the product, developers can design something with real impact, offering an experience that feels natural and intuitive, helping to boost satisfaction and creating a powerful sense of connection between users and software. In short, building empathy into every development project isn’t just good for users–it’s essential if you want to truly develop something impactful.

The Key Takeaways

Empathy Design Disorder 2
  • Software development is a delicate process where a lot of elements have to come together to ensure a positive outcome.
  • This makes it easy for a team to create an application that, theoretically, solves a problem, but in practice, nobody can use it effectively.
  • This can probably be due to a failure of empathy in the development process, which is failing to thoroughly consider the needs, expectations, and pain points of the average user.
  • By allowing empathy to be part of the development process, the result can only be stronger applications that not only solve a problem but also integrate with the experience of the user, the mark of a successful product.

Scio is an established Nearshore software development company based in Mexico that specializes in providing high-quality, cost-effective technologies for pioneering tech companies. We have been building and mentoring teams of engineers since 2003 and our experience gives us access not only to the knowledge but also the expertise needed when tackling any project. Get started today by contacting us about your project needs – We have teams available to help you achieve your business goals. Get in contact today!

Productivity Ratio: Understanding the “invisible work” of software development

Productivity Ratio: Understanding the “invisible work” of software development

Curated by: Sergio A. Martínez

We know that software development is not all just coding. As with any big project, there are plenty of tasks that must be fulfilled to create an effective end product, such as stakeholder supervision, decision-making, problem-solving, communication, and time management. Which is why it is  essential to have a clear understanding of the business goals of the software being developed, while also analyzing and interpreting the user requirements that must be worked into the development phase.

When-Excel-is-not-enough-icono

That’s part of the reason why productivity in this context is a tricky thing to track. Sure, you can see how long it takes to reach the end goal and measure it against timelines and expectations, but that doesn’t take into account all the nuances of software creation, as well as the challenges of debugging, refactoring, tweaking, editing and other tedious but crucial elements of every successful project. And this is further complicated by progress not always being linear — as soon as you start working on a project, it’s almost certain things will follow their own kaleidoscope-like paths that don’t always make sense from the outside. 

With all that, it might seem that tracking productivity is like nailing jelly to a wall: not an easy task by any stretch of the imagination, and sadly without a one-size-fits-all solution. Doing the required following isn’t impossible, though, but it requires finesse and forethought to obtain meaningful results. It also requires being aware of the “invisible work” going into the development of an application, and it requires having a complete understanding of how that many pieces fit together. Unfortunately, for some teams, ignoring the tediousness of tracking productivity can be seen as more desirable than going through the hassle. However, with the correct approach, any team can achieve such a goal.

Getting ratio’d

Productivity Ratio

Working with other professionals like designers, business analysts, or testers, is part of every software development project, so good collaboration skills are necessary to reach any goal. Furthermore, making sure that the tools you are using are appropriate for the task ahead can have a dramatic impact on how successful the project would turn out to be in the long run. All these requirements mean that a positive outcome demands a spectrum of skills, which makes the whole process more challenging, and not all of them are obvious at a first glance. In the words of this Crossing the Equator article:

This invisible work increases the communications gap between the hidden, almost abstract world of coding on the one side and that of marketers, purchasers, and investors on the other. It’s a gap that can cause frustration and misunderstanding and can lead to employee turnover and a slowdown of business growth. It is usually the responsibility of engineering leaders to close this gap.

In other words, measuring «invisible work» can be difficult due to the complexity of any project. While time and effort can obviously be used to gauge progress, many intangible elements must be factored into the equation, but it’s hard to quantify the value of research, problem-solving strategies, code refactoring, and investigating emerging technologies that all help to improve software quality. In addition, developers must often adjust their efforts on the fly if stakeholders change their expectations or new information comes in. As a result, measuring invisible work requires an experienced team who understands what needs to be tracked and how to factor it into the overall process. And one of the more interesting approaches to this comes from a very simple formula: productivity ratios.

Productivity ratios in software development are the gauge by which you measure whether or not a process is successful, indicating the amount of work completed versus the amount of time and effort expended. In other words, it looks at how much time and resources have been invested in a project, such as coding and bug fixes, against the end result. The productivity ratio, consequently, it’s an important metric for gauging how effective a development team is at producing quality work. And understanding how to calculate it can be an invaluable tool for ensuring a project’s success. The formula to do so can be expressed as the following:

productivity ratio

The tricky part, however, is how to define what the input and the output mean in the context of development. The most common approach is looking at the basic resources that go into the project (work hours, number of developers, cost per hour, among others), against a specified result, like development milestones reached, user stories, pull requests, and many others, with the general idea that something is being produced continuously. 

The result of the equation is then compared to a baseline (industry standards, or past development story, for example) to obtain an estimate of the total productivity of a given team. But how does this tie back to the invisible work involved in software development? Coming back to the Crossing the Equator article:

It’s a human-focused thing. It also applies to collaboration, knowledge sharing, and team-building activities. Successful organizations build products that customers love, which can only happen when the right people are involved and treated correctly. Teams cannot afford to hire people who merely hit the keyboard to write code without any profound understanding of or connection to the end user. Understanding the business means understanding its processes and goals and ensuring full team alignment.

A different way to look at development

Productivity Ratio

In short, without a holistic view of development, a productivity ratio cannot work as is because a lot of the effort is not directly apparent in the final product (like planning, writing documentation, ensuring clear communication between stakeholders, managers, and developers, implementing and maintaining the adequate tools, observing security, refactoring the code, etc.), but it’s required to guarantee the timely delivery of a product, its quality, and the overall success of it. 

After all, putting all the focus on coding is not enough and in fact can lead to disaster if other aspects of the project such as design, testing, debugging, and the actual use case are not taken into consideration. Without properly assessing these elements a lot of issues can arise while rolling out the software to customers resulting in wasted effort and resources. That last part is key: developers should take an all-encompassing approach by focusing on the final users as the overall destination of the whole process, and what they are getting from the whole ordeal is, perhaps, the most important point of all. Consequently, an effective productivity ratio should be defined less in terms of input/output, and more like:

productivity work

The core of this approach is to stop seeing the development process as an isolated black box where effort goes in and results come out, and instead get into a mindset of the “total work” output by a team against what the client and final user will be receiving. This should not just be an abstract idea but rather a value that’s central to all efforts during production, helping align everyone with a clear goal. Additionally, when strong ties exist between a software development team and its users, trust is established allowing for up-front feedback before any changes or upgrades would be made, all but ensuring that technical implementations fit with user expectations. Bottom line – all software development projects should prioritize the user experience, helping teams align their efforts from day one. Making sure everyone understands and is deeply invested in this user focus allows for more meaningful and consistent collaborations internally, bridging the gap between the visible and invisible work. Ensuring there is a clear baseline for the productivity ratio, will end up manifesting into an ideal, successful product that satisfies users completely.

The Key Takeaways

  • Productivity is always an important concern for any software development project because it can give a clear picture of the effort and resources put into development.
  • One of the biggest challenges of tracking productivity is the “invisible work” involved in creating a successful application, which is never obvious in the final product.
  • A successful approach might be the “productivity ratio” that measures the input against the output of any project, but it needs to be used carefully to consider invisible work.
  • To that end, keeping the focus on the final product that the user will be receiving can give a better idea of the productivity of a team, comparing the ratio of effort put in versus what the user will be getting.

Scio is an established Nearshore software development company based in Mexico that specializes in providing high-quality, cost-effective technologies for pioneering tech companies. We have been building and mentoring teams of engineers since 2003 and our experience gives us access not only to the knowledge but also the expertise needed when tackling any project. Get started today by contacting us about your project needs – We have teams available to help you achieve your business goals. Get in contact today!

Is LEGO a programming language?

Is LEGO a programming language?

Curated by: Sergio A. Martínez

He used to make his house out of whatever color [LEGO] brick he happened to grab. Can you imagine the sort of code someone like that would write?— Daniel Underwood, “Microserfs”, 1995

It can’t be denied that computer programming is a very fascinating topic. There’s something undeniably appealing about the mix of creativity and logic it demands, allowing anyone to bring their ideas to life. Programming, essentially, is a puzzle where you can piece together code until everything works right, with the final result of a digital object that works tangibly, and there’s a great sense of satisfaction that comes with that. It’s no wonder that so many people find computer programming so captivating to learn.

When-Excel-is-not-enough-icono

Another thing that makes programming fascinating is the fact that it’s always evolving; there are always new languages to learn and new challenges to tackle. For many people, computer programming is the perfect blend of left-brain and right-brain activity, and it’s this balance that makes it so compelling. And whether you’re just getting started or you’ve been coding for years, there’s always something to discover. However, why is the idea of programming so seemingly exclusive to digital spaces? Or is programming, as a concept, beyond what we see on our screens?

Because, as we move towards a future where software and technology are involved in everything we do, the idea of “programming” seems less of an abstract concept, and more of a natural part of our reality, and the same principles can be found in the unlikeliest of places. But what is programming in the physical world? And why stuff like Lego is a great gateway to understanding and getting passionate about something as complex as programming?

Programming in physical spaces

When Excel is not enough 2

Have you ever noticed that Lego plays a far more important role in the lives of computer people than in the general population? To a one, computer technicians spent huge portions of their youth heavily steeped in Lego and its highly focused, solitude-promoting culture. Lego was their common denominator toy.” 

These words come directly from the 1995 novel Microserfs by Douglas Coupland, which portrays the lives and concerns of various Microsoft programmers in the early 90s, prior to the release of Windows 95. The novel has been pretty popular since its original publication because it’s a very thorough look at the nascent class of “software people” that was quickly growing during this decade. Simply put, much of the modern software development culture, when early startups like Microsoft made the jump to a corporate existence, started at this time, and many of the insights exposed in the novel still resonate today. 

For example, let’s see the main argument here, which comes from a character waxing poetic about these popular building toys. The core idea here is that Lego bricks are a binary system, where each of the studs in a brick is either connected to another or they are not, enabling anyone to build something concrete. In that sense, Lego bricks could be conceived as a programming language of sorts, with the resulting “application” being a tangible object, like a rocket ship, a house, or whatever you want. As the book explains:

Lego is ontologically not unlike computers. This is to say that a computer by itself is, well… nothing. Computers only become something when given a specific application. […] To use an Excel spreadsheet or to build a race car, that’s why we have computers and Lego.

That is not a far-fetched idea, mind you. More complex programs can involve hundreds or even thousands of lines of code, but they all operate on the same principle: single interconnected elements whose logic dictates the final result. And by providing a set of unambiguous instructions, programmers can get computers to perform virtually any task they can imagine. In that same sense, to build something with Legos, you need to have a clear understanding of how the individual pieces fit together; just as a programmer needs to have a strong understanding of syntax to write code, a Lego builder needs a strong understanding of how the pieces fit.

Of course, writing effective programs requires more than just a basic understanding of how to give instructions. It also requires an awareness of the many different ways that something can go wrong. A well-written program anticipates the needs of its users and anticipates the ways that the program might be misused. By anticipating these potential problems, programmers can write robust and user-friendly code. Some would argue that Lego is not a true programming language because it does not allow for abstraction or complex logic. However, there is no denying that Lego represents a powerful system for creating and manipulating physical objects. In many ways, it is similar to the way that code can be used to create and manipulate digital objects. As such, it is safe to say that Lego can indeed be considered a form of programming.

A world built on code

Is LEGO a programming language 2

Now, when most people think of programming languages, they think of computer code like Java or Python. However, programming languages are not just limited to computers. Any system that uses a set of instructions can be said to use a programming language, and while computer languages may be the most common type of programming language, they are by no means the only kind.

Back in the day, for example, long before digital computers were a thing, people used analog machines for everything from navigation to weather forecasting. These machines were operated by physical variables like electrical current or fluid pressure, which could be used to represent, store, and process data. Analog computers were often used for agricultural applications, as they could predict things like sunrise and sunset times, moon phases, and tides. In some cases, they were even used to control irrigation systems. And while analog computers are no longer in widespread use, they did play an important role in the development of digital computing.

Analog computers were around for centuries, and although their use has declined in recent years, we can still learn a few tricks from them. For example, these computers are far better at handling continuous data than digital computers because they can represent it more directly, using physical quantities such as voltage or current. As a result, they are often used in scientific and engineering applications where continuous data is common. In addition, analog computers are usually much faster than digital computers when solving certain types of problems because they can perform many operations in parallel, whereas digital computers typically process information sequentially. 

What we are getting at is that we have always lived in a world built on code, where even the simplest expressions of it, like Lego bricks, can have an impact on the way we see and interact with our reality. Although the insight of Microserfs about Lego being analogous to programming might seem odd on first viewing, considering how the field of software development is growing by the day, and evolving just as quickly. Our love of programming probably has a simpler origin than we thought. 

I think it is safe to say that Lego is a potent three-dimensional modeling tool and a language in itself. And prolonged exposure to any language, either visual or verbal, undoubtedly alters the way a child perceives the universe […] The charm and fun of Lego derives from reducing the organic to the modular: a zebra built of little cubes.

And with the modern world increasingly reliant on computer code, from the websites we browse to the apps we use, there’s something special in seeing its magic present even in the simplest of things. To code, in simple terms, is human, becoming the main way we conceptualize our reality and build something on it. Be it a humble Lego brick or a complex chain of code, it’s difficult to overstate the presence of code in our modern lives. And as long as there are people who need to solve complex problems, programming will continue to cast its spell everywhere we look. In many ways, our future has always depended on it.

The Key Takeaways

  • We always think of “programming” as something that only happens inside computers, but that might be far from the truth.
  • If we look at the basic concept of programming, then it’s no surprise to see it everywhere else, and Lego is a great example of it.
  • Lego can be conceptualized as a programming language, where each brick connects to build an application.
  • That’s because programming goes beyond a computer, and our world has been built on analog machines that predate everything digital.

Scio is an established Nearshore software development company based in Mexico that specializes in providing high-quality, cost-effective technologies for pioneering tech companies. We have been building and mentoring teams of engineers since 2003 and our experience gives us access not only to the knowledge but also the expertise needed when tackling any project. Get started today by contacting us about your project needs – We have teams available to help you achieve your business goals. Get in contact today!

Do you want to be a great software developer? Embrace a Growth Mindset

Do you want to be a great software developer? Embrace a Growth Mindset

Curated by: Sergio A. Martínez

What makes one a great software developer? When you work in a field where there is no “right” way to do things, this can be a pretty important question. Some say that the best developers are those who can find creative solutions to difficult problems, willing to experiment and take risks, always learning from their mistakes. Others say that a great developer has a strong understanding of the latest technologies and trends, enabling them to think outside the box and come up with new and innovative ideas. And yet others say that a good developer is simply one who writes good, stable code with discipline and consistency.

Cloud-Computing-2023

Of course, all of these are very good qualities for a software developer to have, but here at Scio, we think that there’s something else involved, a “secret ingredient” of sorts that every developer can have if they put in the necessary effort and that we encourage as often as we can: a growth mindset.

What is a growth mindset? Simply put, it’s the belief that intelligence and ability can be developed through hard work and practice. It means having the ability to constantly learn new things, adapt to new situations and be open to feedback with a willingness to experiment. It’s never getting too comfortable with your skills because the industry is always changing. We believe that the best developers are always learning, always growing, and always looking for ways to improve.

The research of Stanford University psychologist Carol Dweck has shown that people with a growth mindset are more likely to persevere in the face of setbacks, take on challenging tasks, and embrace failure as an opportunity to learn. With this, you can see why any great developer would know that having a growth mindset is critical for success. Your skills can be developed through hard work, determination, and persistence, and this mindset allows you to approach challenges with a positive attitude and the belief that you can overcome them. It also gives you the chance to learn from your mistakes and view “failure” as an opportunity to evolve. Without a growth mindset, it is easy to become discouraged when faced with difficult problems or to give up when encountering setbacks. Getting yourself into this headspace will leave you better equipped to continue growing as a developer.

Developing a growth mindset

The rise of the industry-specific Cloud: Here’s everything you need to know

As we said, a growth mindset believes that intelligence and talent are skills that can be developed, rather than static traits that you’re born with. The latter is known as a “fixed mindset”, which maintains that ability is static or predetermined, and there’s little you can do to change that. In other words, it’s thinking in terms of “natural talents” instead of “acquired skills” that can dissuade a lot of people from learning and improving an aspect of themselves, leaving them stuck in place. 

The idea of “natural talent” is very powerful. It’s often used to describe someone good at something seemingly without any effort, a sort of “Life’s Lottery Winner” that either you are, or you aren’t. However, this is far from the truth; what we call «talent» is simply the result of hard work, practice, and dedication, so anyone can become good at anything if they are willing to put in the time and effort. The belief that some people are born with inherent abilities, while others are not, is nothing more than a harmful myth, discouraging people from trying new things and pursuing their goals, because they believe that they will never be as good as those with «natural talent», no matter what. In reality, everyone has the same potential for greatness, but it’s up to each individual to get into this mindset.

But how to shed this worldview and embrace the idea that you can always learn and become better? How can you develop a growth mindset to become the developer you always wanted to be? Well, the most important thing you should know is that having a growth mindset is not always an innate attitude for most people, so it requires effort to get one. We all have a specific aspect of our personality somewhere that we believe impossible to change, that is just “part of who we are”, making us likely to give up in the face of adversity, stick to familiar tasks, and see failure as a reflection of our lack of ability, which is rarely the case. Recognizing the presence of this “fixed mindset” is the first step to start improving.

With that in mind, you should start by practicing self-advocacy. This is the ability to communicate your wants and needs to others, which requires an honest assessment of your strengths and weaknesses. Doing so makes it easier to identify areas of opportunity where you can improve a skill or learn something new. In software development, for example, you need a lot more than just writing good code; you need to communicate with the client and your team effectively, understanding their needs and challenges, and in a Nearshore company like Scio, often in a different language than your native one. All of these skills require time and commitment to master, so to get started…

  1. Make a list of all the skills you use daily, both hard and soft (tools, frameworks, platforms, and programming languages, for example, as well as stuff like planning, communicating with others, giving feedback, etc.)
  2.  Make a note of which ones you feel completely confident about, and which ones require more effort on your part. 
  3. Try to see what’s the difference between these skills: maybe it’s the amount of practice you put into it, or maybe you feel more interested in doing one rather than the other. Maybe you never had the chance to use that skill before.
  4. Apply self-advocacy to find the help you need to bring these skills up. Sign up for a course, ask a more experienced friend, or make the time to improve.

By understanding what you’re good at and what you need to work on, you can set yourself up for success”, says Luis Aburto, CEO and Co-Founder of Scio. “If you’re aware of your weaknesses, you can take steps to improve them. And if you know your strengths, you can use them to your advantage. Which is an essential quality if you want to grow and evolve as a developer. By taking the time to understand what makes you tick, you can set yourself up for success both now and in the future.

However, even after doing all of this, we understand that this growth doesn’t happen instantaneously; it requires a continued effort and the support of everyone in your environment to reach your maximum potential as a developer. This is why choosing to collaborate with an organization that takes growth seriously is just as important as recognizing your need to improve your skill set. After all, what good comes out of knowing your areas of opportunity if you don’t have the chance to act on them?

Growing together

Growth Mindset 6

However, a true growth mindset goes beyond simply believing that you can get better by just expanding your knowledge or your technical toolset. It involves taking the initiative to explore new skills and going through learning experiences outside of your “comfort zone”. In a previous blog, we talked about how actual “comfort zones” are less about getting stuck on a single place, without feeling the need to go beyond it, and more about expanding your areas of expertise, getting comfortable in areas of software development that are just as important as technical knowledge, but demand a very different kind of effort. Soft skills like  communication, negotiation, problem solving, teamwork or strategic thinking that will help you become a well-rounded developer. Going into places you have never gone before is how a person truly grows.

That’s why it’s so important to work with people that help you improve all your skills, or with an organization that provides opportunities for skill development outside of what you thought possible before, commiting to create a strong team capable of taking on any challenge. Companies like Scio, for example, know the value not only in offering workshops, courses, and programs like Sensei-Creati, but also in letting developers “stretch their legs”, so to speak, with assignments and responsibilities that might help them develop a new skill, like letting a Senior take the Lead in a project, or allowing people that not normally interact with the client to have a more “first hand” experience” to practice communication and planning. Actions like these allow taking something you are not “skilled at” and practice it to perfection on a daily basis, even if it’s outside of your normal interests. That’s how we participate in the creation of well-rounded developers capable of joining any team and overcoming any challenge.

So, to get back to our point, a growth mindset is essential for any software developer that wants to be excellent at their craft. With this mindset, you will never stop learning and expanding your skillset, always looking for new challenges to conquer and ways to improve yourself. If you can adopt a growth mindset and let go of preconceived notions about what you are and aren’t good at, you will set yourself up for success as a great software developer. And We will always be in need of those.

The Key Takeaways

  • A good software developer knows that the key to greatness is always improving your skills and learning new things.
  • To achieve this, you need to get into a “growth mindset” where improving is a continuing process that never stops.
  • To get this mindset, myths like “natural talent” or that there are things about yourself that cannot be changed need to be left behind.
  • However, doing this by yourself can be difficult, which is why you, as a developer, should choose to collaborate with a company or organization that sees the value in growing and learning at every step.

Scio is an established Nearshore software development company based in Mexico that specializes in providing high-quality, cost-effective technologies for pioneering tech companies. We have been building and mentoring teams of engineers since 2003 and our experience gives us access not only to the knowledge but also the expertise needed when tackling any project. Get started today by contacting us about your project needs – We have teams available to help you achieve your business goals. Get in contact today!

Thinking of software development budgets for 2023? Here are three approaches you should know about.

Thinking of software development budgets for 2023? Here are three approaches you should know about.

Curated by: Sergio A. Martínez

If you’re serious about succeeding with your software development projects in 2023, you need to start budgeting for them now. It’s no use waiting until the last minute and hoping that everything will work out – it rarely does. Not only will you have a clearer idea of what you need to spend, but you’ll also be able to start making savings where possible, which may be an important concern going into the next year.

Thinking-of-software-development-budgets-for-2023 icono

After all, 2023 is shaping up to be a challenging year for the software industry, with several factors coming together to create a perfect storm of sorts. First, the overall economic picture is uncertain, with slowing growth in developed markets and an ongoing trade war making it difficult for companies to plan for the future. In addition, new emerging technologies, like AI and cloud streaming, are threatening to disrupt traditional business models, and the political environment is becoming increasingly challenging to navigate. As a result, 2023 is likely to be a year where companies will need to be agile and adaptable to survive and thrive.

With all that in mind, it’s never too early to start planning for success, and budgeting properly for your development expenses today will be a critical element of that. However, budgeting for your development expenses now can be easier said than done. When it comes to producing software, there are a lot of moving parts, which makes budgeting a bit of a challenge. For one thing, you have to account for the cost of the software itself, as well as the cost of any licenses or subscriptions that may be required, then there’s the cost of hardware, which can vary depending on the needs of the project, and don’t forget about the cost of training and support. Add it all up, and it’s no wonder budgeting a software development project can be so complicated. Of course, there are ways to simplify the process, but at the end of the day, it’s still important to have a clear understanding of all the costs involved. Otherwise, you might find yourself in over your head – and that’s never a good place to be.

Designing a software budget in 2023

Thinking-of-software-development-budgets-for-2023 2

Let’s talk about numbers first. According to this article from The Harvest Blog: “Your project team members won’t have the necessary resources they need if you can’t secure the right funding. And if you don’t have a set plan from the start, you run the risk of joining the 57% of companies who say they don’t typically complete their projects within the established budget.” And with the challenges that 2023 will bring to the industry, reaching these goals will be critical.

So, if you’re serious about achieving your development goals, budgeting is a step that you can’t afford to avoid. By starting to budget for your development expenses now, you’ll be in a much better position to succeed. And you may already have a couple of traditional approaches to doing so, like the “Envelope System”, which involves assigning specific amounts of money to different spending categories (like licensing fees, cloud-based storage, subscriptions of all kinds, etc.), or the “Zero-based budget” that requires you to account for every single penny you spend. Nevertheless, when it comes to software development, these might not be enough. 

The traditional approach to budgeting assumes that all projects can be planned and executed linearly, with predictable costs and results. But software development can be anything but predictable; it’s an iterative process, where changes and improvements are constantly being made based on feedback. This means that software development teams need to be able to adapt their plans on the fly, which can make it difficult to stay within a fixed budget. In addition, the rapid pace of change in the technology industry means that teams often have to scrap their plans and start from scratch if they want to stay ahead of the competition.

Whichever approach you decide to use, the important thing is that you start budgeting for your development expenses now; 2023 is around the corner, and with it comes a new year of projects and innovations to look for. As always, software organizations of all kinds will be looking to stay within their budget while delivering quality products, with some basic tips that can help you to do so:

  • Use an agile development methodology. This will allow you to break the project down into smaller pieces and deliver them incrementally, which can help to control costs.
  • Make use of open-source software. Many high-quality open-source options can save you money on licenses and support fees.
  • Take advantage of cloud computing. Cloud-based solutions can be a cost-effective option for hosting and running your software.

But beyond these common-sense suggestions, the correct approach of an organization to budget for a software development project depends on a variety of unique challenges and goals. So, we’d like to present some budgeting techniques that can ensure that your software project stays on track, making a positive outcome more likely for any software enterprise. For example…

  • Bottom-up estimating: This is a great way to avoid any surprises when it comes time for your team’s final budget. Essentially, it’s about working closely with the team and examining each step of the project to the most minute detail, to ensure that you have all the important information laid out to create an accurate roadmap. This process helps ensure no hurdles come up later down the road, which ultimately saves money by having fewer unexpected costs associated with these «known problems» during development. 

  • Top-down estimating: Top-down estimating is a more efficient way to budget for large projects. By looking at the scope as an entire entity, you can identify which tasks will take up most of your time or resources without having any uncertainty between them. This allows us to estimate costs with greater accuracy than the “bottom-up” technique, allowing an organization to know exactly what work needs to be done first. The key difference between “Top-down” and “Bottom-Up” estimating lies in how much detail goes into each stage: With the top-down method, all elements must be defined upfront. However, some flexibility when deciding upon specific costs should remain.

  • Analogous estimating: A great way to get an idea about how much your project will cost when you don’t have enough data for the upcoming task. This technique only works because it relies on previous projects as references, so keeping its accuracy depends largely upon what information there was available from those jobs. That’s why reports, notes, feedback, and the information collected in project management systems can be so valuable to implement, allowing tracking of internal costs and reviewing past work while informing future scope decisions all at once, making sure every penny counts.

Final words

Thinking-of-software-development-budgets-for-2023 3

It’s no secret that software projects can be costly. All too often, companies find themselves over budget and behind schedule, scrambling to contain the costs of their project. However, with a few strategies like the ones we just mentioned, costs can be kept under control. However, there’s no better strategy to plan your software development budget than managing expectations about the outcomes, clearly communicating the scope of the project and what will be delivered at each stage. 

This will help your organization to avoid scope creep and ensure that everyone is on the same page from the start. By following these simple strategies, companies can ensure that their software projects stay on budget coming 2023.

The Key Takeaways

  • The software industry, alongside the rest of the technology sector, will have a challenging 2023, for a variety of reasons.
  • One of the crucial elements of any company’s success is budgeting projects and operations sensibly, ensuring that an organization can meet all the goals it needs.
  • However, software development can be somewhat finicky when it comes to planning, so traditional approaches to budgeting might not cut it out; rather, a holistic view of the whole process can be the right way to plan any expense.
  • It’s important to keep in mind past approaches in order to understand where the biggest challenges might come when budgeting for the new year.

Scio is an established Nearshore software development company based in Mexico that specializes in providing high-quality, cost-effective technologies for pioneering tech companies. We have been building and mentoring teams of engineers since 2003 and our experience gives us access not only to the knowledge but also the expertise needed when tackling any project. Get started today by contacting us about your project needs – We have teams available to help you achieve your business goals. Get in contact today!

Normalization of Deviance: What to do when human nature collides with procedures in the workplace.

Normalization of Deviance: What to do when human nature collides with procedures in the workplace.

Curated by: Sergio A. Martínez

Let’s think of the following example: imagine a brand-new bridge connecting two highways over a river. This highway sees a lot of traffic, including transport trucks that must pass from one side to the other daily, which tend to have a weight, on average, of about 25 tons. Thus, they mark the bridge accordingly: Limit Weight: 25 tons. However, the engineers know that they need a safety margin to ensure that the bridge doesn’t stress and wear out too quickly, so it’s designed to actually support up to 35 tons. It all seems good until one day, ten years later, the bridge collapses; a 40-ton trailer tried to cross it, and a tragedy occurred.

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

It’s easy to point a finger at the culprit, right? That truck was way too heavy for this bridge, so we need to build sturdier bridges and think of a system that checks if a truck has the appropriate weight before crossing. Maybe even instill punishments and fines for people going over this limit. Easy stuff. Well, if that’s the case, then nothing was learned from this disaster. It will happen again in the future.

This is normalization of deviance. Simply put, it’s when people become so accustomed to seeing certain things done wrong that they no longer register as problems, but instead as the way “things work”. And they do work, until the day they don’t: catastrophic failures like a bridge collapsing are seldom the result of a single, unavoidable act of God, but instead the accumulation of small problems that one day reach a breaking point.  And normalization of deviance is a huge problem in the software development industry. 

However, how exactly does the normalization of deviance work, how does it affect software development, and what could be the steps to mitigate, or outright eliminate, the risks it presents?

Bending the rules (until they break)

Normalization of deviance

Software and civil engineering are not that different, at least when it comes to the complexity and precision needed to build things. After all, engineering of any kind is the art of finding solutions that work under stress: creating stuff that works reliably, no matter who is using it. So, no matter if you work with code or concrete, the process is roughly the same: you need to take into account every single situation that the design demands. And thus, both disciplines also tend to have very similar problems, with the normalization of deviance being one of them.

Let’s go back to our bridge example: what was the actual problem? The truck was way too heavy to safely cross that bridge, for sure. But why was such a truck trying to cross it in the first place? Because simply put, it was a normal thing to happen, and if that sounds like a contradiction, you would be right. After all, the normalization of deviance is a lesson in human nature.

People like to bend the rules. That’s what we do. Intellectually, we know rules are meant to keep things working properly, but rigidity is not our strong suit as a species. In the words of veteran programmer Foone Turing: “We always want to optimize. We want to do things cheaper, quicker, and more at once. And the thing is, most of the time going a little faster, a little hotter, that’s fine. Nothing goes wrong. Engineers always design with a safety margin, as we’ve learned the hard way that if you don’t, stuff goes wrong very fast. So going 110% as fast as the spec says? probably OK.

So, you may see where this is going. In our bridge example, an interesting wrinkle is that the disaster didn’t happen right away, it was a full decade after the bridge was constructed. That’s the tricky thing with the normalization of deviance: it takes time to build up. It works through subtlety: if your bridge says that it has a limit of 25 tons, but you once drove a 30-ton truck through it and nothing happened, then the actual limit is higher, right? You can do it again. And if you do it enough times?

You’ve been going 110% all the time. It’s worked out just fine. You’re doing great, no problems. You start to think of 110% as the new normal, and you think of it as just 100%. […] Then one day you’re running into 5 other problems and need to push something, well, maybe you do 120% today? After all, it’s basically just 10% of normal…”. That’s how you get a 40-ton trailer trying to cross a bridge rated way lower than that: someone drove through it with 35 tons of cargo, and nothing happened. 36 should be fine, right? Or 37, or 38, and so on. Bending the rules became so normal, without any immediate consequence, that it ceased to be wrong. Slowly, it became the standard, and a standard supported by bent rules is always a time bomb.

But how to avoid deviance?

Normalization of deviance

In software development, the normalization of deviance can happen at every level. For example, at a product level, it’s not exactly unheard of to release software that is not fully tested, on the assumption that the bugs will be fixed in future releases, which can lead to serious problems, such as data loss or security vulnerabilities. At the development level, programmers can start to disregard code style conventions if they feel slowed down by them (there’s a deadline to meet after all), resulting in a codebase that is difficult to read and maintain. And at the security level, it’s often easier to just write down a password than wait half an hour for IT to reset your account if you forget it. In either case, the result is the same: an organization will start accumulating issues until something serious breaks one day.

However, diagnosing the normalization of deviance can be difficult because there’s no immediate feedback loop to it. The bridge probably doesn’t produce a loud cracking sound if you go a couple of pounds above the limit, or the code doesn’t stop working immediately if you deviate a little from a style convention, so implementing effective ways to detect when it’s happening, or to deter this kind of behavior, can be tricky.   

The aforementioned Twitter thread gives a great example of why: “Susan gets in trouble because she put a post-it note with her password on her monitor, and we had to sit through a boring security meeting about password security. So, people learned to put their passwords in their wallets and their phones.” Or in other words, maybe the systems we have in place provide the incentive to deviate from the rules in the first place, and having after-the-fact measures don’t do enough to stop the buildup of problems. In that case, it falls on the culture of an organization to take into account these possible challenges and take the steps necessary to avoid lowering standards as a normal practice. These four key points might help:

  1. Rules are not forever. When it comes to technology, a year might as well be a decade in terms of advancement and innovation, so every procedure and workflow must be constantly reviewed to ensure “rule-bending” is not encouraged when certain parts lag behind, becoming obsolete or just ineffective. Revising and streamlining are always valuable skills for the leadership of any company to have, and giving people the power to always ask “why” could help avoid problems down the line.
  2. Open communication is critical. In that same sense, the main danger of deviance is that it develops in secret. Effective project management means communicating effectively with people, making clear the purpose of every rule, and being open to opinions, suggestions, and discussions to ensure those rules are effective and followed. Also, promoting an environment where a developer can communicate when a rule must be broken for the good of a project is crucial, as it allows management to respond and control such changes. “This situation has happened to us in the past”, says Jesús Magaña, Senior Project Manager at Scio. “And this decision has never been taken lightly. The objective, after all, is reaching the finish line without compromising quality or performance. This ‘shortcut’ has to be done with the consent of the Project Manager and the client, keeping in mind the possible consequences of doing so.”  
  3. Any change has to be clear and well-thought. The software sector is also ripe for new technologies, frameworks, languages, and tools to be implemented during development, but these changes are not trivial. If a new element is adopted within the development environment without proper measures (like clearly explaining the benefits and drawbacks of the new tool, giving people enough time to acclimate to change, being open to concerns, etc.), the risk of deviance grows.
  4. A culture of collaboration, not politics. Probably the most common cause of normalization of deviance, many of these examples don’t happen in isolation. Humans are social beings that tend to form cliques and in-groups that cover for each other, which can happen at every level of the organization, and thus be the perfect place to brew deviance that could snowball into disaster. So, promoting collaboration, being lenient enough with consequences so people feel comfortable about speaking up, but not to the point that developers feel they can get away with anything, and frequently promoting people to mix and work together in different configurations might be the key. It all comes down to skilled leadership.

And knowing is half the battle

Normalization of deiance

However, let’s not assume that these steps, although useful, are completely infallible when it comes to mitigating the normalization of deviance because this kind of behavior is simply human. We bend the rules when we know we shouldn’t, even at a personal level sometimes (“I’m on a diet, but this piece of cake shouldn’t be a problem, right?”), but that doesn’t mean that we cannot anticipate, learn, and improve at every opportunity. Understanding this is what separates good software organizations from the rest of them. After all, as Jesus Magaña tells us, “one of the values of the Agile Manifesto establishes that ‘people and interactions are above tools and processes’, which implies that a process doesn’t have to be a rigid path. Sometimes you need to veer off-course, and that’s not cheating. Let’s just keep in mind that, if everything is going well during development, a process is meant to help us to be consistent with the quality of our work.

The Key Takeaways

  • Normalization of deviance, of lowering standards over time, is always a risk in any industry, especially software development.
  • Simply put, people are going to bend the rules when that benefits them because that’s simply human nature.
  • The main danger is that this normalization is almost always invisible until too late, helping the build-up of issues and problems until a disaster occurs.
  • It’s up to the management and culture of an organization to mitigate this deviance, which is virtually impossible to eliminate but can be avoided with the right approach to communication and collaboration.

Scio is an established Nearshore software development company based in Mexico that specializes in providing high-quality, cost-effective technologies for pioneering tech companies. We have been building and mentoring teams of engineers since 2003 and our experience gives us access not only to the knowledge but also the expertise needed when tackling any project. Get started today by contacting us about your project needs – We have teams available to help you achieve your business goals. Get in contact today!