How Agile Software Development Can Fix Technical Debt
Traditionally, programmers are taught that software programs have a phase-based approach to development which is simply feature development, alpha, beta, and golden master (GM). This has been the staple for a very long time now.
The thing is, software nowadays is sold to users against their competitors because of their features. For example, you would choose an organizer software that has a bonus feature of having bookmark widgets than those that only have calendars. Features are now the selling point of most software and have introduced many challenges to be addressed by programmers.
Feature development includes the phase where the new features are built, and (ideally) residual issues from the most recent release are addressed when possible. The development cycle reaches “alpha” when each feature is implemented and ready for testing. Consequently, “beta” hits when enough bugs have been fixed to enable customer feedback.
In unfortunate cases, when programmers or a team of programmers are busy trying to fix enough bugs to reach beta, new bugs appear. This is one of the most common, and most annoying phenomena in programming, especially when the designs are revolutionary and complex.
It’s a classic case of whack-a-mole: fix one bug, and two more pop up. Frustrating for most, but this is where the bottleneck of programming productivity comes.
Finally, after a long game of whack-a-mole with the bugs, the program release phase reaches the golden master milestone when there are zero open bugs. Then again, this is usually achieved by programmers by fixing just the issues that could deter the program from leaving the beta phase. Simply put, programmers only remove the bugs that are outright apparent, and leave the unnoticeable bugs for the next releases when users have reported them.
Technical Debt: The Ultimate Programmer’s Challenge
Constantly procrastinating on bugs that need to be fixed is a dangerous way to make software. As the bug count grows, tackling it becomes increasingly daunting–resulting in a vicious death-spiral of technical debt.
Technical debt is a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution. Technical debt is usually associated with ultra-complex programming, especially in the context of refactoring.
To make matters worse, schedules get derailed because coding around the bugs slows down development. Meanwhile, customers are experiencing death by a thousand cuts caused by unfixed defects. As such, many experts in programming has begun addressing the growing problems on technical debt, and introduced Agile Software Development.
Agile Software Development: The Main Answer to Technical Debt
In software application development, Agile Software Development (ASD) is technically defined as “a methodology for the creative process that anticipates the need for flexibility and applies a level of pragmatism into the delivery of the finished product.”
Agile software development focuses on keeping code simple, testing often, and delivering functional bits of the application as soon as they’re ready. The goal of ASD is to build upon small client-approved parts as the project progresses, as opposed to delivering one large application at the end of the project.
Agile puts the “quality factor” into the iterative development approach in order for the programming team to maintain a consistent level of quality release every time. If a feature is half-baked, it is essentially thrown into the trash bin. Good programmers now have a simple trick: defining or redefining the definition of “done.”
For traditional teams, “done” means “good enough” for Quality Assurance (QA) to begin with. The problem with this definition is that only the obvious bugs are apparent in early in the release cycle. As a result, by the time QA gets their hands on it, the product is saddled with layers upon layers of defects that weren’t easily noticed.
Agile teams, however, define “done” as ready to release; this does not only mean that it could be tendered to the users. It also means developers don’t move on to the next story or feature until their current item is practically in the customer’s’ hands. To speed things along, they use techniques like feature branching workflows, automated testing, and continuous integration throughout the development cycle.
The Agile Manifesto
Agile development is not a methodology in itself. It is the collective term that describes several agile methodologies. It is basically a by-product of a collaboration between many software developers that value the quality and sought a good way to help the up and coming surge of software programmers.
At the signing of Agile Manifesto in 2001, these methodologies include Scrum, XP, Crystal, FDD, and DSDM. Since then, lean practices have also emerged as a valuable agile methodology and so are included under the agile development umbrella. The Agile Manifesto includes:
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity–the art of maximizing the amount of work not done–is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Ultimately, Agile Software Development is an approach to programming that is lean in nature, like how manufacturers practice Lean Manufacturing: Reduce waste, include the clients every step of the way, and address problems as soon as possible.
Other Benefits of Agile Software Development
Agile provides multiple opportunities for the stakeholder (the client or the target user) and to the team engagement before, during, and after each phase. The flexibility, versatility, and efficiency of ASD allows the stakeholders to be involved every step of the way.
It’s like getting a Gmail account – an all-around email service, fax messaging capability (http://www.gmailfaxhelp.com/tutorials/google-fax-number/) and access to practically all essential media communication tool in the web.
By involving the client in every step of the project, there is a high degree of collaboration between the client and project team, providing more opportunities for the team to truly understand the client’s vision. Rendering quality software frequently increases stakeholders’ trust in the team’s ability to deliver high-quality working software, and encourages them to be more deeply engaged in the project.
While the team needs to stay focused on delivering the agreed subset of the product’s features during each iteration, there is an opportunity to constantly refine and re-prioritize the overall product backlog. New or changed backlog items can be planned for the next iteration, providing the opportunity to introduce changes within a few weeks.
Also, an Agile approach provides a unique opportunity for clients to be involved throughout the project – from prioritizing of features and iterations planning, to review sessions and frequent software builds containing new features. However, this approach also requires clients to understand that they are seeing a work in progress in exchange for this added benefit of transparency.
By breaking down the project into manageable units, the project team can focus on high-quality development, testing, and collaboration. Also, by producing frequent builds and conducting testing and reviews in every iteration, quality is improved by finding and fixing defects quickly and identifying expectation mismatches early.