Insights from Our Experts
How to Handle Post Development Phase of Your Web Application
The development team is finally done with coding your web application and have run it through the required unit, system, load, and user-acceptance tests. In many respects, your application is now ready for deployment into the production environment. But whereas the development phases are crucial in the delivery of a working application, what happens post-development is important too and will determine how successful the app will be in meeting user expectations.
Many project owners and developers will meticulously plan and follow the evolution of their application through the software development cycle but take a more casual approach post-development in the assumption that all the important work is done. That can have catastrophic results. Instead, you must take a deliberate and well-thought-out approach to the post-development phase if you want the application to meet your expectations.
Here are a couple of tips on how you can do so.
Code Structure Supporting Post-Development Activities
There isn’t much actual programming that takes place post-development. Some coding may be needed in one-off instances such as to remove bugs, add new modules or to facilitate seamless application installation in a new server or CMS environment.
Nevertheless, though post-development programming is minimal, you must ensure that the application overall code structure will not inhibit such programming or otherwise prevent the successful execution of other post-development activities. Ergo, you must factor post-development requirements at the very start of the development cycle when you are choosing the application’s architecture.
Proper Hand-Off from Developers to Administrators
Once the development of your web application is done and it’s installed on your production servers, the primary responsibility for managing the application moves from the developers to web administrators and database administrators that handle the database management.
Usually, this shift in responsibility isn’t something that happens instantly. In the first few days or weeks, developers play an active role in responding to any issues that come up. They thereafter take an ever smaller role in the application’s administration as they cede this work to administrators. Yet, administrators could find themselves lost if there isn’t a clear and detailed hand-off.
Developers possess vast knowledge of how the application works. This knowledge can be shared with administrators and support staff in the form of documentation and where possible, a user-friendly administration tool. Developers should be briefed at the very beginning of the development cycle on what information will be needed by administrators post-development. Documentation should be detailed enough to allow administrators to comfortably oversee the application in the event that the developer is no longer available or accessible.
Error Tracking and Debugging
Despite development teams’ best efforts and exhaustive testing, your web application will inevitably encounter bugs once it goes live. It’s not necessarily an indicator of the developers’ competence—large tech corporations like Microsoft, Google, and Oracle with huge armies of highly skilled programmers backed by enormous cash reserves have to regularly fix the errors in their applications that are already in the market.
Running into application errors is not necessarily a problem—it matters more how you manage bugs once you discover them. Ergo, an elaborate error identification, reporting, tracking and debugging procedure is required post-development. Make the most of existing tools such as Apache logs to detect bugs early (see ). To prevent things from falling through the cracks, there should be a well-defined escalation procedure that ensures no bugs remain unresolved for too long.
No application will be in use forever. All software has an end of life when its developers, users and/or owners conclude that maintenance has become too tedious and expensive. While this is something everyone with a tech background understands, it’s often seen as being too far in the future to worry about today. Yet, the decisions made at the development phase can make a difference in how easy it will be to decommission the web application.
There must be a coherent set of formal procedures and policies that detail how the application will be taken offline for good. At a minimum, decommissioning procedures should address how system data should be archived and preserved, how any sensitive data should be disposed of and a timeline of how users will be notified and regularly reminded of the looming decommissioning.
Thinking through and carefully planning your web application’s post development phases will lower your maintenance cost, speed up response times and keep application performance levels high.