Recently there have been numerous discussions online about the difficulty of convincing people to try unfamiliar software development techniques that technical coaches and mentors consider useful. The same discussions have been taking place for many years, with no progress. Why is there no answer?
Author: neopragma
An IT professional since 1977, I’ve served in a variety of technical and managerial roles. I’ve worked mainly as a consultant since 1984, keeping one foot in the technical camp and one in the management camp. A lifelong learner, I’ve always been interested in exploring better ways to deliver business value through information technology. I’m currently working as an independent consultant, trainer, and coach with an interest in bringing together the best of tried-and-true methods and the best of leading-edge methods to help businesses realize the maximum return on their IT investments and efforts.
The future casts its shadow across the past
I don’t know the origin of that saying. When I first heard it, it was presented as ancient Chinese wisdom. In the West we often attribute pearls of wisdom to some named or unnamed ancient Chinese philosopher. I suspect many of the attributions are not historically accurate. In any case, the saying suggests — correctly, I think — that by examining the past we can make some predictions about the future…within limits, of course.
One of the hot topics of discussion in software development circles these days is the question of how we can make useful predictions about the future for purposes of planning software delivery activities. The subject turns out to be trickier than I had, um, predicted.
Continue reading The future casts its shadow across the past
Four canards that afflict us
Alert: 82% chance of pontification.
Continue reading Four canards that afflict us
Attitudes toward continuous improvement
Question: Is it a general pattern that organizations in need of improvement tend to be satisfied with the status quo, while organizations that pay attention to improvement tend to forget that they already do many things very well?
Here are sanitized descriptions of four client environments where I’ve worked in the past few years. Continue reading Attitudes toward continuous improvement
TDD and software archaeology
Can you tell by looking at the unit test cases whether the code’s author wrote the tests first? During a TDD class I taught last week, one of the participants suggested that you can’t tell. Completed code and unit tests would look the same regardless of which had been written first. At the time I didn’t give the comment much thought.
I returned to the team I was working with at another client on Thursday, the last day of their iteration cycle. I picked up a small story so I could contribute something before the end of the day. It was a bug fix for JavaScript input validation logic in a webapp. Like many applications, this one uses date ranges to activate and deactivate certain data values that drive functionality. In this case, the input validation function neglected to ensure the expiration date was later than the effective date. Continue reading TDD and software archaeology
Delivering provably-correct code
A while ago on this blog I mentioned the idea that a programmer’s job is not to deliver code, but to deliver provably correct code. Twitter responses ranged from strongly negative (wrong on so many levels I don’t know where to start) to mildly negative (not completely wrong, but incompletely right). There were no positive responses.
The converse of deliver provably correct code is deliver crap code, as I read it. Yet, it seems unlikely that is what those people meant to say. Unfortunately, no one followed up to explain their interpretation. I can only speculate that my choice of words has different implications for them than it does for me.
Since no one wants to explain their interpretation of the phrase, I’ll explain mine.
Lean Kanban France 2012 will take place 18-19 October
Lean Kanban France 2012 is coming up in a couple of weeks. The conference will be hosted on 18-19 October by Valtech at their offices in the heart of Paris.
I’m honored to be included on the program of an event that features so many luminaries in the field. My small contribution will be a session entitled Structural Impediments to Lean. The premise is that the conventional organizational structures and basic assumptions regarding roles and procedures tend to present obstacles to the effective use of Lean thinking in companies. It’s a subject I started to explore in earnest a couple of years ago at Lean Kanban Europe 2010 and have continued to explore in my work since then.
Here is the session description from the program.
Continue reading Lean Kanban France 2012 will take place 18-19 October
Cats in the monasteries of IT
Paulo Coelho wrote a nice piece about how cats came to be regarded as necessary for meditation for a few generations in Japan. The story might resonate with just about anyone in just about any context.
In my case, it reminded me of longstanding assumptions about how things “must” be done in the IT field. The following quote sums up the state of corporate IT in a nutshell: “..society continues to create some systems which, in the fullness of time, lose their reason for existence, but continue to impose their rules.” Continue reading Cats in the monasteries of IT
Does remote work work?
First, here’s the short version for those poor souls suffering from tl;dr (too lazy, don’t read much) syndrome, that peculiar malaise that characterizes our times:
Can working from home be effective
compared with collocated teams?
Opponents are quick with invective
and full of opinions, it seems.
But what if we increased, in some way,
the ratio of signal to noise?
Could we discover a good way to
routinely deliver with poise?
And now to business.
One of the ongoing debates in the IT world over the past few years has been about the relative merits of team collocation, including intense collaboration, paired work, and continuous osmotic communication, versus solo work, including work from home and other forms of remote work as well as office spaces fitted with individual cubicles. Continue reading Does remote work work?
Measuring continuous improvement
Let’s walk through a couple of process improvement scenarios to explore the differences between measuring activities and measuring outcomes. The starting point is a software development team that has decided to improve software quality. Continue reading Measuring continuous improvement