How To Protect Yourself From Bad Software Design

Charles Hoare has rightly said -
“There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.”

Most often software development vendors will deliver you solutions that meet your required feature set. These solutions seem to do the work at the time of delivery, but on closer inspection, they are not built so that they may be strong and sustainable. Many users are also not in a position to make this judgment. As a result, the solutions deployed fail to live up to the changing needs of an IT service user and need to be replaced with newer ones again and again. This process is no-doubt tedious and expensive for the end user. 

However, with a slight understanding of the principles of good software design, all end users can save themselves from this trouble and can make meaningful judgments before accepting a vendor’s solution.

The easiest thing to do is to perform these tests and ask these questions:

• Check the Usability – Is the Interface easy to use and intuitive?
• Security Engineering – Is the system open to security vulnerabilities? Can it be easily hacked into? This may be hard to check on your own. Ask an IT expert or the vendor to run some XSS and security tests and make sure they pass.
• Scalable – Is the solution scalable? What if you need to provide parallel access to your system to many people at once? Is the solution built in a manner that it can be used in parallel?
• Performance Intensive – How much RAM and CPU cycles does the solution need to run smoothly? What if your server is overloaded? Will this solution fail to function?
• Modularity – What if you need to add extensions and build in more features into the system? Is the solution written in a manner that adding or editing code will be easy?
• Tests – Make sure the solution has enough software tests accompanying it, especially Regression Tests. This is the only sane way to make sure that existing functionality is intact when newer features are added to the solution.

This will go a long way in saving you money on software re-hauls and re-vamps from alternate software development vendors.

What’s your opinion?

[Guest article by Ritika Sanghi, ex-Googler who now runs Atlogys Consulting. The article has been reproduced from author’s blog.]

Link to full article