Articles on Software Excellence
My plan is to write a series of blog posts all related to the behaviors framework. Some of them will be about a specific behavior. Some of them will be about tools or techniques that help teams express one or more of the behaviors. Some of them will be my own experiences. And some will be damn near complete fiction.
I was recently asked to answer a question on Quora about the challenge of keeping up with change in a software project. The answers were a resounding cacophony of “yes” - change is a real problem in software development.
Inspired by discussions with Jess Kerr and others, I took a different stance. Here it is:
How might the Dreyfus Model of Skills Acquisition apply to pair programming? Is it better to pair a novice and proficient or a novice and expert? Does novice to novice pairing make any sense at all? Doc explores these and other questions.
Why even have a stand-up meeting?
From my perspective, the daily stand-up is an alignment meeting. The desired outcomes are:
Shared high-level understanding of the overall plan/progress
Shared understanding of the near term work
Alignment on how we can best collaborate right now
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.
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.
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.
I occasionally (and usually accidentally) find myself in a discussion about whether or not every story should be a shippable increment of work. The short answer is - Ideally, every user story is independently shippable.
I was recently asked to answer the somewhat vague question, “How do you interact with a large undocumented code base?”
One small step at a time.
A large code base can be overwhelming. Rather than trying to get to know the whole thing, I tend to focus on the problem at hand.
Over the past several years, as I’ve been helping teams and organizations improve their ability to deliver software products that are desirable, viable, and feasible, I have been experimenting with a Behavior Framework that has proven to be rather effective. And I’d like to share it with you in hopes that you find it useful and that you provide me feedback on your experiences with it.