In software, well begun is half done..

And poorly begun is zero done… This applies to the software projects more than any other field. Most projects that are non-software say a construction of building, once past the blue-print phase,  the progress of the project is always a gradual step by step. You start with foundation and you build upwards floor by floor. And then you start working the interiors. It is simply not possible there to start with 4th floor and come down all the way to ground floor. Nor start building interiors first and then the framework. And there is not much parallel scope of activities either.

Its only in Software that you begin pretty much from anywhere and everywhere. And perhaps that’s the art and beauty in it. You start working on UI first and later create the architecture and then the back-end or you begin the backwards up or both or in many other directions. And as you build you realize you need to go back and change and replace that whole layer. Or the market dynamics make you change the whole direction all together all while the product is in early or late development stages. It is this very mercurial nature of the Software development that makes it all the way more exciting and challenging to handle. And that’s where lies the need for a strong technical leadership in dictating the pace and direction of the development activity and in making the right decisions.

The customer requirements even slightly misunderstood can steer the whole direction orthogonal to the goals and render the whole product worthless. We see this very often than not with a lot of outsourced projects and with consultants spread out across the globe. Recently, we had a customer who asked their vendor to build a small content management tool to manage content for mobile devices. The ‘Content Management’ part caught the attention of these consultants and they went on building it on top of SharePoint using the lists as tables to store what is mostly relational data and almost absolutely no real “content” whatsoever. Now the thing eventually got built, but was performing horribly slow which is expected. And things were quite messy to add even slightest of functionality. When the customer approached us later, we had to replace the whole thing and get it out of SharePoint. Technically speaking, the vendor has designed the system as per customers need of a Content management system and chose one of the popular ‘Content management’ systems (and because no one can go wrong choosing a popular tool whether it fits or not). Perhaps the client themselves might have hinted using SharePoint since its universally and widely accepted and pretty much every enterprise uses it. So in theory, the project was delivered as per “customer requirements”, from the vendor perspective. But for the customer, it simply failed to meet their current and evolving business needs. Unfortunately these kind of issues are realized pretty late in the project life cycle causing significant and time and money losses.

At Technovert, we ensure there’s a senior Architect role in the early phases of every project, so we know the technology we produce is headed in the right direction and covers the future needs of businesses. Our Architects are not struck to one Technology area and have a wide experience in multitude of platforms and they still code! No, we don’t build the entire house with a hammer!