Category: Uncategorized

Posted on by

Scrum pain in large organizations

Although “agile” has been around a long time, and Scrum even longer, many large organizations are only now undertaking “agile transformation” initiatives. People in those organizations who have not had experiences elsewhere with “agile” or Scrum are on the learning curve. I’ve noticed a handful of challenges that seem to be fairly common in these organizations.

Maybe it will be helpful to mention some of the common points of confusion and try to clarify them. I hope so, anyway.

tl;dr warning
Continue reading Scrum pain in large organizations

Posted on by

Gilded Rose: Read by Refactoring

People who practice refactoring often turn to the Gilded Rose exercise, originally posted by Bobby Johnson and extended and elaborated by Emily Bache. The exercise can be approached in many different ways. I think that makes it especially useful for exploring alternative ways of dealing with existing code bases.

Several years ago, Arlo Belshee came up with an interesting way to address existing code that he calls read by refactoring. I will admit that I haven’t discussed this with him directly, nor have I attended his training on the subject. I’m basing this on my reading of the idea online and experimenting with the approach on my own. So, I might be missing key aspects of the idea. Please feel free to correct me if that’s the case.
Continue reading Gilded Rose: Read by Refactoring

Posted on by

80/20 Skills

People in our field like to cite various maxims or laws. To name a few, there are Conway’s Law, Hyrum’s Law,
Brooks’ Law, the Peter Principle, Hofstadter’s Law, the 90-90 Rule, Parkinson’s Law, Sayre’s Law, Eagleson’s Law, Postel’s Law (a.k.a. the Robustness Principle), Linus’ Law, the Dunning-Kruger Effect, the Principle of Least Astonishment, Hanlon’s Razor and it’s notable parent, Occam’s Razor, and of course the ever-popular Murphy’s Law.

I’d like to consider a couple of maxims today: the Law of Diminishing Returns and the Pareto Principle, or 80/20 Rule, in relation to the idea of multi-skilled team members on a cross-functional team.
Continue reading 80/20 Skills

Posted on by

What happened to the test automation pyramid?

In a February 2020 article on cucumber.io, “Eviscerating the Test Automation Pyramid”, Seb Rose points out some of the issues that ensue when people misunderstand the intent of the test automation pyramid (or triangle) originally proposed by Mike Cohn and interpret the model too literally. He suggests if we remove the various levels and labels that people have added on the inside of the triangle, and think about the shape as such, we’ll come closer to the original intent – many tests of small scope and fewer tests of larger scope.

Continue reading What happened to the test automation pyramid?

Posted on by

Design by Contract

Design by Contract is a software design approach that is helpful when we are building solutions from small building blocks that interact with one another through interfaces or APIs. The “contract” is the definition of how an interface or API is meant to be used. There’s a good description on the C2 Wiki, a reasonably good article on Wikipedia, and concise explanations in the Microsoft .NET documentation and on the Java Practices site.
Continue reading Design by Contract

Posted on by

Refactoring the Hard Way, Part 2

This is a continuation of an exercise to learn how difficult it is to add refactoring support to a text editor. There’s no intent to produce a fully-featured and robust solution, but just in case it proves to be useful I want to focus on a couple of tools that don’t already have satisfactory refactoring support for widely-used legacy languages.

To be clear: This isn’t a “lesson”. I’m not teaching you something I already know how to do. I’m writing down what happens as I try to teach myself how to do something that’s new to me. Others already know how to write refactoring logic and how to write extensions and plugins for editors and IDEs. Fair warning, in case that sort of thing doesn’t interest you.
Continue reading Refactoring the Hard Way, Part 2

Posted on by

Where does all the bad code come from?

Some of the top people in the software field spend a good deal of their time examining and improving the quality of existing code bases, and showing developers how to keep their code bases habitable.

Brian Marick kindly filled in a historical gap for me in response to the initial version of this post. He writes: “‘habitability’ was probably coined by Richard P. Gabriel in an article for Journal of Object-Oriented Programming. The article (‘Habitability and Piecemeal Growth’) is included in his 1996 book Patterns of Software (available at https://dreamsongs.com/Books.html). Thanks for the history lesson, Brian!

It’s worth noting that “legacy” doesn’t automatically mean “bad”. Code that is currently used by numerous people, companies, and government agencies to support activities that are important to them clearly brings value. That value is part of the legacy of the code. But we need a shorthand way to categorize code whose internal design could benefit from improvement, and the word “legacy” has penetrated the market in that sense.

One might expect that after all these years of harping on “code quality” and “clean code” and “software design principles” that the problem of poorly-designed code would have faded into the background by 2020. Sadly, the problem is more profound than ever.

Why might that be the case? I think there are four main reasons.

Continue reading Where does all the bad code come from?

Posted on by

Refactoring the Hard Way, Part 1

Many developers these days praise the refactoring support in Microsoft VisualStudio and JetBrains IntelliJ IDEA, as well as Eclipse variants. Those who enjoy working with other tools, like VSCode or Sublime Text or Vim often lament the limited support for refactoring in those tools.

What if we tried to roll our own refactoring support? What would be difficult about it and what (if anything) would be easy? Let’s try, and see where it leads us! Worst case, we’ll gain an appreciation for how much help refactoring tools are giving us. Best case…well, let’s not get ahead of ourselves.
Continue reading Refactoring the Hard Way, Part 1