Many professions have myths or rather, misconceptions and half-truths, associated with them. And the world of software engineering and programming is no exception. Below are just some of the few common misconceptions our Program Managers have had to deal with.

Developing software offshore is faster and cheaper

Offshoring software development and testing can be a compelling alternative to in-house development for many organizations. It’s low cost, and teams can work around the clock. However, it is important to realize that there are a variety of issues that can arise when you offshore the work, such as co-ordination, communication, cultural, and time differences that can slow down a project and mitigate any initial cost savings.

Offshoring the work can be faster and cheaper, but it is important to understand the type of work that should be outsourced. Offshore teams can provide a great supporting role, letting your local team concentrate on the core process. Tasks that are not time critical, and those which do not require a high degree of feedback and supervision, are often well suited for the offshore teams.

For complicated projects that require a high degree of creativity, design, and which are time sensitive, contracting local engineers is a more efficient and effective way of supplementing resources.

The latest tools produce best results

“There is no single development, in either technology or management technique, that promises even one order of magnitude improvement in productivity, in reliability, in simplicity.” – Frederick Brooks

The latest programming tools can have benefits such as increased flexibility, speed, or other capabilities.  However, there are some important factors to consider when making the decision to switch or upgrade to cutting edge tools.  There are many tools on the market that do the same things so it is important to check how they differ from each other, and whether they are right for the job. Sometimes we may be tempted to sacrifice flexibility in favour of something that is more user-friendly, and other times flexibility is improved at the cost of performance.

Take Dimensions for example. This versatile software from Serena allows for application change & configuration management across platforms, locations, and teams. While it is a less well-known tool, it is an extremely robust software that tailors perfectly to the needs of any development project.

Stick with the tried and tested

And then there is the flip side of the coin, a complete aversion to anything new. Some people strongly believe that upgrading the tools is not worth it. If you have an established infrastructure that has been working well for a decade then making changes to it comes with certain risks, such as cost, implementation into existing architecture, impact on current projects, etc.

Although some tools almost never go obsolete, there are those that do. The support for those older tools could also be discontinued. Programming tools must constantly be evaluated and re-evaluated to determine whether upgrades or replacement is required.

“To err is human, to really foul things up requires a computer” – Paul R. Ehrlich

Computers don’t really make mistakes – people do. Not every person may want to admit it, but machines often get blamed for something that is a human error. It may be that the person using the technology is not well aware of how to use it. It is also entirely possible that the person who wrote the software made a mistake. It is even possible that whoever assembled the machine made a mistake. In either case, it was a human mistake that made the machine behave in the way it did.

But that does not mean these are unavoidable and just a regular part of programming. Verification and testing of your software on a regular basis can significantly reduce the risks associated with human error. A key factor is to be able to recognize all potential scenarios and then validate them, thus eliminating any potential issues. Learn more from our previous post on Test Driven Development.

The 6 Steps of the Software Testing Lifecycle from Aversan Inc.

There is a ‘best’ programming language

Some people will fight you tooth and nail on what is the absolute best programming language. Is it the one that’s been around for almost five decades? Or is it the one that is very object oriented? The truth is, a programming language is just a tool. In construction, one would most often prefer an excavator to a spoon. That isn’t to say that spoon is an entirely useless tool, it just isn’t right for the job. And so when it comes to programming, there is no “best” programming language.

Selecting the best programming language for a specific project requires a similar approach to how one would choose any other tool. Whenever there are multiple options present, it is important to understand how the chosen language will integrate with other parts of the application and its overall performance. For example, .NET and C# are often chosen when working with Microsoft tools and systems.

In the end, when it comes to software engineering, it is important to look at all aspects of the project and consider time, management, and the impact of different tools and languages on the development process before making any assumptions. What are the common misconceptions that you have come across? Tell us below!