6 mistakes in software development you need to avoid

min read

We all know software development is not a walk in the park. We often solve issues that we couldn't have seen coming, but many others are avoidable if you don't fall for these common software development mistakes. I'll walk you through errors that can all torpedo your hard work and turn promising projects into failure. As a developer, analyst, product owner, lead, or CTO, I have encountered all of them, and even though some look basic, they still jeopardize your ventures. Let's dive into it!

Not understanding the product

Why is software development so exciting? For me, it's because you have a chance to learn a lot about different industries. In fact, you co-create them and shape their future by introducing the projects in the field. I had a chance to work on products in human resources, healthcare, finance, and other industries.

While it's exciting to learn about different areas of human activities, it's also challenging. If you're eager to build a successful product, you have to understand its background. Software development to me is not about writing lines of code. It's about finding solutions for end-users while making a profit.

The key takeaway is this – understand the core of the business and every feature you are supposed to implement. If you don't, you can't challenge other perspectives, making you just a robot following orders. Development is probably the most expensive part of the chain, so errors don't come cheap. I believe that consulting and reviewing the tasks should be an added value of every software specialist because it can correct faulty views of business representatives of the company that hired you in the first place. Exchange of opinions is the biggest advantage teams have over individuals.

Assumptions as facts

Decision-making is a central part of every product development and it's usually more complicated than choosing a color of a CTA. Naturally, your opinions from previous projects and assumptions come into play. Be aware of them. Guessing requires less effort than asking someone else, but it's treacherous. If you are right, lucky you but if not and an issue arises late in the development cycle, it's gonna be expensive. So how do you avoid this sad but common scenario?

Stay in touch with your team and have each other's back. Consult or prepare an experiment if you deal with a super-complicated issue and can't agree on the final outcome. Asking an expert in the field or your consumers can shine a new light on the matter. Hypotheses and experimental features as their results are also great for gathering feedback. It lets you implement a behavior that is possibly wrong but with a mechanism to verify its correctness. The mechanism might be a metric, a survey, a visible warning about the experimental nature of the feature with an easy way to get users' feedback. It's up to you and your team to pick a relevant mechanism for a specific hypothesis.

Lack of communication

Communication is important. Wow, really? How many times have you heard this phrase? Countless, I believe. Nevertheless, after working with teams of various sizes and nature, it is a problem. Creating a safe and open environment where no one is afraid to speak up is the proven way to avoid quiet backlog refinements, pointless sprint plannings, and aimless daily scrum meetings.

So if you want more than just moving items from one column to another, communicate and find a mentor that will help you steer the development. If you follow the Scrum framework and don't have your Scrum Master, you should ask for one. Footballers also don't play without their coach. Focus on communication will save you unpleasant surprises at the end of the sprint when you accidentally find that only 10 % of the backend is ready for the new FE features you just finished or that the implemented API adjustments are incompatible.

What are the key takeaways? Build a team spirit where people like to share ideas with each other and if you find communication too difficult, find a Scrum Master or coach that will streamline the whole process.

Business vs. tech language barriers

Understanding each other is the founding stone of an effective team. Software development brings together two worlds that often don't know how to communicate together. Here are some examples when things go south and meanings are lost:

  1. Techies use technical jargon, and business folks don't understand
  2. Techies want a technical decision from business folks but they don't know how to decide because they don't understand the technical point of view.
  3. Business folks use business jargon, and techies don't understand
  4. Business folks try to use technical jargon without understanding it
  5. Usage of same words with different meanings in business and tech

Familiar, huh? If you want to communicate honestly and not just pretend communication, know your audience and use words they understand. Start with context (see below), outline the problem, propose a solution, explain outcomes, provide examples, and make sure your listeners understand.

Error 404: Context not found

Imagine preparing a new requirement for a feature. You can simply describe what the feature should do, why it matters, and how it will bring you closer to your goals. Or you can outline everything from A to Z and leave no room for discussion. Which one is better? I am sure that most developers will prefer the first approach.

A new requirement is the opening point for a discussion, not a final assignment. Therefore, senior product owners should always start with context description and feedback gathering. Team members who understand the issue and its background are likelier to come up with better ideas. Making developers program something precisely as it has been written wastes their potential and will lead to misunderstanding. The "why question" is not a sign of distrust or aggression but interest, and it's the one that sets apart successful teams from unsuccessful ones.

What makes the product owners repeat this mistake? Time pressure is one answer, but it can't be an excuse. Sometimes the requirement is finished too late, and there is no room for developers' feedback. Designs are done, documentation is written. In such a situation, it can be challenging to stop and throw the requirement away, but it's still worth it if you don't find an answer to why. Some resources were wasted, but many were saved, so the lesson here is – be involved as soon as possible and start with the Why.

In-team silos

Your team is probably not homogenous. It's compiled of backend, web, mobile, business, or testers' silos. You need all of them to proceed meaningfully, and no one can do everything. Should each bubble or silo have its own sprints? Let's take a look from the product perspective.

You start with a backlog item. Items, nor user stories should be separated by silos. They shouldn't specify which silo will do the job. What matters is to have a deliverable piece for the sprint review. Something end users can use.

If your team often fails to deliver a complete feature in one sprint, either the backlog items are too large, teams are wrongly structured, or sprints are too short. Improve the workflow by having silos cooperate and never assign silos to sequential sprints, making them wait for each other. Remember that a half-done feature has no value.

Be active, step out of your silo, cooperate from the beginning, tweak your processes and automate where possible.

Final thoughts

Sure, it's impossible to code without hard skills. But no matter in what position you are in, soft skills like cooperation, communication, or presentation skills will determine how successfully you will push your projects forward. Exceptional companies do not look for people who can just do the job but those who provide an added value.

Cooperate, understand others and always aim for the best!

Reach out to get more information.
Jakub, CTO

Scroll to the top