This guest post comes from Dev Anand. Dev is the Director of Product Management for the Datacenter and Network Management Division at ManageEngine that develops IT Management software for Datacenter Visualization, Datacenter Infrastructure Management, Network and Application Performance, Change Management, Network Traffic Analysis and Virtualization Monitoring. You can follow him @irdevanand (Twitter).
As a server-side MVC, Struts’ proximity to the database regularly tempted our developers to query the database right from the client code. That’s quick and easy, but it also bypasses all the MVC rules. Blame it on our agile development model. Take 50 to 100 developers and push them hard on things like features and support, and corners inevitably get cut.
We were seeing JSP pages full of unnecessary database connections, as well as scattered business logic. Hard to spot initially, the effects of such violations slowly surfaced as we reworked our UI. Simple redesigns or additions were just taking too long.
A lot of application development time gets spent on the UI when you don’t follow a UI-driven development approach and make UI adjustments towards the end. That’s what we used to do. And it slowed us down.
Now, we have dedicated UI developers who can start working on UI prototypes at the start of each deliverable, and the rest of us can test functionality along the way simply by calling the APIs and checking the responses. A UI developer, meanwhile, can work on the new feature with a dummy JSON file. The result? We can prepare for a common exit in far less time when compared to Struts.
Until a decade ago, Microsoft set the standard for enterprise software development with a complete suite of .NET development tools, testing tools, integration tools, and so on. No one since has matched Microsoft on a product-for-product basis. Alternatives such as PHP and Ruby on Rails managed to capture developer interest, but neither really caught on in the enterprise.