point
Menu
Browse by year:
The Smart Techie was renamed Siliconindia India Edition starting Feb 2012 to continue the nearly two decade track record of excellence of our US edition.

July - 2009 - issue > Technology

Real Software Architectures, not the Fanciful work

Shailesh Goswami
Friday, July 3, 2009
Shailesh Goswami
Software requirements analysis is critical to the success of a software project. Inappropriate gathering of software requirements is a major reason for projects not achieving the desired results. A META group research indicates that approximately 60-70 percent of IT project failures occur directly as a result of poor gathering of requirements, analysis, and management. Unclear requirements often increase the tendency amongst software designers and architects to over-engineer the solution. Here we will take a look at the ‘software over-engineering trap’ and the ways to avoid it.

In a recent recovery project, we were called to ‘fix’ the software developed by the customer’s own team. The testing team found that the software, though claimed to be highly scalable, was too slow and unresponsive, especially on smaller number of users. On investigating, we found that though the software architecture used the most fanciful technologies, implemented nifty design principles, and seemed ‘perfect’, it did not work when deployed. This is a classic example of what I call the ‘software over-engineering trap’. Let us take a closer look at why we fall into this trap.

Top Reasons for Getting into the ‘Over-engineering’ Trap

1. Lust for using latest technologies:
Being abreast of all latest technologies available in the market, it is natural for software architects to have an inclination to use them. But in the eagerness to use the latest technologies, one should not lose sight of whether it is actually required for the project at hand.

2. Lack of clarity on non-functional requirements: Often the customer is not able to convey the requirements in the best possible way and may also be not sure on the levels of performance and scalability required. In such situations, the software architects may tend to take the safest route: create a software architecture that is straight from the textbook.


Share on Twitter
Share on LinkedIn
Share on facebook