Technical debt can be difficult to connect directly to customer value, but delivering customer value is what Agile processes are all about. So how can we track and reduce technical debt in an Agile development environment?
Big Ball of Mud, is a code jungle which is haphazardly structured, sprawling, sloppy and connected by duct-tape. Over the years we have been introduced to various guidelines such as SOLID, GRASP and KISS amongst age old, high cohesion and low coupling to deal with this Mud. However, the situation still remains bleak and Big Ball of Mud seems to be a popular way to design and architect software.
W3C has released Unicorn, a one-stop tool to help people improve the quality of their Web pages. Unicorn combines four popular tools, including the Markup validator, CSS validator, mobileOk checker, and Feed validator, with a single interface.
Gerald Ford International Airport has a parking lot fee calculator and Matt Heusser noticed that it was buggy. So he issued a challenge to testers around the world: Find the bugs in ParcCalc. The respondents included James Bach, Selena Delesie and many others.
Most Agile teams recognize the evils associated with technical debt. Just like a financial debt, the technical debt incurs interest payments. These are paid in the form of extra effort required to maintain and enhance the software. Most Agilists recommend repaying the technical debt as early as possible. However, most Agile teams fail to monetize the technical debt.
There is code which is well tested, well re-factored and built to last. There is also code which is planned to be thrown away in a few days. Between these two extremes, there is a lot of gray area. The code in this gray area is written with the presumption that it would be cleaned up later but is never done.
Any developer has written at least one line of comment throughout his code. Some have written many comments in an attempt their code to be more explanatory. This article gathers some of the practices used in writing code comments.
Continuous deployment has gained a recent buzz in the Lean-slanted "eliminate work-in-progess" movement. But while many may find this an intriguing and logically worthwhile objective, many less can visualize how this might actually be achieved. Ash Maurya helps to fill this gap by describing his experience with making it happen at his company.
Stabilization sprints are an additional number of sprints added to the end of the normal development cycle before shipping the product. As the name suggests, they’re usually added to shake down the product one last time and drive the last of the bugs. Do they belong in Agile environment or should "Done" be enough.
The term "technical debt" was coined by Ward Cunningham. It describes the obligation that a development team incurs when it chooses a design or construction approach that is easy to implement in the short run but has a larger negative impact in the long run. Agilists provide their view point on what should be considered a technical debt and how it could be classified.
In a recent article entitled “Continued Delivery of High Values as Systems Age”, Chris Sterling discusses the concept of Software Debt – “Software debt accumulates when focus remains on immediate completion while neglecting changeability of the system over time.” Software Debt goes beyond technical debt an encompases a variety of aspects that impact on the ability to deliver value.
Ruby on Rails has been around for about 5 years and in those years developers have created a lot of applications. Many of those applications were created while learning Ruby and Ruby on Rails and may not have used the best practices but yet made it into production web sites. These web applications can be problematical but a new book focused on the solution is available.
Jaibeer Malik has posted an introduction of how to address and introduce code quality within a team. His series of posts may suite you if you are in a situation where you have to either learn more yourself or introduce these ideas to others. The series provides a brief overview of the topic and gives pointers in different directions of where to go to study more.
"Why in the world would we use two people to do the job of one?" This is often the initial reaction to people when first introduced to the idea of pair programming. In essence, they perceive pair programming as doubling the cost of writing any segment of code. Dave Nicollete offers some quantitive ideas to help show how pair programming can save money, not waste it.
Kent Beck suggests that on very short term projects, when you're trying to figure out if there is a viable concept, you might do less (even no) automated testing to help get off the ground quickly. This goes against all of the conventional wisdom surrounding TDD.