DEV Community: Sergio Fiorillo

Not Just Code: The Real Skills That Define Great Software Engineers

Sergio Fiorillo — Wed, 05 Feb 2025 11:36:03 +0000

When starting out in software development, most people focus on one big question: Which programming language should I learn? But what if I told you that the language itself is one of the least important factors in becoming a great engineer?

I remember searching for a clear answer in university, only to get vague suggestions like "Learn Java!" or "Try .NET!"—without much reasoning behind them. But over time, I discovered something surprising: once you understand the fundamentals, switching between languages is easy. Today, AI can even generate code in any language for you.

So, what truly makes a great software engineer? It’s not just coding—it’s the hidden skills that never appear in job descriptions but make all the difference. The ability to understand problems deeply, communicate effectively, and adapt to change separates top developers from the rest.

Let’s dive into the skills that will shape your career.

Embrace the Problem: Understanding is Key

I’ve often heard the phrase: "Don’t just love your product; love the problem you are solving." This resonates deeply because a product is meaningless unless it solves a real problem.

Many developers implement requests without fully understanding the context. Sometimes they fear asking questions or simply don’t have anyone to ask. This can be damaging, leading to issues during testing or actual use. To make solid technical decisions, you need to understand not only the problem the product solves but also the reasoning behind features or changes. Seeing the bigger picture helps you anticipate future changes and focus on what truly matters.

But solving a problem effectively requires more than just writing code—it demands a deep understanding of the business itself.

Become a Business Expert, Not Just a Tech Expert

When developers ask questions to understand their work better, they gain valuable insights into the business. This knowledge enhances technical decisions and encourages active participation in product development. Instead of just coding, you can offer feedback, propose improvements, and contribute to shaping features.

By developing these non-technical skills, you become a more valuable and sought-after engineer. Companies today are looking for individuals who bring more to the table than just technical know-how.

However, understanding the business is just one piece of the puzzle. The best developers aren’t just experts in today’s needs—they’re ready to adapt to whatever comes next.

Be Ready for Change: Adaptability is Crucial

In today’s fast-paced world, adaptability is essential. Many companies start projects without clear definitions, making an agile mindset crucial. Learning to manage frustration—especially from factors beyond your control—is key to avoiding setbacks.

Key strategies for navigating ambiguity:

✅ Prioritize the real problem. Solve what truly matters, not just what’s asked.
✅ Validate early, iterate fast. Assumptions lead to failure—test and adapt continuously.
✅ Align on scope upfront. A shared vision prevents wasted effort.
✅ Spot roadblocks before they hit. Dependencies can derail progress—anticipate them.
✅ Keep everyone informed. Clear, frequent communication prevents misalignment.
✅ Set realistic deadlines. Don’t let time pressure force bad decisions.
✅ Negotiate scope, not quality. If time is tight, adjust deliverables—not standards.

In a fast-moving industry, waiting for instructions won’t get you far. The best engineers don’t just react to problems—they take action before issues arise.

Take initiative: Make Things Happen

While this skill is often associated with management roles, it is equally vital for developers. Identify and address obstacles that slow you down, assist teammates facing challenges, research new technologies, and be proactive when issues arise. Cultivating a proactive mindset can be a game changer.

Proactive developers drive change. But ideas alone aren’t enough—you need to communicate them clearly to get buy-in and make an impact.

Strengthen your Communication Skills

Communication is a common weakness in technical roles, leading to significant problems. Many developers struggle to explain their work to peers or fail to consider their audience, which can include non-technical individuals. Poor communication can result in wasted time, endless discussions, incorrect implementations, and even project failure.

You could be the best programmer in the world, but if you can't communicate effectively, your skills may become perceived as less relevant. Developing your communication abilities will set you apart from your colleagues and position you for future leadership roles.

Even the best engineers have blind spots. The only way to grow consistently is to seek and embrace feedback.

Seek Feedback: The Path to Continuous Improvement

This practice applies to all professionals, not just those in tech. While many companies promote feedback through defined processes, not all prioritize career development. If you find yourself in such an environment, take the initiative to seek feedback.

While technical skills can be improved through documentation and practice, other skills often come from real-world experiences. Reach out to more senior colleagues and ask for both positive feedback and actionable advice. Observe how they handle various situations, such as team management and conflict resolution.

Beyond feedback, staying competitive means keeping up with industry trends. The best engineers never stop learning.

Stay Updated: Learn from the industry

Keeping up with technological advancements is vital in the ever-evolving tech landscape. Staying updated will help you remain competitive. While you can’t learn everything, try to stay aware of emerging technologies and their applications.

As a software developer, you'll face various challenges every day. A good strategy is to research how others have solved similar problems, especially complex ones. Analyze different solutions to weigh their pros and cons, and identify ways to improve your own methods.

Final Thoughts

Technical skills are essential, but they’re only part of the equation. The most successful software engineers go beyond just writing code—they understand problems deeply, communicate effectively, adapt to change, and take initiative. These are the skills that truly define great engineers.

What skills have made the biggest difference in your career? Are there any underrated ones that more developers should focus on? Drop your thoughts in the comments!

Thank you very much for taking your time to read my article. Don’t forget to ❤️ if you liked it👏🏻

Uncovering developer discontent: Why are so many software engineers unhappy?

Sergio Fiorillo — Wed, 30 Oct 2024 13:11:17 +0000

Software development is often seen as one of the most fulfilling careers in tech. But behind the attractive perks and competitive salaries, there’s a growing discontent. Why are so many developers feeling drained and disconnected from their work?

Despite the freedom to work remotely and competitive salaries, the latest StackOverflow Developer Survey reveals a shocking truth: 80% of developers are dissatisfied with their jobs. Even more alarming — one in three actively hates their job, while half are merely ‘surviving’.

Interestingly, this unhappiness is not mainly about salary or fears of being replaced by AI. So, what is behind their dissatisfaction? Let’s explore.

Legacy Technologies and Technical Debt: A Trap for Developer Morale

This is the number one cause of developer frustration. Working with outdated systems is like endlessly patching cracks on a sinking ship. Actually, the main challenge usually is to not break anything else instead of just solving a problem.

When developers feel like they’re always firefighting instead of innovating, it’s a clear sign that technical debt is weighing them down. The inability to modernize systems not only stifles creativity but also creates frustration when workarounds become the norm.

As a leader, inspire your team with challenges that match their interests and skills. This not only reignites passion but also fosters a culture of innovation. Even when there is lots of ‘business as usual’ work to do. Knowing your team, understanding what they like and what they don’t will help you also to distribute work accordingly. Consider Introducing a ‘debt day’ where developers are allowed to dedicate time to reduce technical debt. Encourage refactoring during regular sprints, ensuring innovation isn’t just an afterthought by fixing real problems for the business. Celebrate small wins when technical debt is reduced to keep motivation high.

Tight Deadlines: The Road to Burnout

In the IT industry, meeting deadlines -often set without input from development teams- creates extreme pressure. They just need to meet them, no matter how and whatever it takes. At the end of the day, the development team is under pressure. The constant cycle of urgent deadlines makes this stress a daily reality. Once a feature/module/app gets completed, there is another one coming with the same or even higher priority and so on. Inevitably, at the end of the road, the burnout is there.

It might be worth considering to involve the development team in setting deadlines. Encourage open conversations about the scope of work, allowing the team to highlight risks and constraints. This not only creates more realistic timelines but also gives developers a sense of ownership and control over their work.

Hustle Culture and Bureaucracy: Roadblocks to Developer Productivity

This is a common issue in large companies. Endless meetings and unrealistic managers’ demands contribute to the feeling of futility. Some other examples of this extensive bureaucracy can be found in large companies where someone needs to provide approvals to move things to production or where you have to ask multiple people/teams/departments to find some definitions for requirements, clarifications or even answers to questions. Developers become frustrated when their time is spent on administrative tasks instead of actual coding, leading to increased job dissatisfaction.

Something that might help is to limit meetings and give developers dedicated focus time. Streamline approval processes, and delegate authority where possible to reduce unnecessary bureaucracy. Empower your team by letting them focus on doing what they are supposed to do which is actually coding.

Lack of career growth: Stagnation Leads to Frustration

Most of the people want to grow somehow in their professional careers. When they don’t see any progress over time, it can lead to feelings of demotivation.

One effective way to combat this is by establishing a clear career path. A well-defined career path helps individuals measure their growth by setting and reviewing specific goals. It also clarifies the responsibilities of each role, preventing situations where developers take on too many tasks outside their primary duties. The previous should be also completed with regular one-on-one meetings to discuss individual career goals, to make sure they are aligned with upcoming projects. You could also consider offering mentorship programs and encouraging continuous learning through workshops and certifications.

Constantly Changing Requirements: Keeping Developers on Track

Priorities change, and requirements as well. There is nothing wrong with that, but it might become a problem when they are not properly handled. Just imagine starting a project only to be interrupted for something new. This can be very frustrating right? Now, how would you feel in case you have been working hard on some specific project or feature during a certain amount of time and then it gets discarded making that work to be throw-away?

One way to address this could be to explain why these shifts are happening. Involve your team on the business pains, show the value of their work and the contribution to the end users. By doing that you can ensure the team is aligned when priorities change. This transparency helps developers feel more connected to the bigger picture and less frustrated by sudden changes.

The push to return to the office

Before the pandemic, many developers enjoyed the flexibility of working from anywhere. Now that more and more companies want them back in the office, some employees are unhappy. They’ve adapted to remote work and may feel uncomfortable returning to less suitable environments, like noisy offices or spaces without privacy. Why would anyone choose to return to an uncomfortable office when they have a better workspace at home?

Lack of Resources: Providing the Tools Developers Need to Thrive

Developers need a wide variety of resources to do their job. From having the right laptop and other devices, going through the licenses for the programs they use, to having the right infrastructure in place, just to mention some of them. Few things are more frustrating than facing situations where any of them are missing. You can work on the most exciting project in the world by using your favorite trendy technology, but if you are not able to run your app locally or the amount of time it takes to do a simple task is huge, sooner than later the development force will feel they could be at a better place.

Tracking Time vs. Objectives: Trust Your Developers to Deliver

Even today some software developers have to track hours in some sort of application or system. This should not be a big deal as long as they are not requested to have installed a time management tool in their machines. The purpose of this kind of tool is to record what they are doing in order to ensure they actually work the required amount of hours. This kind of practice not only feels restrictive and adds more desmotivation for devs but also does not make sense in today’s software world where there are several other metrics to measure objectives completion and ensure the success of the projects.

Developer dissatisfaction is real, though often hidden. It’s clear that this issue impacts productivity and engagement across the industry. While some of the mentioned challenges are difficult to address due to external factors, managers and leads can still make meaningful changes. By understanding and recognizing what truly demotivates software developers, you’re better positioned to create an environment where your team thrives — not just survives.

As a developer or manager, how have you confronted these challenges? Share your insights!

Dealing with Digital Transformation in large companies

Sergio Fiorillo — Mon, 28 Oct 2024 20:04:37 +0000

Simplifying Digital Transformation: A Guide for Engineering Managers to Handle Challenges, Lead Teams, and Keep Projects Running Smoothly

Digital transformation can feel like climbing a mountain — especially for large companies. Whether you’re starting from scratch or building on existing systems, the path is filled with complex challenges and risks.

As an Engineering Manager, you’re responsible for navigating these obstacles and finding ways to overcome them. Success in digital transformation comes down to one key thing: anticipating challenges and staying prepared.

In this article, I’ll share the most common challenges I’ve faced during digital transformation and give you practical tips to help you tackle them with confidence. Let’s explore how to make your transformation journey smoother and more successful.

> CRUSHING DEADLINES WITHOUT CRUSHING YOUR TEAM

Tight deadlines are a common challenge in the software industry. While time is indeed money, the pressure intensifies when multiple projects run simultaneously, creating dependencies and strained resources.

While it’s best to address these issues early, complexities can still arise. Take time to re-prioritize, set clear expectations to all involved parties, and agree on a plan. This is essential when managing complex situations. Have in mind that multiple possibilities are available, from shifting people between projects to adjusting scope of certain projects or even extending some of the deadlines. Burnout should never be an option. Nor should sacrificing quality or piling on technical debt. These are temporary fixes, and you’ll pay for them in the long run.

> MANAGING COMPETING PRIORITIES

Each project might have either a single sponsor or multiple ones. Of course, they have interest in their own projects and might not care about other ones, so could easily arrive at the scenario where everything is a priority. If that’s the case, make sure to clearly expose not only to involved stakeholders but also to upper management the following: what the roadmap looks like, where the dependencies and what the blockers are, and the deadlines the team have based on current resources. They will need to make decisions, and clearly define what the priorities are between all of the projects and adjust as needed.

> NOT GETTING LOST IN THE CHAOS: TRACKING IS YOUR LIFELINE

Things need to be tracked, no matter whether you are using any methodology framework. This includes but is not limited to: new requirements, change-requests, sign-offs, deadlines, dependencies, etc. There are several tools that can be used for this purpose, so why not take advantage of them? Yes, it takes some time and requires some effort to keep it updated on a daily basis, but trust me, it is worth it really.

The benefit is extremely useful: it allows anyone to take a look at any moment, check the status of things, the history, the progress, dependencies and make decisions based on that. The information there can be used to support your work anytime, but especially in those not comfortable situations that could happen from time to time where you need to justify some missed deadline or some inconsistency between what was defined and the implementation itself.

On the other hand, the lack of tracking has some side effects related to efficiency. Some common examples of this are having regular meetings to ensure progress and get updates or exchanging endless chains of emails, or even losing information when somebody is no longer in the project or the company, just to mention some of them.

> MASTERING CROSS-TEAM DEPENDENCIES

Even if you are working on a big project or building a product that interacts with some other existing products/features, as long as many teams or parties start getting involved into the same project, it’s inevitable that at some point they will need to interact with each other.

While it seems to be something obvious, these teams must be communicated from the very beginning. Each team should know what they need to deliver, what the timelines are and how that deliverable piece will fit into the desired output of the project.

Given the fact that each team might have their own projects, priorities, timelines, etc, it’s clear that development won’t necessarily occur in parallel. For that reason, it’s super important that involved teams make an agreement on the contract which must reflect their interaction in advance. This means, each team should know:

what parties they have to interact with
how to interact with those parties

By doing this, each team will be able to do their own development without worrying about the readiness of other parties’ pieces. Of course the previous is valid only by respecting what was agreed previously, which allows them to mock the missing pieces in the meantime. Any change there should be properly communicated to the rest of the interested parties, so that they can make adjustments as needed. In the end, some integration efforts might be done to test the feature or the product end to end and ensure everything works as expected, but it should be smooth if they did properly the mentioned before.

> ADAPTING WHEN STAKEHOLDERS LEAVE

It happens from time to time that people who were in a position of taking high-level decisions get out of the project, the role or even the company. This usually occurs when objectives or goals are not met or even when the results were not expected ones. In those cases, new people come in, and this could bring a situation where either defined priorities or even the vision for the business change.

My piece of advice here is to establish a new partnership as if you were starting from day zero but taking advantage of all the knowledge you already have about the business, the applications and the ecosystem itself. Show yourself and your team as helpful and resolutive by focusing on the value you can add to the business even if the new direction taken is exactly opposite to the current one.

> MANAGING MULTIPLE TEAMS AND PARTNERS WITHOUT SILOS

As larger a company is, more chances are that it could work with multiple software providers. What is more, it could be the case that all of them might be spread across different teams or working in isolation. The key **under that scenario **is to work closely with all the team leads and make sure that all of them encourage their teams to follow defined practices and standards and avoid having “silos”. Having regular meetings with leads where people can be aware of what’s going on in other teams plus sharing experiences and facilitating tech discussions might be useful for that purpose.

> NAVIGATING RESISTANCE TO CHANGE

Digital Transformation usually comes to break the status quo. In most cases, this involves introducing a completely new way of doing things which can produce that some people could feel frightened about it and refuse to collaborate because of that. Remember, digital transformation isn’t just about upgrading technology. It’s about getting your team on board, every step of the way.

FINAL THOUGHTS

Successfully navigating these challenges requires a proactive approach, strategic planning, and a commitment to fostering an inclusive culture that embraces change. By approaching digital transformation as a collaborative journey rather than a mere technological shift, organizations can pave the way for lasting innovation and growth.

What challenges have you faced during digital transformation? Share your lessons learned!

Mastering Offshore Partnerships: Key Considerations for a Successful Digital Transformation Journey

Sergio Fiorillo — Mon, 28 Oct 2024 19:55:27 +0000

Building development teams can be a thrilling adventure, but working with external software providers comes with its own set of challenges. The good news? By tackling these challenges upfront, you can navigate your digital journey more smoothly and reap the rewards of partnership. Let’s dive into the common hurdles and why preparing for them is essential.

Either if you are about to start a digital journey or in the middle of a digital transformation process, at some point you may face the situation where you need to build or increase your development force. This exercise usually involves choosing between different approaches such as building an onshore team, an offshore one or a mix of them to accomplish your goals.

While there are different opinions about them -based on real experience- the truth is that we can elaborate an entire article to establish differences, pros and cons of each approach. But what I’ve noticed (and motivated me to write this article) is that when people discuss it, there are some aspects which are not usually included as part of the analysis. What is more, most of them are implications related to working either with a single or multiple offshore partners, and many times they arise since no introspective exercise is done in order to determine how prepared the company is to build a partnership. Casually — or not — most of these items become a real problem at later stages of the project lifecycle.

So, if you or your company are in a situation like this, and working with an offshore software provider is a valid option under analysis, make sure to review this list of considerations before choosing one approach to go with:

> UNDERSTANDING THE SPECIFICS OF THE PARTNERSHIP

As with any other decision that involves investing money in it, make sure to clearly understand what includes the service you are contracting.

In case you find such very different rates for the same tech profiles, make sure to verify the “added value” factor that the provider offers. This one is usually “hidden” and includes not only professional development opportunities but also competitive salaries for the different profiles, considering you may want the best people working for your project for a long time. But that’s not all about it. Your provider also needs to address attrition rate properly — in a time and manner — in order to mitigate the risk, so having the tools and expertise to respond appropriately to this common situation is a big asset. In addition, having experience working with similar projects/business areas and using methodological frameworks is also a plus.

As you can see, this kind of partnership service might include lots of aspects rather than just finding profiles with some specific tech stack knowledge. Not considering them might end up not only choosing the wrong partner but also suffering lots of headaches in advanced stages of your project.

> THE TIMEZONE FACTOR

While it seems to be obvious, as everything is “global” nowadays this has become a critical item to consider. No matter the project nature or how much things are documented, people will need to meet for different purposes. Of course this will be virtually most of the time, but it is super important to have a time range where people’s calendars get overlapped to make these meetings happen. This becomes such a challenge when having multiple providers working from very different locations across the world. If you don’t want to get frustrated when the time comes, make sure to take this into consideration not only when choosing your provider (and their locations), but also when configuring your teams and assigning them to the different projects.

In addition, and considering the overlapping time could be not that much, you should carefully prepare the meetings in advance to make the most of the people’s time. Having a clearly defined approach which includes setting an agenda, enough recurrency as needed, inviting the right audience and having a moderator would be helpful for that.

> THE MULTI-CULTURE FACTOR

If you plan to work with multiple partners from different countries, it’s important to anticipate potential friction between them. Such friction is not uncommon and should be expected. This occurs since people from different cultures could have contrasting visions about how to manage a team, how to solve problems, how to address conflicts, how to develop some project, how to deal with stressful deadlines and so on and so forth. Defining a clear leadership and setting up standard work practices for all the involved teams upfront, is a must if you don’t want to struggle with undesirable situations during your journey.

> ACCESS TO KEY PEOPLE/STAKEHOLDERS

Unfortunately, facilitating access to key stakeholders is often more challenging for offshore teams compared to in-house counterparts. In many cases, internal team members may lack awareness of external partners and their roles, particularly in large organizations with multiple departments. This lack of visibility becomes more pronounced as projects involve numerous stakeholders. Moreover, without a designated product owner or project manager to bridge communication gaps, ensuring effective collaboration becomes even more daunting. It is imperative to establish early connections between all involved parties and prioritize transparency by disseminating relevant information. If full disclosure is not feasible, assigning a dedicated role to facilitate communication can help mitigate these challenges

> THE IMPORTANCE OF HAVING A QUICK ONBOARDING PROCESS

It’s critical to establish a clearly defined and streamlined onboarding process, ideally leveraging automation wherever possible. Delayed onboarding can significantly impact project timelines, especially considering the already tight schedules common in most projects. Rapid integration of new team members is essential to ensure productivity and effectiveness. The onboarding process should encompass several key activities, including advance preparation of necessary documentation, provisioning of essential tools, granting appropriate access permissions, and introducing new hires to both the team and broader organizational context. By prioritizing these activities, organizations can expedite the onboarding process and minimize disruptions to project timelines

> SECURITY RESTRICTIONS

Depending on the project’s nature, business requirements, or established company protocols, there may be a need to impose restrictions on external providers. These restrictions could range from limiting access to production environments to safeguarding sensitive data or enforcing approval processes for production releases. In such cases, it is crucial to proactively establish mechanisms to prevent potential bottlenecks that could hinder offshore team productivity. This may involve implementing defined workflows tailored to address specific limitations and ensure compliance with security protocols. By taking these proactive measures, organizations can mitigate risks and maintain operational efficiency in offshore partnerships.

> MULTIPLE TEAMS COORDINATION

This aspect is so important in any context to maximize team efficiency. Ideally, each team should have its own leader who collaborates closely with counterparts. Initially, they should collectively establish a cohesive set of development and methodological guidelines to be adhered to by all teams. Consistent enforcement of these standards is essential over time. Furthermore, all leaders should maintain awareness of activities within the broader digital ecosystem. This facilitates effective coordination, prevents redundant efforts, and ensures resources are utilized efficiently.

Neglecting these steps can lead to dependency issues, especially in interconnected projects involving multiple teams. Moreover, it may result in the formation of isolated ‘silos,’ where teams operate independently, potentially leading to inefficiencies and discrepancies in implementation.

SOME FINAL THOUGHTS

The search for the right approach to build development teams as well as the look for the right partners (if it applies) are commonly underestimated problems. Actually, they are more complex than they sound. It’s not just about looking for a development force at the lowest price possible. It’s more like a detailed exercise that involves not only analyzing the digital goals your company has and the timelines to accomplish them, but also how prepared your company is to work with one schema or the other.

While there is no exact recipe that works for every single scenario, the truth is that if your decision involves working with external partners (either just one or multiple providers or even a mix of internal/external providers) you will need to consider comprehensively all the mentioned in this article before committing. By addressing all of them in advance, it will help you to not only reduce the risks and the friction, but also to succeed in your digital journey.

Did you face any other challenges when working with offshore software providers? What strategy did you implement to solve them?

Why you should consider migrating your legacy software

Sergio Fiorillo — Wed, 27 Sep 2023 12:27:39 +0000

Considering that technology and business are constantly evolving, there is no reason to think that your custom software won’t become obsolete over time as well. In both cases, it could be related to a wide variety of reasons such as changes in the economy, market conditions, laws, management, compliance, etc.

No matter which one is affecting your business or company, the good news is that there are some options to make your legacy software adapt to the new context, even without entirely getting rid of it and starting from scratch. This is where the migration concept begins to gain strength. It refers to the process of transitioning outdated software to modern technologies which helps businesses to unlock new opportunities and stay competitive.

Of course there are some implications to consider before embarking on that project. But let’s start from the beginning, and define what legacy software is.

WHAT IS A LEGACY SOFTWARE?

We can define as ‘legacy’ any old or out-dated software that continues to be used by an organization because it still performs the functions it was initially intended to do. They usually were built with old-fashioned programming languages and are used to run critical business operations.

Even if your software meets the definition above, it does not necessarily mean that you need to consider migrating it, at least initially. It could be the case that the value it adds to your company reaches your business expectations without too many issues, and therefore there is no need to invest time and money on that project. So, you might now be wondering…

WHEN YOU SHOULD CONSIDER MIGRATING?

There are some common indicators that you should pay attention to in order to determine whether you need to consider migrating your legacy systems. They are:

Existing systems are limited to extend. It includes any of these: they are difficult to adapt to new business rules/changes, it is not possible to scale them, their performance and/or their user experience is poor and cannot be improved.
They are heavily patched
Their technology does not offer any longer support
Its maintenance became too expensive.
They are not efficient

Based on the previous, if your system belongs to the ‘legacy’ category but you are not evaluating any migration yet, then you should be aware of some risks you most likely face by keeping that legacy system. Let’s take a look at them.

WHAT ARE THE MAIN RISKS OF NOT MIGRATING?

Compatibility issues. Since it may use outdated technologies, the legacy system can become incompatible with new systems or technologies that are also essential to the business. As a result, departments using legacy systems may not benefit from all the features offered by new systems.
Security issues. The lack of support, updates or maintenance, as well as the fact of using old security protocols and standards, leads to introducing vulnerabilities or even causing security leaks. This can also make meeting regulatory compliance even more difficult.
Data isolation. Legacy systems are not usually built to be integrated with newer systems; isolating data from other systems.
Decrease performance and productivity. Legacy systems tend to become slower over time as technology continues evolving. This causes an immediate impact on the performance, efficiency and productivity by decreasing those indicators.
Maintenance costs and competitiveness. Maintaining a legacy system means investing money on something that will need to be replaced sooner than later. This can put your business at a disadvantage relative to competitors, ultimately stopping you from reaching your full potential.

So you started to think about it, didn’t you? Let me tell you that the process of migrating your legacy systems also involves some challenges that need to be addressed properly to success. These challenges are diverse and depend on some factors such as the scope of the migration itself or the state and nature of the legacy system that needs to be updated.

WHAT ARE THE CHALLENGES?

Existing systems are usually critical to day-to-day operations, so their migration must be carefully assessed and planned to minimize potential risks.
It involves investing a quantity of resources — which means time and money. It is usually costly and time consuming and requires all parties to be involved at some point.
The new system needs to not only meet the business needs but also gain user adoption. Considering user experience as part of the process is a must.
Data protection. All data must be migrated properly to avoid data losses. So, involved parties must make sure all data can be extracted securely, ensure compatibility between old and new formats and take the time to test and review the data.
If the legacy system is built with an obsolete programming language or technology, it might be difficult to find qualified professionals to lead the migration.
The process can involve not-planned obstacles, for example, understanding the nature of the system as it was originally coded. This specially occurs when there is no documentation, when the quality of the code is poor or when nobody is able to provide information about it.
If not done in the right way, it can end up not completing the entire migration which could cause a worst consequence: adding more systems that will need to coexist and be maintained as well as data spreaded across multiple sources.

Fortunately and despite all the challenges involved, the good news is that legacy applications can be perfectly transferred to modern platforms, which have the necessary resources to improve efficiency and enhance user experience. In case you decide to start this journey, you should consider this set of good practices before writing any single line of code:

GOOD PRACTICES FOR SOFTWARE MIGRATION

Conduct a through analysis of existing applications
Define the scope of the migration
Determine what information will be transferred to the new platform
Choose the right migration strategy and technology
Involve all parties (business, IT teams, end-users, etc)
Develop a comprehensive testing plan

SOME FINAL THOUGHTS

Given that digital modernization is a concern that should be included on the agenda of any company nowadays, it becomes mandatory to assess your software inventory at some point and check its capabilities before it’s too late.

In that context, migrating your legacy software applications can help your business to not only improve customer experience, but also to adapt to new technologies and tackle industry challenges. The process involves lots of challenges, yes, but there are different strategies that make it possible for diverse business contexts. Definitely, a great chance to unlock new opportunities for enhanced efficiency and innovation!

8 Common Practices you should avoid when working with Distributed Teams

Sergio Fiorillo — Fri, 19 May 2023 11:59:03 +0000

In the current context after the pandemic, distributed teams across the world have become a reality and the software industry is not an exception to this. Regardless of the team’s configuration chosen for each specific case (in-house, offshore, or a mix of both), it’s easy to find so many examples where teams fail to succeed due to a wide variety of factors.

While each project has a completely different nature that is mostly related to the business area they are related to, there are some common patterns that get repeated frequently. Unfortunately, they have a negative impact not only on the team’s performance, but also on the success of the project itself. What is more, their consequences become exponential as long as those teams increase their size or even when adding more teams.

You might be wondering which those practices are and of course how to avoid them. Let’s take a look:

● Miscommunication and overcommunication

Calendars fully booked, meetings without a purpose/agenda, many attendees invited without any specific reason, calls scheduled to discuss stuff that could be addressed offline, multiple channels where topics get lost — just to mention some of them — became part of the team’s daily basis. While we could think this should not dramatically affect the performance of a team, let me tell you that it does actually. Why? It should not be difficult to realize that pe*ople get constantly distracted in order to attend meetings instead of focusing on the work they need to do.* What is more, many times these meetings do not resolve anything (specially when the discussion gets diverted or when there is no conclusion, action items, next steps, etc), which makes people frustrated about this. My advice here it’s simple: define the communication strategy you want to use and make sure everyone not only understands it but also follows it. This includes establishing which channel to use for each purpose, meeting only when needed, including the right audience, moderating meetings and channels, and of course ensuring everybody receives the same message.

● Not having clear methodology/processes defined

This comes in different flavors, but basically the idea is that everyone on any team should know how to proceed in most common situations (i.e how to track requests/issues, how to deploy, which branching strategy to use, which standards to follow, etc). In order to accomplish the ideal state, processes and work methodology must be defined and of course supported by accessible documentation that needs to be updated periodically. This will bring the teams a ‘framework’ which will make the work they do on a daily basis easier. Otherwise, it will be easy to end up in some sort of chaos where team performance, business expectations and timelines will be impacted.

It is also essential to ensure the processes and methodologies get not only adopted but also supported at all levels and on every single team.

● Not handling team dependencies properly

One of the recurrent issues when having multiple teams working together in development is not handling their dependencies properly.

Involved teams should be in sync before, during and after the implementation. In addition, each team must have clearly defined its scope and the integration points, including the contracts defined between parties. Of course, planifications should be aligned as well in order to meet deadlines. In case nothing of the previous is considered, you should expect to have a lot of delays, miscommunication and friction between involved teams.

● Confusing roles and responsibilities

While it is essential for the entire team to be involved in a project and engaged with the mission of adding value in different areas, It is important not to fall into the common trap of confusing roles and responsibilities. Developers are not supposed to take business decisions and/or define priorities/scopes. In the same way, “the business” is not supposed to be involved in implementation details. Not having a clear separation of concerns between parties may affect not only the project development itself but also the relationship between them.

● Lack of development & delivery strategies

A huge mistake is not clearly defining the procedures the teams need to follow in terms of branching techniques usage, environment deployments and releases management. A classic example of this is when you heard about issues on the environments where the applications get deployed to. This may cause some environments to be not usable at all due to errors, some others to be ‘frozen’ for some time or even entire features overridden in some specific environment by someone else’s deployment. What is worse, it may be the case that any of these situations last for days, which of course will have an impact over some other planned delivery timelines.

While the situations previously mentioned could happen due to several reasons, the truth is that in most cases, they could have been prevented by defining and implementing the policies to address them. The right strategy will depend on many factors such as project delivery requirements, infrastructure resources, available budget, amount of teams, just to mention the main ones. What you should definitely avoid is not having any strategy at all.

● Reinventing the wheel many times

This one becomes more visible especially when having lots of teams working at the same time in different applications that belong to the same ecosystem. It refers to the fact that without good communication and sync between teams, they will probably face the situation where you develop something that somebody else already did. Even having good communication and being aware of the existence of this code somewhere, it could be not enough. Here is where the importance of having reusable code and the right infrastructure to support it, becomes essential. By doing this, your team will be able not only to develop faster (and therefore be in a better shape to meet aggressive timelines), but also to ensure consistency across applications.

● Not handling the teams autonomy properly

While the autonomy of each team is a great asset and something we should look for, this does not mean anarchy. In other words, each team cannot do whatever they want just because they consider it is the right way to do something. Team strategies, implementation designs and technical decisions must be reviewed and validated with other teams, especially in those cases when -at the end of the day- all of them are working under the same ecosystem. If not, you will not only end up having different approaches implemented to solve similar things (even within the same solution/project/application), but also a high tax to be paid whenever the time to fix those bad decisions comes.

● Making key people to be ‘bottlenecks’ and ‘silos’

We all want the key players to be part of our teams. They usually bring smart solutions, have the knowledge to make things work and are an essential piece to succeed. Nothing wrong with that right?

The problem is that they usually become a bottleneck in many ways, which actually is an issue. Basically, they get involved not only in almost every tech discussion (even from other teams), but also in several other decisions (including not technical ones). Because of the previous, their availability is almost null which could also cause some extra delays while somebody else is waiting for them. In addition, since they usually concentrate most of the knowledge, this is why they become ‘silos’. In case that knowledge is neither documented properly nor shared with the rest of the team, it would be lost if the ‘silo’ decides to leave the team someday.

FINAL THOUGHTS

Working with distributed development teams brings a lot of challenges that need to be overcome to not only get the best performance from them but also to ensure the project success itself.

While the patterns mentioned above are commonly faced nowadays, the good thing is that most of them can be easily addressed. How? Easy. First, identifying and considering them as key to success especially in the long-term. Second, assigning them the right importance they have, so make sure to invest time on addressing them as early as possible. Finally, adopting the set of practices defined for that purpose, without forgetting to review them periodically to make sure they evolve as needed as the project does.

12 Best practices for building secure software

Sergio Fiorillo — Thu, 18 May 2023 12:52:56 +0000

There is no doubt the pandemic has sped up the digital transformation process. As a result, the software development industry has been asked to deliver a lot of value in the shortest time possible. While many businesses have moved to digital, cybersecurity risks have not only increased but have also evolved from the version we used to know. In that context, minimizing vulnerabilities in the code, protecting it from cybercriminals and hackers, and maintaining the user’s privacy have become a top priority when developing software.

Want to know the bad part? While secure software is a critical process that should be addressed from the very beginning, in many cases, it is skipped due to time and resource constraints. In others, there is a false belief that people think hackers will never attack their application. As you may guess, this is not true.

In reality, it is super easy to find many recent examples of how software vulnerabilities have been exploited for further malicious behaviors. Some of the common risks are related to exposing sensitive data or users’ personal information, performing unauthorized activities, stealing money, getting your application or data hijacked until you pay to recover it, and taking down an entire application for a time.

At this point, you might be wondering how to develop secure software under this scenario. Let me tell you that it is quite challenging, and despite not having an exact recipe, there are some practices discussed below that must be included in secure software development.

1. Consider security from the very beginning

Security needs to be hard baked into your culture and code, and there’s no better place to start than in the earliest stages of your project. So before creating a single line of code, begin planning how you will integrate security into every phase of the SDLC (software development life cycle). The price of neglecting security to get to market quickly is too high, so avoid that common pitfall.

2. Protect code integrity

Keep all code in secure repositories allowing only authorized access to prevent tampering. It is recommended to strictly regulate all contact with the code, monitor changes, and closely oversee the code signing process to preserve its integrity.

3. Ensure sensitive information is protected

It will probably sound obvious, but it is worth it to mention that sensitive data should be encrypted both in storage and when transmitted over the internet. The sensitivity of particular pieces of information varies, but there are tried-and-true ways to determine what sensitive data needs to be protected by default. Regarding passwords, they should be stored as a hash by using any of the well-known hashing algorithms.

4. Secure every single component in your application

Be cautious about whom you give what type of access and features to. It is recommended that you provide access that is only required according to the user’s role. If your application involves multiple components, make sure to secure all of them by implementing the authentication and authorization schema that fits your needs best. Carefully consider this upfront during the designing of your software because it becomes time-consuming to implement later.

5. Use code reviews to identify potential security issues

Code reviews can help developers identify security vulnerabilities. Actually, it is essential to review security requirements to ensure that secure coding practices are followed throughout the entire development process. The idea is that for every code change you make, you should go back and check to see if those changes have introduced any new security issues. Doing it timely and in due form allows developers to flag and fix them before they are implemented in production.

6. Use code signing certificate

Sign your software using a Code Signing Certificate from a trusted Certificate Authority. It is an effective mechanism for ensuring your security and privacy on the internet. In addition, by doing this, you will be able to avoid security warning signs for unsigned software, demonstrate the trustworthiness of your software, prove its integrity, and boost your users’ confidence.

7. Take advantage of code analysis tools

Static code analysis tools are an excellent approach to finding security vulnerabilities before the software is deployed. They facilitate the code review process by helping to identify areas of concern such as most of the common issues that lead to software vulnerabilities (e.g., SQL injection, cross-site scripting, sensitive data exposure, etc.). They can even be integrated into the pipelines so that every time there is a new build, the analysis tools will automatically run these checks and flag any potential issues.

8. Use popular and well-maintained libraries and frameworks

Before extensively using any third-party library or framework in your application, developers should always research those components’ reputation and make sure they are regularly updated. Why? It is easy — they are less likely to have vulnerabilities, you can benefit from early bug detection and fixes, and they can help your application be more secure.

9. Implement secure DevOps practices (DevSecOps)

DevSecOps attempts to strike a balance between agility and safety by embedding security processes and practices into developers’ daily workflow. It proposes a shared ownership model (between developers, testers, operations, and IT security teams) around a common goal of optimized innovation and speed to market without sacrificing security and compliance. As a result, your team can identify security issues at the beginning of development instead of waiting until they impact end users. This set of practices is based on the following fundamentals: collaboration, communication, automation, security of tools and architecture, and testing.

10. Include logging and monitoring

Every application should implement both features. By logging and monitoring things like logins, high volume transactions, failed login attempts, user request frequency, among many others, having an alert threshold defined for any suspicious activity, can help determine whether an attack is taking place.

11. Penetration testing

Penetration testing is a security exercise where cybersecurity experts attempt to find and exploit vulnerabilities in your software. The purpose of this simulated attack is to identify any weak spots in a system’s security which attackers could take advantage of. This way, you can have confidence that any existing vulnerabilities are quickly being addressed and resolved before attackers find them first.

12. Be prepared to mitigate threats and vulnerabilities quickly

Regardless of all the efforts done to avoid them, vulnerabilities and threats are a fact in software development. It is not if they occur, but when, so be ready with strategies, plans, and processes in place to address incidents in real time. Of course, the faster you can identify and respond to vulnerabilities, the better, since you will be shortening the window of opportunity for exploitation.

FINAL THOUGHTS

From the information discussed here, we can easily conclude that secure software development is about more than just secure code. It is a set of practices that should be implemented during the entire software development lifecycle (SDLC).

As cybersecurity risks continue evolving, security best practice approaches aren’t standing still. While the proposed list of practices works as a guide to definitely take into consideration, it becomes critical to look ahead to see what’s coming, keep learning, and identify better ways to secure your software development process.

What is pretty clear is that security deserves a preeminent position in the software engineering process. Organizations failing to do so will find themselves struggling to compete.

10 risks of not contracting the right custom development

Sergio Fiorillo — Wed, 17 May 2023 18:47:39 +0000

Starting a project always involves some risks. When looking for a service provider, regardless of industry, you need to cautiously evaluate which option may be the best to drive your project towards success. Software development is not the exception to the rule.

Choosing a service provider may sound easy peasy, but it is not. You may hear, “It’s just software development, there are a ton of developers and agencies worldwide.” However, there is some complexity that lies within. That complexity comes from the fact that it’s not just software development per se. You may also consider some other related areas, that include, but are not limited to, product, quality assurance (QA), UI/UX, infrastructure, and security, just to mention the most important ones. With that said, it is easy to conclude that each area may have to mitigate their own risks, and the cross-functional interaction may generate additional risks that require a continuous assessment.

In order to help you identify most of them, I compiled a list of common risks that you should definitely consider when looking for a custom software development provider.

● Not understanding the scope of the project
It is one of the more important ones, if not the most. The scope determines how much work will be done and what features need to be developed. The scope definition sets the stage for all the rest. In other words, if the scope is misinterpreted or not accurately defined at any point, then you will fail on the estimations, the team composition, and the plan to achieve the project objectives. Defining the scope should be a joint and collaborative effort between you and the development team. Once defined, the software partner should be able to explain how they will do it.

● Not having experience on similar projects
This is also known as not having the know-how. Not all projects are similar to each other, even within the same business area. Nevertheless, having broad experience on different projects over the years will allow providers to gain efficiency and apply any lesson learned to your project. Mimic what has worked, avoid what has not. The key piece is that they will be able to add value to your project based on the business knowledge and capitalize the experience from other projects.

● Not building the right team
Software development is not as easy as finding some tech genius that is tailor-made to bring you a software solution. It’s not just about hiring people that only know about programming or a certain technology. While building the team, you may need to ensure all the required roles are covered with someone that is highly qualified for the task that will be performing. A balance between technical and soft skills, it is crucial to accomplish the project objectives in a timely manner. Having a clear defined staffing process of course will help mitigate this.

● Not choosing the right technology
Choosing the right technology is essential, as it is another factor that could make your project fail. Which technology to use will depend on the project requirements, and the decision needs to be strongly backed up by funding. Avoid using either outdated or trendy technologies just because the development team is familiar with them or just because it is easy to find skilled people.

● Lack of methodology
The methodology, regardless of which one you want to work with, builds the framework where the project must be developed. Not having any methodology defined at all will cause the project to be chaotic, and of course, to fail even earlier.

A related risk may be about not choosing the right methodology. It’s not about implementing one or the other because they are trendy. It is about analyzing which one would suit your project’s needs better .

● Not having a clear communication path
Lack of communication or miscommunication could result in either considerable delays or notable cost overruns. This applies to either internal or external communication.

Every project needs to have a clear communication path between both sides, which should be maintained through the different stages and over the entire duration of the project. That communication path definition must include not only the point of contact(s) to address different situations but also the channels that will be used for each purpose.

● Not keeping the team motivated/engaged
When a new project starts, developers usually are excited about it if it seems to be interesting. While this is extremely positive for delivering a great software product at the end, it is also necessary to keep it up during the entire project. For that purpose, they should have leaders who can guide them throughout all the different phases and keep them motivated, focused, and engaged with their work.

● Not considering software quality assurance / after-development support
No matter how good the developer team is, bugs are rarely avoided (especially when timelines are too tight). Combining various tools and techniques for testing is ideal. Do not just rely on your own testing capabilities to make the project cheaper because it will be more expensive in the end for sure.

In addition, as many users start using your application, they will likely request some changes or improvements on the software itself. Make sure to discuss a plan to address them in advance.

● Not right-sizing the infrastructure
Nowadays, cloud providers have simplified this a lot (you usually get all the resources your software needs to run and pay only for what it is used for), but there are still some projects that require on-premise infraestructures because of different reasons. In those cases, sizing up the right amount of computing and storage resources with room for growth can be a complex process. This activity may involve some related risks that include under-provisioning or over-provisioning, hardware incompatibility, software incompatibility, network issues and outages, migration issues, downtime, disaster recovery, vendor reliability, and unexpected costs. Setting expectations in terms of high-availability, amount of users that will use the software, concurrency scenarios, and scalability, among several others that will help you come up with the right infrastructure solution for your project from the very beginning.

● Data protection and information security
This one has two big implications. First, of course, it impacts your confidential business information. In order to reduce it, confidentiality agreements are put into place.

But then, there is another one, though not less important, related to implementing the right security mechanisms to avoid potential attacks. It involves not only the code level but also the infrastructure one. It is a must to ensure there is no back door open that could cause any issue against data protection.

FINAL THOUGHTS
Now that you have become familiar with the risks, you’ll be more prepared when the time to look for a software partner comes. Taking these risks under consideration and planning a mitigation accordingly is the key to making the correct decision about the provider you should choose. If none of the items mentioned above are discussed in advance about how they will be addressed, it is definitely a red flag you should pay attention to before moving forward.

In the end, the biggest risk of not contracting the right custom development is driving your project to failure. So what would be better than taking the time to find a team that not only delivers quality solutions for your needs but that also treats your project as their own?

When a software project becomes essential

Sergio Fiorillo — Tue, 16 May 2023 11:08:14 +0000

Although we are in the middle of the digital era, it is still quite astounding to hear how large companies continue using their old processes and tools that have ceased to be efficient in today’s world.

The other day I heard an employee of one of those large companies complaining about how difficult it was for them to do their daily work and satisfy all of their customers. It raised my interest in understanding what the main challenges were that they encountered, so I asked him to be driven through the step by step within their operational daily tasks. What came next completely astonished me. Let’s simplify it as follows: He needed to validate a budget by comparing information from different sources before sending it to their customer. He logged into a DOS application (yes you read that right, DOS!). The login operation took around two minutes. Then, he had to log to a different application to retrieve another set of data, in which the login operation took around three additional minutes. For sure I don’t need to clarify that the operation to retrieve the data they need also took another significant amount of time. At that point, I was curious about why they had more than three completely different coexisting applications. He stated that each newest application was intended to replace the previous one. This is not what we understand by replacement, right?

Finally, after gathering information from all different sources, this data was used to validate a huge excel file with tons of rows, columns, and sheets. In the end, considering no errors were found on the values displayed on the budget, It would not take less than six hours for that employee to get that task done (while many other tasks were pending).

Inevitably, some calculations came into my mind about the time that is wasted by every single employee every day and what is even worse, how much money that would mean at the company level. Unfortunately, it is not just about money. That has driven me to create the following list of symptoms and associated consequences that can help us to understand when a software project becomes essential:

Having two or more coexisting software applications

Even though it is really frequent to have more than one application in a company ecosystem, we should avoid having the situation mentioned above. New applications intended to replace old ones should effectively replace them and not coexist all together in the end. What is the main reason this needs to be avoided? It could cause undesirable situations like duplicated information (that should be synchronized across platforms to avoid errors), conflicts of interests between platforms, a higher learning curve of employees, especially the new ones, trying to understand when to use one system or the other, and the obvious waste of time involved in those activities. Ideally, it would be much easier -and certainly more efficient- to have one platform providing all the required functionalities. If this is not feasible, we at least need to ensure that not only each software has its own intended purpose but also to have enough mechanisms to integrate them.

Lots of repetitive tasks

At some point, any repetitive task performed on a daily basis could be automated, easy peasy. That does not mean replacing a human resource by a software tool but rather designing and implementing a system that helps them improve their performance from an efficiency and time perspective. As a result, employees will be able to put their focus on and invest their time in what really adds value to the business.

Gathering data is a time-consuming task

Depending on your business, gathering information from different sources can become a time-consuming task. If that is the case, you will agree that waiting half an hour to retrieve some data in order to be processed is not acceptable. Do not even mention if that was the first task within the workflow as it will be the bottleneck for the whole process.

Employees become less productive than they could be

Put yourself in an employee’s shoes for a minute. How would you feel if every single step of any task you need to perform takes no less than 5-10 minutes? Consider you have to face these issues many times per week, per month, per year. Actually, not many of them are willing to do it, and they probably feel frustrated and with a lack of motivation because of that. What will the result be? For sure, job burnouts lead to a reduction in productivity.

Delay in achieving timelines

It is predictable to conclude that all the time wasted to complete the entire process jeopardizes project deliverables in a timely fashion. Entire projects are usually at risk when the gap between the scheduled timelines against the actual progress becomes bigger and bigger. A delay in terms of timelines should be a red flag to keep under the radar when managing any kind of business. Otherwise, your weakness will be the strength of your competitors affecting your credibility in front of your clients.

Email as a software

If your operation involves exchanging a lot of emails with your clients, and by a lot I mean to have a full inbox to address every day, this is probably outside of the intended purpose of the email as a communication pathway. If you are using email communication to share and review documentation, receive the client’s feedback, request confirmation, just to mention a few examples, a deep review of the process is warranted. Why?

Well, I have good and bad news for you. Starting with the bad — you may encounter security issues and miscommunication between the different parties involved, a lack of tracking during document revision, or even within your own mailbox to find an old communication to validate new information. The good news is that all these issues could be solved implementing the correct customized software application.

It is worth noting that the situations mentioned above can be easily extrapolated to other types of businesses or activities. So even if you don’t work with budgets, you may find some of them familiar. It is possible that within a particular industry all of the companies work in the same way. Paying attention to your processes´efficiency and identifying any of the symptoms mentioned above could help you to take action on those gaps earlier rather than later. Getting the whole picture and deciding to implement accurate software could add value to your company’s process and make a difference among your competitors. If they take advantage and implement this first, you could be potentially ousted from the market. Undoubtedly, this is a guaranteed pathway to make a difference and take advantage of your business.

Are you facing any of these situations in your company? If so, I strongly suggest you explore the advantages that a software project can bring to your business!

Geographically distributed development teams: a challenge that’s worth it

Sergio Fiorillo — Mon, 15 May 2023 11:51:59 +0000

While it is something more and more common nowadays in the software industry, today, many people and companies think that working with remote teams is not a good idea.

In many cases, the old myths are still valid, such as the one that being at the same office, room, or building increases the team’s productivity. If we look for the definition of a team, we will find that it is a group of people who work together to achieve a common goal. Even if we analyze it a little bit further, we will find that a team can be effective or ineffective, depending on how its members work together to meet deadlines and complete tasks.

As you may have noticed, there is no reference about the geographical location of those people at all.

The truth is that the fact of working and managing remote teams, whose members are located in different cities, or even countries, involves a wide range of challenges. If they are addressed correctly, not only will the success of the work team be guaranteed but they will also provide enriching benefits for all parties, which are often not taken into account.

Among the main challenges that we come across when having this kind of team, we need to figure these out:

The team synergy despite the physical distances
How to handle different cultural backgrounds
How to compensate for the lack of human contact
How to solve the time-zone issues
How to organize daily work

In this context, the keyword is communication, because it will help us to solve most of all those challenges. This involves not only the use of the numerous tools that allow us to make it happen through voice, chat, and video (both in real-time and deferred), but also to project management tools.

From the very beginning, there must be a common understanding and agreement among the parties regarding the best practices and standards to be adopted and followed. This includes development methodologies, good programming practices, processes, and everything that will make it possible to obtain a high-quality result that satisfies the client.

Defining checkpoints will also be helpful to ensure that all of the above is fulfilled by each and every one of the involved parties.

Another important aspect when it comes to managing remote teams is to distribute the work uniformly, ensuring that all team members understand their role and no one feels just as a collaborator but rather an important part of the group. Doing that, we will ensure the motivation of the entire team to achieve the desired objectives. The distribution of information should also be done in the same (uniform) manner to ensure that the team can quickly respond to any situation that may arise.

Now, it turns out that many of those mentioned challenges are really great opportunities… How is this possible?

To begin with, we can consider having the best professionals in each place. Today, in this industry, there is already a very competitive market where the demand for professionals is still much higher than the supply. It is clear that talent is not exclusive coming from a specific city or country, especially in terms of technology (although there are some markets well known for its IT professionals). The more you are open to work with teams distributed in different places, the faster the staffing process will be.

Additionally, the distributed teams provide greater coverage thanks to the different time-zones of the places where their members are located (also known as Follow the Sun [FTS] development). Thanks to that, we won’t have a team that only provides support during shifts or a specific time range (which generally coincides with the work schedule but sometimes does not coincide with the client’s schedule). Instead, the fact of being geographically distributed in strategic places makes solving this problem more natural, having at least a part of the team available at almost any time.

That sounds great, doesn’t it? This is fundamental in a globalized world like ours and especially in those projects where the development team and the client are from different countries or regions.

But there is more. The cultural diversity of a distributed team encourages everyone to think out of the box, accepting and adopting ideas that can become new and unconventional. This becomes a great way to build an innovative team and empower different resources. At the same time, companies can gather different perspectives from various locations, which creates a good sense of usability, local norms, and scalability of the product.

TO SUM UP

The type of work team to assemble will obviously depend on the needs, culture, and budget of the companies that participate in any software project. While implementing a geographically distributed work team involves certain challenges, addressing them is worthwhile.

The advantages they bring are insight, and best of all, they are enhanced by the implementation of Agile methodologies and the constant development of all the communication tools that exist today.

Why be agile in a dynamic business context

Sergio Fiorillo — Sun, 14 May 2023 18:27:56 +0000

Many people nowadays are probably aware of Agile methodologies, especially when talking about software development. This is the most common approach to work with when developing these kinds of projects, but the truth is that the methodology to use will depend largely on your business context, so first things first, let’s talk about this.

No matter what industry your company belongs to, you may consider your business environment as dynamic in any of these situations:

Operate in highly competitive markets
Build and maintain market share via regular new product introduction
Must respond to rapidly evolving requirements
Constrained by time, money, and skilled resources, among others.

All those characteristics are easily findable in most organizations. They make today’s business world highly dynamic and competitive where speed and flexibility are essential factors to succeed. Therefore, building software that supports those business needs is an even harder challenge to face.

Here is where Agile methodologies provide us the way to accomplish that! But, why should you be Agile in this dynamic business context? Is this really important? How can Agile project management impact your company?

Agile can be outlined as a really empowering methodology that helps companies to design and build the right product. The management process becomes very beneficial because it helps the entire team to analyze and improve their product throughout its development. This allows companies to produce a highly valuable product so they stay competitive in the market all the time.

How do they achieve this? They do it by reducing the complexity of building an entire software product by dividing it into smaller and manageable chunks of work, which are defined, coded, and tested separately in shorter time cycles or iterations.

In this way, while the company sets its own business priorities, the development teams can focus on delivering the highest business value in the shortest possible time. After each iteration, anyone can see the working software, and the customer can decide to release it as is or continue to enhance it in another iteration.

The Agile methodologies are based on an empirical approach employing feedback mechanisms to continually monitor and adapt to the unexpected, which provides regularity of its outcome and quick responses to that feedback. They do not concentrate on intense initial planning but rather on the interactions of individuals in a team and how they respond to changes. The goal is to produce working software rather than comprehensive documentation, as well as to use customer collaboration for continuous feedback.

There are other important benefits that are worth mentioning if you are looking to be Agile in a dynamic context:

1. SYNERGY BETWEEN STAKEHOLDERS AND DEVELOPMENT TEAM
The Agile process creates several opportunities throughout each iteration for real engagement between the team and the stakeholders. As a result, the client is actively involved in the entire project: There is a continuous level of collaboration among all parties.

Thanks to this, the team has the chance to fully understand the client’s vision and make suggestions and improvement proposals based on their knowledge (not only on the business but on the application itself).

By delivering high quality and working software frequently, the stakeholders rapidly build up a trusting and authentic relationship with the team.

2. THINGS BECOME PREDICTABLE: COSTS, SCHEDULE, AND DELIVERY
Iterations are held on a fixed schedule of 1 to 4 weeks duration (depending on the Agile methodology chosen). By using this time-boxed method while predictability becomes high, new features can be delivered to the stakeholders quickly and frequently.

As a result, the costs are limited and predictable, with all this based on the amount of work done. Considering the estimated costs before each iteration and comparing it with previous work already planned will enable the client to better understand the approximate costs of each feature. This will entail more improved decision-making opportunities when prioritizing the features or adding iterations.

3. FLEXIBILITY, THE KEY TO BE PREPARED FOR THE CHANGE
In a software development project, customer-driven features are prioritized based on their business value for a specific moment in time. Since the business context is dynamic and may change very often, Agile brings more flexibility by allowing you to change that prioritization at any time for all those requirements that are not currently in progress.

While the focus is on delivering the agreed subset of product features, Agile processes create an opportunity to continually reprioritize and refine the product backlog. Along with this, clients do not have to wait much since these changes can be added to the next iteration, which means they can be introduced within a few weeks.

4. FOCUS IS SET ON BUSINESS VALUE AND USERS
Because of the synergy already mentioned, the entire team has a better understanding of what is most important for the client’s business. Given that and setting the focus on the user’s needs, the team is able to deliver real value instead of just a software component.

How do we keep the focus on the user’s needs? It’s easy. Just take advantage of the feedback gained from them after each iteration. That valuable feedback allows the team to make changes to the software according to what users need.

5. QUALITY IS IMPROVED
An iterative approach results in a more robust software when issues, defects, and mismatches are detected and corrected earlier in the project lifecycle. This is especially good for critical workflows since it ensures it works as expected as changes may be introduced over several iterations. The result is not only having more mature testing but also getting higher quality software.

TO SUM UP
Agile management brings a powerful set of practices to carry out software projects. Implementing this approach properly is definitely recommended for those projects that take place in a dynamic or volatile business context since it reduces the common risks that are associated with the delivery, scope, and budget of the project itself.

As if that were not enough, the quality of the projects is vastly superior thanks to the evolving process. Finally, one thing to highlight is that thanks to Agile project management, organizations can continually find ways to increase the value for their customers!