Introduction
A number of projects have kicked off and somewhat completed over the past 18 months looking to significantly enhance a number of applications. However many of these projects have failed to acknowledge the current technical debt of the applications that they are attempting to change. The end result is often a project which runs well over time and over cost, with unhappy project members, stakeholders, managers and customers.
Moving forward, systems must be assessed - i.e. Warrant of Fitness - before attempting to add functionality, to determine whether they are in a fit state to be enhanced. If not, the project must include the payback of technical debt or scale back on such ambitious plans or not even commence.Technical Debt Definition
Technical debt (also known as design debt or code debt) is a metaphor referring to the eventual consequences of poor or evolving software architecture and software development within a codebase. The debt can be thought of as work that needs to be done before a particular job can be considered complete. "Interest payments" are both in the necessary local maintenance and the absence of maintenance by other users of the project. On-going development in the upstream project can increase the cost of "paying off the debt" in the future. One pays off the debt by simply completing the uncompleted work. It also may be considered as outstanding tasks to complete a project - to the customer's satisfaction - even after the project has "completed" and "closed". The OSCH Project is a good example of this.
Another measure of technical debt interest is the number of support calls logged after the project closes. Ideally projects complete and no calls are raised; the Volunteer Project is a good example of this. Technical Debt Avoidance is far more efficient and cost effective than paying the debt off - as at the point of payment you include interest. A number of steps have been taken to reduce debt which involve solid adherence to SDLC principles. Inclusion of code reviews, early and frequent involvement of testers in analysis and development, thorough, sound, robust requirements, frequent regression testing and so on. As a result current projects are leaving behind little or no technical debt. Again the Volunteer Project is a good example of this.
Technical Debt Responsibility
Payment of technical debt is not solely the responsibility of IT, but includes the application owner, steering committee members and stakeholders - all must take a level of responsibility. Business pressures, where the business considers getting something released sooner before all of the necessary changes are complete, builds up technical debt comprising those uncompleted changes. However poor coding, review, test, design practices i.e. - SDLC - are largely the responsibility of IT.
Background
The Admissions\Expressions project - in simple terms the merging of Expressions functionality into the Admissions application - was a deliverable from the FOC Programme of Work (POW). The project was focused on introducing significant change to the Admissions application. At the time the project was scoped there were a number of known issues with the Admissions application, inclusive of the obsolescence of the version of GRAILS the application was written in, the need to modularise and refactor the application, open tickets with support issues. Though known to the project team and business they were not considered necessary to resolve. Though the upgrade and modularisation was completed, the outstanding tickets were not scoped for inclusion in the project. However, as the project required regression testing it is almost certain that current known and unknown issues would be raised in testing. This then places the project in the position of apparently uncovering a range of "bugs' - which are in fact current issues. At this point a decision then needs to be made to fix or ignore. Some issues cannot be ignored as the inclusion of new functionality means a minor issue now becomes a critical issue. Effort spent on resolving these issues incurs a time, cost and opportunity spend. This pushes out the project timeline and costs and places the project team in an uncomfortable position.
What is the SWOF?
• Known issues captured in JIRA. Outstanding tickets that are require action i.e. to be fixed; need to be included within the project. Tickets which won't be fixed ideally need to be closed flagged as "Won't Fix".
• Current versions of the code base and libraries.
• Current state of the code. This may require a deeper dive and review of the time. Code refactoring and modularisation are effort and cost intensive. However if necessary needs to be stated.
• Versions of underlying infrastructure including physical and virtual servers, database engines and versions, state of backups, restores, disaster recovery plans. This could be quite comprehensive and a decision would be needed on how deep to go. However there may be serious underlying issues - such as obsolete and poorly database - which impede application performance.
• Current state of test scripts and automated testing
• Last known run of regression testing, coverage of regression testing i.e. 100% of application functionality and results of regression testing
• Last known run of performance testing
• Current state of technical and functional documentation
Desired Outcome
.The outcome of the assessment should determine whether the project is technically feasible and should flow into the future stages of the project, particularly the design phases. There are significant economies to be achieved if technical debt tasks are combined with functional enhancements i.e. regression testing of a code upgrade as well as functional change as opposed to two separate regression tests.
No comments:
Post a Comment