Working with software developers – Misconceptions that lead to project failure
Odds are, you have already worked with software developers at some point in your career. If not, it is very likely that you will, especially if you want to hop on the digital train yourself.
We’ve already written about the main reasons why you should start business digitization right now in our last article.
In any case, it’s no secret that it can be pretty difficult to stay on the same page with the technologically gifted.
Over the years of working in the field, we have seen many cases where projects fell off track simply because clients and software developers failed to really understand each other.
This is why I’ve decided to use this article to address the misconceptions and simple misunderstandings that can easily lead to software development project failure. I will also share some advice based on our own experiences of what worked well for us in the past.
I didn’t put this one first by accident. A software project stands no chance without open, frequent communication between all parties involved – especially if we are talking about an internationally distributed team.
In some ways, people who are designing the product and software developers who are building it often don’t speak the same language. This is not a language barrier in the traditional sense.
Clients usually don’t have technical expertise, and they lack the ability to really see things through from a development standpoint. They need help from the development team for this.
On the other side, software developers will never have the same level of experience and insight into the client’s specific industry. The client has to provide these insights for them.
This is why bidirectional communication between them is so crucial.
We still frequently receive projects where development came to a halt simply because communication hadn’t been working between the client and the developers. In these cases, both sides failed to share relevant information with each other regarding changes in product features, or production difficulties.
Most of the time, the development team didn’t even understand what the client had in mind. This resulted in some pretty wild product releases.
This is becoming an increasingly common source of misunderstanding.
Because of the ever growing competition in the software development industry, more and more development firms and freelancers decide to give very unrealistic initial project estimations. They do this to stand out from the crowd. Clients can easily get deceived if they don’t ask for a second opinion, or educate themselves on the matter.
Most of these projects start to fall apart relatively early, and end up failing in a spectacular fashion. On the long run though, these kinds of offers can also result in super unrealistic client expectations towards software developers.
From time to time, people show up with some truly amazing and logic-defying requests that make us question our own sanity as well.
Here are some of our all-time favorites:
“I want to develop a site like Facebook for $5,000.”
“I need a (1!) developer to make a clone of eBay. If they can do it, there is no reason why you can’t.”
“Why do you need three months to make a mobile app? [Name] from [OtherDevCompany] said they can do it in a week.”
If clients don’t put any thought and effort into developing the idea for their software projects, they can easily get separated from their money without getting anything of value in return.
Project scope, desired quality, technologies used and a bunch of other factors all determine how much time your software project will take. Developing great software takes time, and a lot of invested work.
Quick math: Facebook boasts to have more than a million users per engineer. They have somewhere close to 1500 engineers today. With an average developer salary of $5,000 in the US, we get $7,500,000 per month. Safe to say, this system would be pretty hard to replicate for a total budget of $5,000. Just a simplified version of Facebook would probably cost at least $500,000 (<– really optimistic estimation).
Odds are, your complex, high-quality software product won’t be ready in 2 weeks.
A proof of concept? Yes.
A minimum viable product? Maybe.
A polished, profitable software product? No.
The time required highly depends on what your MVP scope is. For a small MVP, 1 or 2 months is more realistic. If you’re lucky, and you have a very small and clear MVP vision, maybe you can build it for $5,000 – $10,000. You probably won’t get a proper product under $50,000 – $100,000 though.
People also often confuse what really is minimal with what they personally feel is minimal for a product to work.
For example, if someone wants 5 payment methods in their MVP, as others are offering the same, it will obviously not be an MVP. The minimal part would be violated by adding the other 4. These are “extra features”, not minimally required for the system to work and for early users to get on board and start using it.
Once your project is off the ground, you get to see how little initial estimations really matter.
Seeing the planned features in action and getting first feedback from your client base can greatly change your final product vision.
These changes to core product functionality can turn the whole project on its head.
Maybe your customers found the most value in a side feature that you thought wasn’t important, and you have to rebuild the whole product around it. Maybe they didn’t find enough value in it, and you need to focus on adding something completely new.
This is the beauty of adaptive software development. You can make changes to the final product in time, based on early feedback from actual users.
While this is all fine and well (if not even obvious), you can’t expect software developers to make every required change overnight. What seems like a simple change to product interface to you may mean days of work for the development team.
While almost everything is possible in software engineering, current frameworks still have their limitations that also need to be taken into account.
When part of the software is updated, there’s a chance that the original architecture may no longer make sense for the new design. In these cases, the development team can either start over from scratch, or adjust the code to make the updates work with the old architecture, even if it may cause problems later on.
If you don’t want to end up with poorly written code, you need to give software developers time to implement every change properly.
It is very hard to find good developers for any programming language.
A good developer can be as effective as 5-10 average developers. While hiring less experienced people at a lower price may seem tempting, it is much more beneficial to hire a single expert who really knows what he/she is doing.
If you need to hire someone later to do refactoring work on your poorly written source code, you will ultimately end up losing more time and money.
If it was possible to master software development in university, the world would be full of great experts. Unfortunately, this is not the case. You really need to dig deep to find great developers.
What really makes an expert developer?
Becoming a real expert in software development takes a lot of hard work, dedication and perseverance.
While anyone can learn the craft, not everyone has the affinity to truly master it. Many great developers switched over from professions not normally linked with software development, like marketing or journalism.
Instead of thinking about them as introverted scientists, you need to see developers more like you see writers or artists. Their work requires talent, a great amount of passion and creativity.
It is a mistake to look for experts solely based on years of experience. Diversity of experience is much more important. Someone who has a real understanding of many different technologies, and can quickly adapt to them can be much more valuable than someone who has tons of experience in a single language.
If you want good developers, you don’t have to look for people with a minimum of X years of experience in a certain language. It is better to hire experts that are willing to cross over to that language.
Knowing what to expect while working together with software developers can already greatly increase your project’s chance of success.
When choosing your development team, remember to take the time to do your research and always ask for a second or even third opinion about the offers you receive.
Throughout your time working together, think about your software team as more than just a service provider. You are partners who are working together to reach your long-term goals.
You both have to do your best to keep your channels of communication open and transparent at all times.
Thank you for devoting your time to reading this article. If you are concerned about your own project, feel free to reach out to us at firstname.lastname@example.org, and we will do our best to get you back on track.