Ward Cunningham, a fish of some note in our small pond, wanted to deliver software incrementally to a client in the financial sector. The client didn’t see the value in doing that as opposed to delivering in a “big bang” fashion. To help relate the idea to the client’s frame of reference, Ward came up with the “technical debt” metaphor. It’s explained pretty well in an Agile Alliance article.
Continue reading Technical Debt: The Man, the Metaphor, the Message
Warning: Rant
Warning: tl;dr
So, there’s this idea floating around of technical debt. There are some nuanced definitions, but in general it means bad design baked into the code. The “nuance” has to do with why bad design is baked into the code. There are a lot of debates about this, and you might wonder why, as it isn’t intuitively obvious how anyone could argue in favor of baking bad design into their code.
Yet, they do.
Continue reading The what, the how, professionalism, and pragmatism
Can you tell by looking at the unit test cases whether the code’s author wrote the tests first? During a TDD class I taught last week, one of the participants suggested that you can’t tell. Completed code and unit tests would look the same regardless of which had been written first. At the time I didn’t give the comment much thought.
I returned to the team I was working with at another client on Thursday, the last day of their iteration cycle. I picked up a small story so I could contribute something before the end of the day. It was a bug fix for JavaScript input validation logic in a webapp. Like many applications, this one uses date ranges to activate and deactivate certain data values that drive functionality. In this case, the input validation function neglected to ensure the expiration date was later than the effective date. Continue reading TDD and software archaeology
Most people who do coaching work in the IT space focus on one of three areas: (a) technical practices, (b) process improvement, and (c) organizational dynamics or “human factors.” It’s not unusual for a person to have skills in both process improvement and organizational dynamics. It is rare for the same person to work at both the level of technical practices and the level of process improvement, and even more rare for that person to be engaged for both purposes at the same time.
I’ve observed a sort of disconnection between process improvement initiatives at the organizational level and improvements in technical practices at the team level. I don’t know if the reason for this is, in part, the separation, first in formal education in universities and technical schools, and later in coaching, consulting, and training services, between technical practices on the one hand and process improvement and organizational dynamics on the other. Whatever the cause or causes, the situation appears to be that improvements in technical practices and improvements in process are treated as separate and disconnected issues.
I think the two are connected. Technical debt is more than merely an annoyance for maintenance programmers who have to deal with a challenging code base. A mass of tightly-coupled code can make it very difficult, time-consuming, and expensive to implement general improvements.
Continue reading The domino effect of technical debt