Development

Refactoring: Introduce Parameter Object

A cluster of parameters often indicates an object in hiding. By creating a Parameter Object, you are making the code more flexible and you may discover a new object that was hiding in plain sight. In many cases, not only will you end up moving the parameters into a class, but you very well may discover that some of your code will move into the class as well. In this way, parameter clusters can be an indication we have a Single Responsibility Problem.

Agile is "the best"!

I was asked to answer the Quora question, “Why is the Agile model the best”.

I’m not comfortable with the notion of “best”. Maybe “better”, “leading”, or “fit for purpose”. But most of this is so contextual and ephemeral, I tend to avoid the label “best”. That nit-pick aside…

Agility focuses on working in teams together with the customer to deliver high-quality working software in rapid cycles.

Comments rarely improve code

Comments rarely improve code

The debate over comments in code is ongoing. At least once per year for the last 30 years, I’ve been involved in a discussion on the subject - often accidentally and reluctantly. To be honest, my perspective has changed over time. I used to comment every method, I used to comment any line of code that was “weird”, and I used to comment any blocks of code that were too complicated. Today, I rarely comment, if ever. Over time, I’ve come to realize that most comments are unnecessary.

Measuring Agile Efficiency

Measuring Agile Efficiency

This blog post is inspired by another Quora question; “What metrics do you use to track Agile Efficiency?”

To begin with, I want to state that if I had to choose between efficient and effective, I’d choose effective. Efficiency is often about output (how many widgets per hour), whereas Effectiveness is often about outcome (was the purpose consistently met).

Agility is about responding to change. Efficiency is achieved by driving out variation. An over-focus on efficiency will lead down a path of standardization and control, making for a less agile system.

That said, given the question was specifically about agile efficiency, I’d look at a few things - Throughput, Cycle Time, Deployment Frequency, and Mean Time to Recovery.

Removing Code Duplication

Today’s offering is another post inspired by a question on Quora about when to refactor away duplicate code.

The specific question was, “What is the limit for duplicate code to start refactoring?”

I took this to mean, “How much duplication needs to exist before you should refactor it?”

And I’m not sure that’s really a great question. So I decided to start with clarifying what duplication needs to be cleaned up and then when might that happen.

When to Refactor Your Code

For me, refactoring is when we change the implementation of a piece of code without changing the behavior. That’s the entire definition - Change the implementation, but not the behavior.

As a result, I will generally not refactor code unless it has a solid set of tests around it. If I see code that needs refactoring, but has insufficient tests, I will add character tests.

Thoughts on Refactoring

Thoughts on Refactoring

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.