How easy is it for your programmers to fix problems?

A programmer, writing some new code, looks into some existing code that she needs to use. Something doesn’t look quite right. In fact, there’s a bug. Whether no one’s triggered it, or they have but their complaints haven’t reached anyone who will do something about it, is hard to say. Can she fix this code now and keep working? Or does something prevent that?

In such a situation, I would prefer to write a new test illustrating the bug, fix it, and check both the test and the fix into source control. This might take five minutes or an hour. It’s a small detour, but I feel better knowing that the code is now safer for the future.

Maybe, however, there are policies, either explicit or tacit, that prevent such quick resolution. (Continued)

Coherence vs. Standardization

I’ve talked about the rush to standardization before. My article, Coherence vs. Standardization, published yesterday on projectmanagement.com, offers a more detailed look at the problem, and offers an alternative.

[Note: projectmanager.com requires registration, which is free.]

Process Standards

There’s been a long discussion on one of the mailing lists about software development process standards. Someone quoted Robert Glass from his essay “A New Way of Looking at Software Productivity” in Software Conflict 2.0: The Art and Science of Software Engineering

Data show that good people do various software tasks 7 to 28 times better than others… Could we, for example, find out what the good people do? And once we found out, could we transfer that technology to others?

Now, I haven’t read this paper, so it’s quite possible that it’s taken out of context.  But it was introduced to me with the question

This sounds like the goal we are trying to do, to discover the most effective way to do something and then enable others to work the same way.  Does anybody disagree with this as the goal?

That sounds so logical, doesn’t it. (Continued)

Of course it’s a misnomer

On Twitter, my good friend Mike Sutton said, “CSD is a misnomer. The value of existing Certifications needs to be justified before new ones are released.”

Many of the terms we use are misnomers.  For example, “acceptance testing” is a misnomer because it doesn’t indicate acceptance if the tests pasts–it indicates lack of acceptance if the tests fail.

What is the misnomer in the phrase “certified scrum developer?”  (Continued)

Make it work before you make it standard

Matt Heusser has just published a post about standards. In it, he says

So, when people rush to standards, I hold back a bit. Having a standard means saying “We believe the value of doing things the same, every time, is more valuable than the value of the lessons we will learn by experimenting with new things.”

I, too, have been puzzled by the rush to standardize. (Continued)