BT

Monetizing the Technical Debt

by Vikas Hazrati on  Mar 30, 2010 10

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.

Temporary Code, Sustainable Code and Everything in Between

by Vikas Hazrati on  Mar 24, 2010 1

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.

To Comment or Not to Comment

by Abel Avram on  Mar 03, 2010 36

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, In Practice

by Mike Bria on  Jan 27, 2010

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, A Necessary Evil or Pure Waste?

by Mark Levison on  Dec 19, 2009 8

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.

Dissecting Technical Debt

by Vikas Hazrati on  Oct 20, 2009 5

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.

Software Debt Adds Up to Substantive Costs

by Shane Hastie on  Aug 10, 2009 1

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.

Rescuing Your Ruby on Rails Projects

by Robert Bazinet on  Jul 02, 2009 5

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.

Code quality for teams

by Niclas Nilsson on  Jun 29, 2009

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.

A Dollar Value On Pair Programming

by Mike Bria on  Jun 24, 2009 22

"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 Skipping Testing for Very Short Term Projects

by Mark Levison on  Jun 18, 2009 10

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.

How TDD and Pairing Increase Production

by Mike Bria on  May 27, 2009 7

"Test-driven Development" and "Pair Programming" are two of the most widely known of agile practices, yet are still largely not being practiced by many agile teams. Often, people will cite being "too busy" to adopt such practices as TDD and pairing; in essence, implying that striving for high code quality will reduce productivity. Mike Hill explains how this logic is seriously flawed.

Presentation: A Tale of 2 Systems

by Abel Avram on  May 05, 2009

In this video recorded during QCon London 2008, Pete Goodliffe presents two Linux-based audio products with a complete different outcome, software design making the difference.

What does Quality Mean?

by Mark Levison on  Apr 22, 2009 5

Is quality supposed to mean a lack of defects that are holding us back? Mike Bria, Lisa Crispin, James Bach and JB Rainsberger debate the meaning of quality and the limitations our current definition is placing on us.

J.B. Rainsberger: "Integration Tests Are A Scam"

by Mike Bria on  Apr 09, 2009 18

Well-known agilist and TDD expert J.B. Rainsberger has begun a series of posts to explain why his experience has led him to the thought-provoking conclusion that "integration tests are a scam".

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT