Home10 Common Software Myths Dispelled
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
Myth I: Remote developers are worse than in-house developers
Some clients believe that if developers are out of their sight, they’re unmotivated, uncontrollable, and unaccountable. This is hardly true, having modern project management practices, excellent communication opportunities, and project management systems.
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
Most people believe that software creation is similar to manufacturing or building a house from a blueprint. The team just has to stick to the plan. For better or worse, this isn’t entirely true.
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.
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
This myth is the opposite of the previous. Some clients believe that a brief list of generic requirements is enough to start development: details can be added in due course. Some misinterpret Agile as “no more planning and no more documentation.” Others equate changing things to changing a few lines of code.
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
The latest or most popular technology or SDLC methodology is desirable because it seems to guarantee success. Unfortunately, teams have to consider more factors to that end and primarily focus on the client’s needs and essential tasks of the software. There’s no need to go overboard if something simpler or cheaper can work just as well.
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).
Myth V: More people/man-hours = faster software development
It’s one of the project management myths. Some clients and inexperienced PMs apply economic principles to software engineering. If they fail at planning and fall behind schedule, they think that adding programmers to the team should help to meet the deadline.
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)
People that believe in this myth have many reasons for it. For example, people outside the IT industry think that anyone can test software. However, only QA experts understand the overall workings of the software, what the dependencies are, and the impacts of one module on another. Sometimes clients give up testing arguing that it’s time-consuming. Actually, the quality of software can be effectively measured during any phase of the development process by applying QA mechanisms, e.g., code review. Moreover, test automation reduces testing time.
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
A 100% bug-free product is an ideal worthy of pursuit, but hardly possible, unless your software is very primitive, written immaculately, and tested properly. In most cases, even testers with superb testing skills can’t claim with absolute certainty that the software is bug-free. All paths may be tested, but comprehensive testing is never possible. Sometimes, the team or the client can’t execute some scenarios during the development but only after the project has been deployed.
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
It’s an inherently false belief. Nobody knows what ‘perfect’ looks like till people start using the product. It’s better to build a Minimum Viable Product (MVP) with the essential functionality rather than require (and wait for) the whole nine yards from the developers.
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 idea sounds convenient, but software products rather resemble living organisms: they have their life cycles and are subject to change. Markets, businesses, and technologies are evolving rapidly. End-users increasingly demand functionalities and improvements. When an application is not compatible with a user’s device or operating system, they are frustrated. For the business, that means loss of revenue and other unrealized opportunities.
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
The right specialists or outsourcing partner can organize a proper project development process and ensure the quality of the resulting product. They will deliver it on time and budget. However, they can’t guarantee the product’s success in the market. For example, for a mobile application, the right monetization strategy and promotion are only some of the factors that are involved.
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. Alternative-spaces 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!
Content created by our partner, Onix-systems.