This article focuses on using Chain of Command as a means of reducing cyclomatic complexity in our code. Along the way, we also create better adherence to SRP.
I recently worked with a team on a fairly significant refactoring. I paired with different team members each day over a three day period as we moved code around, pushing responsibility into other classes, reducing complexity, and make the code more expressive. On the fourth day, I put together some notes on the things we saw and general guidelines for the team to keep in mind. Nothing herein is new to the community, but it might be new to you.
I am wrapping up my second in a series for Clean Coders on Technical Debt. In the first episode, I explain the Technical Debt metaphor, how it originated, how it changed over time, and how it now is commonly understood in a way that is the opposite of what it originally meant. I talk a bit about the limitations of metaphors and how debt in particular has not served us well as a metaphor over time. So when a link to an article on the "Limits of the Technical Debt Analogy" hit my inbox this morning, I was quick to follow the link and see what the author had to say.
Unfortunately, this article is not at all about the limitations of the metaphor. The article is about how people other than those who write the software are responsible for the quality of the software. This article is bunk.
I recently gave a talk on the role of a Quality Analyst as an organization transitions from waterfall to agile. The talk was entitled "Switching Horses in Midstream" and covered a number of topics. One item in particular struck me as worthy of blogging about. It's a technique I've been using for years, but have never written about it. So here we go:
Legacy code bases with a lack of test coverage are often trepidatious places to hang out. You never know when a simple abstract method is going to create a sink-hole of logic and reason, eventually leading to your exhausted resolve to revert and leave it dirty.
I saw a tweet this morning that caught me off-guard.
If your software makes money it is good software by definition. Nothing else matters. #Agile ^ @SkankworksAgile — AgileFortune (@AgileFortune) July 23, 2015
It doesn't strike me as consistent with the type of thing AgileFortune usually tweets. My initial reaction was to reply via twitter, but didn't feel I could express my thoughts well in 140 characters or less.
This is an old talk (2010), but Matt Polito made it available on YouTube today and I wanted to share. My intent was to encourage discussion. I hope it has.
This is a quick post, following up on a tweet from a little while back:
"Unit testing is for code coverage like exercise is for weight loss. You're actually missing the point."
A great number of people in the software field appear to think the primary benefit of unit tests is test coverage. Some even talk about them as if they were one and the same. "No need for more unit tests, we have plenty of coverage already."
This year, at SCNA 2011, I had the honor of moderating a panel on apprenticeship. I was lucky enough to get participation commitments from an impressive list of individuals. I feared I would not be able to get a decent panel together and instead, I had to pare the panel from a list of eleven amazing people down to just six.
I've been thinking quite a bit about estimations and our general obsession with getting them "right". After all, we need to know when the project will be done. And we need accuracy. Knowing the entire project will be done before the end of the third quarter isn't good enough. We need to know that the project will be done this month or this week or perhaps even on this specific day.
In a discussion on the Agile Alliance Linked In Group, Michael Moles asked how refactoring fit into the agile process.
Refactoring: How does it fit into your Agile process?
We are in the midst of writing a new product, at this point the developers are realizing that some of the code should be refactored to improve performance and or clarity for ease of use. How do you fit refactoring into you Agile process? We have created separate backlog items for refactoring specific pieces of code. These backlog items are treated exactly like any other backlog item (meaning they have effort assigned and are committed to sprints by the team). What do you do when refactoring is necessary?
I really enjoy pair programming. It seems a natural process to me and I often wonder why it is that I like it so when others may not. Clearly, we have differing tastes and styles. I am sure that contributes to the joy (or lack thereof).
I've been watching others pair lately. And there is something I've noticed; pairing done well is conversation.