Do Trust and Faith belong in Software Development? Not Really!

The words “Trust” and “Faith” don’t normally come up in discussion surrounding software development. However, whether we like to say it or not, we really do put a lot of both trust and faith in software. In fact, software developers often put a lot trust and faith in there development tool. While this can be justified in certain cases; it is most often a mistake.

The Good

When following Test Driven Development (TDD) you basically don’t trust anything by writing unit tests to verify everything at every level. It is often thought that Unit Tests are only testing the source code you write, but really it’s simultaneously integration testing the development tools and frameworks your code uses as well.

Writing proper test cases for your code with the highest code coverage reasonable is the best practice to follow.

The Bad

When a tool doesn’t lend itself to Testability, thus disallowing you to write unit tests against it in full or just making it difficult, you need to fully evaluate whether that tool is the best tool for the job.

Here’s a couple tools that generally fall into this category either in whole or partially:

• SQL Server Integration Services (SSIS)
• Crystal Reports
• Database Stored Procedures
• Entity Framework
• LINQ to SQL
• ASP.NET WebForms
• .NET Windows Forms

While there may be methods for either unit testing or integration testing things using the above frameworks/tools, they appropriately represent the types of tools that need to be fully evaluated before selecting them as the tool of choice for any new project.

It is worth mentioning, that generally legacy frameworks/tools don’t easily lend themselves to proper testability, so this is an area that some newer technologies really shine bright!

Grey Areas

There are also plenty of gray area tools and frameworks. These are tools that do allow for testability, but it can be a pain to do in certain cases. In these cases, it’s important to evaluate which parts of the tool/framework are appropriate to get the job done.

An example of this is the fact that some of the legacy ASP.NET framework stuff is present in ASP.NET MVC. While ASP.NET MVC was built with testability in mind, it is still built on top of ASP.NET which has its fair share of legacy pieces that are either impossibly to properly unit test or are just a pain to do so.

Conclusion

Don’t put too much Trust and Faith in your software development tools and frameworks. Sure while it’s in the vendor’s best interest to keep them bug free; it is still your job as the developer to do the same. You must not just reduce the amount of bugs in your own code; you must also protect your applications from bugs in the vendor’s code as well to the best of your abilities.