The other day, GeePaw Hill mentioned on Mastodon
“inline-jiggle-extract” is a coding pattern that needs describing.
If I were a better person, I would write that up.
As it happened, I’d recently talked about that pattern on LinkedIn
I found the sequence of inline, re-order statements, extract to be one of my favorite refactoring arpeggios.
Josh Kerievsky called me to task for not following up on his third version of his story of providing a quick fix before a test-driven fix. As I said, I don’t want to be critical of Josh. I will, however, cast a critical eye on the code he has shared.
For those just tuning in, the previous installment talked about differences between the culture we espouse and the culture we practice. This installment will return to that.
An open letter to a programmer who thinks that code coverage by integration tests eliminates the need for unit tests. Read More
I saw that Alistair Cockburn had written a post about Seb Rose’s post on the Diamond Kata. I only read the beginning of both of those because I recognized the problem that Seb described with the “Gorilla” approach that, upon reaching the ‘C’ case.
“The code is now screaming for us to refactor it, but to keep all the tests passing most people try to solve the entire problem at once. That’s hard, because we’ll need to cope with multiple lines, varying indentation, and repeated characters with a varying number of spaces between them.”
I’ve run into such situations before, and it’s always be a clue for me to back up and work in smaller steps. Seb describes that the ‘B’ case, “easy enough to get this to pass by hardcoding the result.” Alistair describes the strategy as “shuffle around a bit” for the ‘B’ case. I’m not sure what “shuffling around a bit” means and I don’t think it would be particularly easy to get both ‘A’ and ‘B’ cases working with constants and not heading down a silly “
if (letter == 'A') "¦ elseif (letter == 'B') "¦” implementation. I was curious how I would approach it, and decided to try. (Ron Jeffries also wrote a post on the topic.) I didn’t read any of these three solutions before implementing my own, just so I could see what I would do. Read More
No, not the book and personal productivity method by David Allen, though somewhat related in intent. I’m talking about getting things done in software development.
Traditional phased software development processes tend to have a long delay between starting to work on something, and having something working that people can use. During this time, there may be a lot of work expended on partial products and artifacts to support the process, but little or nothing that could be used for its intended purpose.
Both timebox-oriented [e.g. Scrum] and flow-oriented [e.g. Kanban] methods try to emphasize getting things done so that they can be used earlier and provide value. Even if you decide not to use them earlier, at least they can be evaluated for suitability of the intended use, and progress toward a larger collection of functionality that will be deployed for use together can be more reliably tracked.
The strategies for getting things done vary. Read More
At various times, the behavior of Facebook reveals to me that it’s a loosely coupled system with long latencies in synchronizing its various data stores. Just today, the iOS app asked me to confirm a friend request. When I did so, it gave me a pretty generic error—something about not being able to do this action at this time. That’s when I realized that I’d already accepted that particular friend request, days ago. That tells me that there are often inconsistencies between the database used with one interaction, and the one used with another interaction on another interface.
It also tells me that there are likely teams working on components, rather than features. If it was a feature team, the need for an error message would have driven a different underlying implementation. A feature team would want to differentiate between not being able to accomplish an action because it was already done, and because some problem was blocking it. For the former, there’s no need to show an error at all. Read More
A common complaint against Test Driven Development is that writing tests and refactoring take too long. In the long run, I’ve found that TDD has improved my skills such that I can complete work faster by writing tests and refactoring than without. I’ve also found that this information is a weak argument for those who have less confidence in their skills, or feel too pressed for time to learn. But that’s not the only benefit. Read More
Ward Cunningham originally coined the term Technical Debt and described it at OOPSLA 1992
“Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.”
In this, Ward was not referring to poor programming practices, Read More
Oops! The whole problem started when I wanted to install a new program on the “entertainment computer” that’s connected to the TV. The existing version of Ubuntu was no longer supported, so I started what I thought would be a simple upgrade. Oops, it deleted the entire /var directory, including the contents of the second drive mounted there. That drive contained all of our photos and music. Not a problem, I thought. It’s all backed up nightly onto a USB drive. It’s just a bit of bother to copy all of that over the USB interface.
Oops! There are no photos beyond last March. I felt sick to my stomach. That’s a lot of family memories to evaporated. Whew! The program we’ve been using to download the cameras also makes a backup copy local to the machine used to download. I’ve got all the pictures back on the photo server, and now just have to sort them into directories again.
But first, I need to fix the backup script. Why didn’t it warn me when it started to fail? Read More
Southwest Airlines has long been known for two things: low prices and attention to customer service. Since they instituted the “reserved place in line” so I wouldn’t have to stand for a long period of time, I have come to check their website first, and only rarely look for alternative flights. Sadly, they’ve taken their eye off the ball. I suspect that the focus on customer service has been replaced by a focus on growth (given their in-progress takeover of Airtran).