10 Common Software Myths Dispelled

Image for post
Image for post

Originally published at onix-systems.com.

Myths, superstitions, and misconceptions have accompanied man since ancient times. Even the relatively new and advanced industry of software engineering is no exception. Unlike old stories with underlying life lessons, myths in software engineering only confuse businesspeople, end-users, software managers, and developers themselves.

As an outsourcing software development company, we often deal with the effects of software myths. False beliefs and assumptions hamper communication and product development processes. Some clients have stereotypical or exaggerated expectations. Others are mistrustful and reluctant to make important decisions.

We’d like to shed some light on the most popular misconceptions about software engineering. We hope it will be useful both for potential clients and our developers.

Ten Common Software Myths

Image for post
Image for post

Myth I: Remote developers are worse than in-house developers

Silicon Valley startups and giants of Google’s caliber debunk the myth totally. Their outsourcing experience proves that remote teams can be as professional, hard-working, and enthusiastic about product development as in-house developers are. Excellent web and mobile app development, custom UI/UX design, and software testing services are available from specialists around the world. For established outsourcing services providers, the success of a product and the client’s satisfaction are the top priority. They wouldn’t survive without continuous dedication to quality product development, timely delivery, new technologies, and customer satisfaction.

The truth is that the choice of human resources should be ideally based not on the geographical availability or cost but on professionalism and dedication.

Myth II: Software development is a predictable linear process

Software development can be predictable and straightforward for small short-term projects, e.g., a landing page. It’s something on which fixed-price contracts are based. As long as the product requirements are clear and well-documented, the right technology stack has been selected, human resources are sufficient, and the communication is regular and smooth, software development goes off without a hitch.

It looks particularly simple with the traditional waterfall SDLC model. However, the sequential production flow is considered rigid nowadays. Development teams worldwide favor the more flexible but less predictable Agile methodologies.

In most cases, it isn’t even possible to give a 100% accurate time estimate for a project. It’s advisable indeed to think over each functionality in detail as early as possible. However, project requirements rarely remain the same throughout the development. Software products can be affected by both internal and external changes. Moreover, new ideas and insights can come daily, or developers can experience writer’s block.

Image for post
Image for post

When embarking on software development, you need to account for uncertainty. Planning and detailed project documentation is highly desirable, but plans should be considered rather as initial hypotheses that are constantly being revised.

Myth III: Adding/changing features is a piece of cake

False. False. False. Starting development without clear requirements leads to loss of time and money at least or to project failure at most. Proper documentation speeds up software engineering processes and helps ensure product quality. “Scope creep” disrupts time-to-market and budget. “Feature creep” does the same and affects the product’s usability. Moreover, the team can’t adequately test the product if the requirements keep changing.

In reality, you have to balance the triangle: time — cost — features. If you had overestimated the flexibility of software at the initial stages of a development process, at least try to incorporate most change requests as early as possible. At later stages, they may require re-design, extra resources or repeating the entire development process.

Myth IV: There is a silver bullet technology/methodology

Another version of this myth is that one programming language is better/worse than others. Software developers love to praise the one in which they program and criticize others. Remember that each language serves a specific purpose, and its advantages can be determined only within a particular task or project.

‘Trendy’ doesn’t mean ‘suitable.’ ‘Mature’ doesn’t mean ‘deprecated’ either. It’s OK to switch approaches and technologies according to changing business needs (proven, for example, by progressive web applications).

Image for post
Image for post

Myth V: More people/man-hours = faster software development

Fred Brooks, the author of Brooks’ law, put it simply: adding people to a delayed project delays it even more. It takes some time for new people on a complex project to become productive. They must be first trained and educated about the work that has preceded them. Engineers already working on the project have to be diverted for that purpose day-by-day. The task temporarily diminishes their productivity while the new team members are not yet contributing meaningfully. The new workers can also introduce bugs and make mistakes that move the project further from completion. As the number of people increases, so does the number of communication channels and communication overheads. The more people are added, the more time they spend trying to find out what everyone else is doing.

Programmers that can work around the clock is another myth. In fact, their productivity drops dramatically if they are forced to work long hours. Even worse, the quality of work deteriorates as well.

Myth VI: You don’t need testing (or testers)

The high cost of QA is a related myth. Automated unit testing, which reduces the number of bugs by up to 90%, does increase development cost by 30–50%. Whatever it costs, though, you will pay less for testing during the development stage than for the maintenance or correction afterward.

Myth VII: Software can be bug-free

As long as bugs aren’t catastrophic, it’s not a disaster when they pop up. They can be worked out over time. Moreover, this process goes hand in hand with product improvement. Just test the functions of your software in a timely manner and look out for bugs.

Myth VIII: Product must be perfect at the first attempt

Image for post
Image for post

Put the MVP on the market, start earning money, collect feedback, and improve on the product. For instance, if you’re launching an online store, focus on the basic purchase functionality and then add features to the foundation, e.g., to make the experience more personalized and fun.

If the product development team succeeds from the first time, kudos! However, then there’s another risk: the team may relax and stop developing innovative solutions. Regular updates are essential for successful products, and experiments are indispensable to the innovation process.

Myth IX: Release of the product = end of the project

The best software requires constant care. Security updates, bug fixing, and regular maintenance should ensure its smooth performance. It would be best if you had after-release support, long-term product development strategy, and ability to accommodate changes quickly.

Myth X. Successful development project = successful product

Image for post
Image for post

We hope this article has succeeded in clearing up some of the most harmful misconceptions and allaying some fears associated with software development. However, the best way to dispel any software myths is excellent work. Onix has been serving international clients in the areas of software engineering, UI/UX design, and quality assurance for years. Give us a chance with your project!

FOLLOW US:

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

Written by

Onix-Systems provides IT services in website, mobile app and emerging technologies software development. Check our blog -> https://onix-systems.com/blog

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store