Software business application development is about understanding the the best practices around data management. In my opinion the application development should be around understanding the
- Core business needs
- Robust yet simple application implementation approach/architecture
It is understandable that requirements can at times not be made available completely in the early stages of project initiation, however getting the most of it is essential for a project to be successful in the long run and avoid adding huge functionalities as patches, ultimately it results in a software that is very hard to maintain and scale, I will take some examples from my own experiences and observations.
Back in early 2000, Java and Java related frameworks and architecture was spreading like wild fire. The most most hurt applications were because of developers migrating from other technologies like Visual Basic 5, 6 etc and writing and enterprise applications using EJB & Struts and trying to fit in J2EE blueprint. Well, in order to take the modeling route UML tools were available. Many developers then thought that UML tool is a one stop solution for everything. I know some who were rampantly using Rational Rose to generate the EJBs eventually ending up in nonsense names and heavily generated code. And interestingly the problem was more because of limited understanding about the requisites and understanding the need of tools in context of envisioned application. I was fortunate to be part of that development team, it gave me an opportunity to really understand what the need was, and how to amalgamate Struts framework for the presentation layer, EJB as the middleware implemented via Session & Entity Beans, usage of design patterns like Singleton, Service Locator, Business Delegate, Factory etc. Well the mantra is use only what is needed and not every tool and overkill the system. It led to development of proof of concept, training the whole team and moving on 🙂
The initial effort with a huge team was partially useful, oh yes but certainly a good platform for everyone on the team to get lucrative next job lol.
I had the privilege of working on an e-commerce marketplace which was developed wholly using Javascript, ASP & SQL Server, interesting bits were generation of databases for individual storefronts using DB Engine and usage of Javascript to the core. It was really not necessary to chose just a famous or happening framework or technology for any implementation, What is needed is an understanding the tools and envisioning the product. Look before you leap.
Moving further, when it came to desktop applications, back then Visual Basic was the most sought after technology, but there were situations where it would not fit in. Then came the era of Spring and Hibernate, almost replacing EJB. Oh well, frameworks and libraries have already been engineered, why would one need hibernate for everything. The other viable options for desktop development were Java Swing and Eclipse RCP, Eclipse RCP was certainly closer to the native operating system. It was fun developing on these technologies, almost no one dared to work on these, it was too cumbersome compared to the drag and drop thing in VB, well getting the grip of layout managers, command pattern, services. What does it take to make these kind of applications successful is understanding why a particular stack is chosen and how it will benefit in comparison to an established way of development.
Then came the period of dashboard, Macromedia Flex and Laszlo, shiny rich internet application platforms. Flex was awesome, gave the whole new way of developing web applications, and working on CRM dashboard with a fresh enthusiastic team, could not have been better, cut off the JSF presentation layer from the main application nd introduced a light service interface, good experiences. Got the thoughts right and no over engineering, keep it simple.
Next came an experience of seeing a team trying to develop a call center application using portal technology, JSR 168 & 286 the in the technology space now, small application, probably even a normal scripting technology would have been just nice. Wow we fought hard to get it to Spring portlet, some consolation. It was interesting to see the whole team testing and communicating over IP Phones, only a large enterprise can afford 🙂 Yes there are political reasons for choosing technologies as well.
Now what, most of the technologies for web development is rails inspired, hold on you do not need to introduce a multi layered platform/technology or design patterns and end up violating the basic software development principles by cross calling resulting spaghetti code. Hmm you know this when you change something at one place and you do not know at home many other places it stops working.
Being thoughtful, planning properly and improvising is the key, Avoid Over engineering!