Do you like writing comments in code? Or are you against them? There is no definitive, easy answer to this question. Along with the equally perplexing question of where is the best location for braces in code, we will probably never find a permanent and definitive answer. But my experience has been that many people just pick one side and stick to that. In this article, I’d like to consider both sides of the debate.
Before we get into the debate, I want to digress and talk about readability for a moment. Ease of readability is not a universal desire…
[We] will focus on the good parts with occasional warnings to avoid the bad. The subset that will be described here can be used to construct reliable, readable programs.
If you had suggested to me just a few months ago that I would be writing an article in…
“Agile Framework” must be one the most overused but poorly understood terms in the Agile universe. Most of the time, it’s just dropped into a conversation or training course with an assumption that everyone will already know what it means. After seeing so many people struggle with this term over and over again, I started asking just what is an Agile Framework anyway?
The first obvious thing to do is to search online. Doing so yields these gems:
One of my frustrations as a developer is waiting for what can seem like forever to get my code reviewed and integrated into the build. I’ve heard many of my colleagues complain about the same issue too. Sometimes we have to chase people to review our code in order to authorize the merge, and other times the roles are reversed and we find ourselves being chased by those same people! Delayed code reviews hold up everything else down the line, such as acceptance testing, deployment and realization of value.
So how could we make code reviews more timely? Let’s look…
People can use the terms “leadership” and “management” interchangeably; other times they mean slightly different things. Leaders typically paint a vision and enlist followers to believe it in, whilst managers typically work to implement that vision. For example, politicians are leaders, while bureaucrats are managers.
In this article, I will lump both leadership and management into one big category meaning “whomever is in charge.”
But before we begin, here are a few questions for you:
Over the years I’ve seen many approaches for working out product focus. Some are relatively simple, like OKRs; others are quite convoluted. Some talk about lofty ambitions to be the “best in the world”; and others focus exclusively on just the work immediately before us. Whilst they all have their merits, none have been able to connect the dots for me between the overall big picture and the minutiae of everyday work. …
Long before Agile, the Iron Triangle — a.k.a. the Project Management Triangle — was a cornerstone of project management. Its origins remain unclear, but it has been used since the 1950s (Wikipedia). It was once a very useful tool to understand the trade-offs involved in delivering a project, and I’ve been wondering whether we can capture it’s embodied wisdom again.
In Part 1 we saw that reductionist User Story Templates of the form “as a user I want some action so that I can receive some benefit” both fails to adequately convey a deep understanding of the customer’s problem, and prematurely jumps to a solution. We proposed a set of long-form questions to ask in order to get a deeper, richer understanding of the underlying problem. We left the article postulating that it must be a lot of work to gather all the information required to answer such questions. (Spoiler: we were right!) Let’s continue…
Such a detailed user story…
Over the years, I’ve been on the receiving end of many terse User Stories, and I’ve often thought to myself “I have absolutely no idea what this means!” At first I thought that these User Stories were just poorly written. But as I saw more and more of them, I started to get the sense that maybe the User Story Template itself was the problem.
To recap, a typical User Story Template looks like this:
As a <type of user>, I want to <perform some task>, so that I can <achieve some goal>
A few examples might be:
The choice between Agile, Lean and Design Thinking can be confusing. There are many articles that dive deep into the weeds of each, describing them in painstaking detail, but not giving much practical advice about which one to choose and when. This is not one of those articles. Instead, I want to look at the bigger picture to help you make a call on this common dilemma. To that end, I will not describe any of the three processes in great depth, but rather direct you to any of the many existing articles freely available.
With that said, let’s get…