Home | Login | Recent Changes | Search | All Pages | Help

UsefulPractices

A less fatuous concept that substitutes better ideas for the dangerous assumptions associated with BestPractice:

• BestPractice - someone else knows what's best for you
• UsefulPractices - you are stuck deciding what's best for you. It's your butt, after all.
  
  
• BestPractice - you don't have to think about your context.
• UsefulPractices - you are the one in your context. So pick what works for you there.
  
  
• BestPractice - you can have success by doing these things without understanding anything about them.
• UsefulPractices - only through understanding of the practices and their principles do you stand a chance of succeeding.
  
  
• BestPractice - is an exclusive practice. These are best. We know best. The work is in selecting out.
• UsefulPractices - is an inclusive practice. These seemed to work. We have some ideas. The work is in selecting in.

Where BestPractice presents a limited prescription, UsefulPractices presents a loose-leaf catalog. Where BestPractice presents technique without principles, and rules without reasons, UsefulPractices presents examples of principles, and guidelines that describe.

-- JimBullock, 2004.02.22

I wonder, JR, if you implementing FrequentBuilds isn't a special case. You are personally willing and able to rapidly deliver large volumes of prescriptions, techniques, and direction within the domain of software development. More, and faster feedback about development won't help people who aren't as sure, or as quickly sure about what to do with the information. -- JimBullock, 2004.02.24

In Re, moves that are often useful when you don't know much FrequentBuilds has several meanings and at least three uses:

• Provoke some information.
• A likely useful practice, absent other information.
• A powerful ongoing source of feedback.

In a recommend / improve someone else's results kind of situation I end up recommending FrequentBuilds a lot, sometimes even as a simple thought experiment. When I'm the one tasked with delivery vs. tasked with assisting others with their delivery, FrequentBuilds is even more common with me. But they are separate cases. OK. Enough of that a-ha moment. -- JimBullock, 2004.02.26

http://fairlygoodpractices.com/

I've been trying to remember the exact domain name for two days. Just goes to show, it's nowhere near as memorable as "BestPractice".

LaurentBossavit 2004.02.23

SherryHeinze 2004.02.23

Re: Frequent Builds

Well, I've been a couple places that more frequent builds weren't helpful, but I seem to have an affinity for deep trouble. Maybe it's karma from a former life. Anyway, two situations where more frequent builds don't help:

• Things are working well enough (in context) that the extra feedback you get from more frequent builds doesn't tell you anything. (Sherry's example is a case of this, I think.)
• Things are challenging enough that more (faster, better, etc.) information from more frequent builds wouldn't get anything happening any faster.

That's actually my heuristic for more frequent builds: can and will somebody do something with the additional feedback this creates? If not, then we might go work on our ability to respond to feedback, whatever that means here.

-- JimBullock, (Or does trouble just find me?) 2004.02.23

Re: Universal Practices

Now, to sort of contradict myself, I can think of exactly two kinds of best practices that seem to be always useuful. The practices vary, but stepping up a level, the kinds of practices are universal.

• Help them, and me, get calm, take in information, and be OK with the information we are getting.
• Move toward refining a baseline, an intended outcome, and thus the deltas between them.

I tend to think in terms of feedback systems. More precisely, I think every kind of intentional behavior can be approached pretty well as a feedback system, either direct feedback on what's going on (CMM "steering" approximately), or feedback at the meta-level (CMM "anticipating" approximately.) So sort of:

• What are we trying to do here?
• Why do we think whatever we are doing will help that along?
• What kind of results are we getting?
• Do we like any of this, or do we maybe want to change it?
• And how are we doing in coping with all this reality happening?

Sorry for the high-sounding fog on this. That's as good as I have so far.

Unfortunately, this stuff is pretty far removed from what "practices" usually means, and doesn't look much like all that productive seeming techie stuff: making code, doing tests, peering intently at screens full of colored squiggles, or scribbling obscure diagrams on white-boards. Doesn't even look like the "Do this" "Do that" pronouncemundos that get associated with expertise (when they are about practices and processes) or "management" (when they are about work in progress.) And the hand-waving. Most of the time less hand-waving, more clarity.

Getting a grip on what we're up to, and another grip on ourselves sounds like I'm channeling Harry Winnipeg, doesn't it? Except for being not as clear as he usually is, and no clever law. Maybe this:

The two hands law of universal intervention (expressed for us kinesthetics, we get it):

"You have two hands. One to get a grip on yourself, and the other to get a handle on what you are up to."

Unfortunately, this human and meta level stuff is the stuff that always works even though it doesn't sell too well.

-- JimBullock (Not Harry Winnipeg - he's better) 2004.02.23

> I have to admit, I've always recommended FrequentBuilds. I haven't yet been in a context where building more frequently wouldn't be more helpful.

As someone who has spent years working on this "one good idea", I can definitively say that more frequent builds do not help until the culture realizes WHY they they would be helpful. I see this all the time. I build more frequently but the builds are useless and management thinks that this the way things always are ("Sure the builds are useless, the developers have not integrated yet"). I have worked in many shops where the code would regularly not compile and management thought that it was reasonable to have developers check in code which was broken.

So building frequently is a practice that is easy to do (I have worked on the tool Tinderbox to make this painless) but actually doing something useful about broken builds, partially integrated features, code which the testing group can use and all the other expectations which go along with it is not a practice but a change in culture. I have had little success with that. Hence my participation at AYE and other similar events.

(this little section is just an echo of what Jim said above, however I hope I am a bit more concrete then my learned friend)

KenEstes 2004.02.24

Agree with Ken, and that leaves me with a further thought and maybe insight into the nature of useful practices: you always get value (so in that sense it's perhaps a best practice) from drilling down a bit into how a practice claimed useful might be useful to you.

Even if you conclude that the practice wouldn't work in your context, the attempt will have taught you something about your work that you didn't know before. If nothing else it will have taught you that your work is not susceptible of improvement from practices like the one you were recommended, so you learn to ignore similar recommendations in the future.

In the best case, from thinking about something like "You could do more frequent builds" you'll reap insights about what is causing your builds to happen at the frequency they do, what you'd have to change to get them to happen more (or less) frequently, what effects would arise from that, etc.

I'm rereading Jerry's BecomingaTechnicalLeader, and it seems to me that assessing and proposing practices fits the MOI model to a tee; you want to look at motivation - "Why would we want to do that"; organization - "What would have to happen around here for that to be useful"; and innovation - "Is there by any chance an idea in this that we wouldn't have had otherwise ?"

LaurentBossavit 2004.02.24

Nice. So building on that, we can play with the question: Why aren't more frequent builds useful? In Ken's example, "build" has no shared meaning. So maybe we can work on that. In Laurent's example we might move from "We can't do this kind of thing right now." to "Why can't we do that?" and maybe "What would it take to be able to do this kind of thing?" Maybe that deserves an aphorism:

The inability to do a change nominates another candidate change if you pay attention.

Ken and Laurent's examples illustrate something I've been noodling with about practices and change: observations, models, and prescriptions.

• Observations - Until you can say: "I don't know what 'build' means." or "This build failed to complete." you have a problem with changing that practice, or any other. Accurately observing what's going on may be a universal best practice.
• Models - Models are like the animals in AnimalFarm: "All models are created equal, but some are more equal than others." So yeah, a model is "just a" model and observed experience trumps a model's predictions. Still some models are more like hunches while others are stronger than that. This matters because practices are based on models of the world. (Disclamimer - see the end note.) If someone claims: "Adding people to a late project makes it finish sooner." I'd like understand how the model behind Brooks' law doesn't apply here and now. Brooks' book describes the model of software development work which leads to his famous law. That model also suggests occasions when the law would not apply. A practice is something like Brooks' law. It's a conclusion, based on a model. The model may or may not apply here and now. The observations that lead to that particular conclusion may or may not be true here and now.
• Practices - These seem to be prescriptions for something to go do, based on observations, and some model of the world. If someone claims: "More frequent builds just won't work here." I'd like to know why, based on what observation(s), and what model(s). If I propose: "Try doing more frequent builds." my client has every right to ask the same questions: "Based on what specific observation(s), and what general model(s)?"

I'm thinking that maybe with observations, models and practices we can steer among BestPractice, UsefulPractices, and BaselessOpinion (and their cousins WeakOpinion, SingleAnecdotalSuccess, GrandPronouncement and SillyPractices.) Here's an example:

"Do more frequent builds because that always works for developing software." is pretty weak. "A always means b" is a weak model, and "You are building software." is a pretty weak observation. Really simple, general laws you can use with weak observations are so hard to come by that we often call them "laws of nature" and celebrate the people who articulated them. Most of us aren't that smart most of the time.

This is better: "Do more frequent builds because you have the time, energy and interest to develop this system somewhat better and don't know what to do differently." This has a stronger model, and stronger observations. And "do more frequent builds" is something concrete and immediate that we know how to do. The whole recommendation goes:

"You seem to have the time, energy and interest to develop this system more effectively and don't know what to do differently to make that happen. So, get some feedback on what's working in your software develoment, and you will likely have an idea what to adjust. One way to get more feedback is more frequent builds, and we know how to do that. Do you want to talk about what it will take to try doing more frequent builds?"

Of course feedback on how development is working is only one of several possible payoffs from doing more frequent builds. It's important, I think, to pay attention to which payoff(s) you are working for if suggesting that change, and generally which payoff(s) you are working for when suggesting any change(s).

Perhaps observations, models, and practices taken together allow for the idea that there are no universal best practices, and the simultaneous idea that some behaviors are very likely silly. "Observation, model, practice" feels like I stole it, but can't recall from where at the moment.

End Note: I'm finessing some arguments mostly around big-philosophy words that end in "ology." There are also lots of other relevant POV. So this is a piece of the elephant, I think. No claim that it's the whole thing.

-- JimBullock (Not all that learned) 2004.02.24

Revision and change control seems like one of the UsefulPractices whose usefulness is relatively independent of context. Perhaps that makes it a universal practice. I suspect for most (successful) software developers, this practice is a given.

It's difficult to imagine any non-trivial situation in which the costs of version control exceed the benefits. I've worked on platforms that had no tools for version control, so people went to the trouble of establishing manual procedures to compensate.

-- StephenNorrie 2004.02.25

Some situations make the costs of not having version control low, so that the value of version control is not sufficient to overcome the reluctance to change practices. I have real-world experience in one such situation, circa 1999:

• We're writing code for a large "portal" Web site, which has tens of thousands of users banging on it each day. This provides that a lot of testing happens all the time, and we get quick feedback. We are editing code on a "pre-production" server; all the developers in the team access the same set of files, through an NFS mount on that server. We make edits, manually test our work, then "ship" modified code in sliver-small increments to the production servers by using an automated sync script.

We talked for a year about starting to use something like CVS, but never did. Ours was mainly a failure of Motivation; or to use Jim's terms, we were lacking both a Model of how version control might have helped, and an awareness that pushing code to the live servers was a versioning procedure - one that destroyed old versions.

Here's another observation - everyone is "for" version control, but I'm not sure that everyone agrees on what good it is to them.

LaurentBossavit 2004.02.25 (This is version 1.1.17 of my opinion on the subject, but I've lost the diffs previous to 1.1.16)

This is a good illustration of why BestPractice is a fatuous concept. Just because I wasn't able to imagine situations in which version control wouldn't provide a clear benefit, it doesn't mean they don't exist. -- StephenNorrie 2004.02.25

In Laurent's example, changes were pretty weakly coupled from each other, and the cost of configuration errors was low (at least three ways: wall time to fix, side-effects, effort to fix). I wouldn't want to try building embedded software that way. Actually I would, as an experiment.

I was going to say: "I wouldn't want to try building operating systems that way." But, of course, Microsoft, specialty vendors like EMC, and arguably Sun (Webstart, applets, and similar) sometimes change the deployment game to make OS software act more like Laurent's portal. Rapid push kinds of technologies like automated patching systems, or just in time software deployment, change the model of how software changes get out there, and the cost trade-offs between delivering one way or another.

Rapid push systems don't change the coupling of the stuff being pushed, as anyone can tell you who's dealt with one of these on-line patches from the Redmond company.

I suspect that in the end all software engineering practices and tools are about changing the performance of how we get from ideas executing stuff. Each tool and technique gives us a different model of how development works. -- JimBullock, 2004.02.24

Adding to my difficulty (see BestPractice) are those here who agree that there are no Best Practices, but find that some Useful Practices are always useful. If that's not one meaning of "best", I'm lost.

MikeMelendez 2004.0225

I suspect you have worked on sufficiently similar-enough context projects that your useful practices are (almost always( useful in your project experiences. As I reflect on my experience with frequent builds, I'm realizing that it isn't always that the build has to be more frequent, but the inability to perform frequent builds is a tipoff to other problems.

So it's not that the practice itself is always useful; it's the inability to perform the practice that shows the other problems in the project. (Did that make sense?)

JohannaRothman 2004.02.25

Yes, it makes sense. "The inability to do a change nominates another candidate change if you pay attention." -- jb

I like the approach here. "What are the options?" becomes the question, rather than "What's the best thing to do?" How your options are limited says a great deal about your problems. It may also point you to solving a more basic problem than the one originally selected. I think is another way of saying the quote selected by jb.

MikeMelendez 2004.02.25

I think maybe we're talking about "rapid builds" meaning two different things.

• One kind of rapid build is poking at the development system, to see what happens. That's like any other kind of quick review.
• Another kind of rapid build is repeated, short-cycle, ideally regular builds as part of ongoing development. That's lots of builds to provide steering input as development progresses.

JimHighsmith talked some about the former kind of thing on this wiki, in 2002 or so, calling it "iteraion 0 release" or similar. Another, similar kind of thing is the development simulation Jerry suggested, also on this wiki under HudsonsBayStart. -- JimBullock, 2004.02.25

As to useful practices in software R&D, they vary widely and wildly. Where testers are not supposed to do anything but tail-end test, various practices are useful. Where testers are supposed to do the developers' tests, a different set are useful. And where I work now, where the developers and CS do the vast bulk of the testing, a completely different set apply. What I haven't seen is anything like the highly regulated software businesses. I suspect that the term "best practice" is in common use there, but I don't really know.

My concern was that in this very thread, "useful practice" was occasionally being used as a mere substitute for "best practice" but with the same meaning given by Phil in BestPractice, though without the edge in his definition.

MikeMelendez 2004.02.26

Actually, Mike, having made the distinction between BestPractice and UsefulPractices, I'm exploring whether I was all wet when I said it (even though it sounded good.) So as a complement to wondering whether practices identified as BestPractice are merely useful, or even misguided, I'm also poking at whether stuff that seems merely useful might not be BestPractice, meaning can be applied fatuously and still does some good. -- JimBullock, 2004.02.27

I think distinguishing a term from its meaning it very important, if difficult. "This is not a pipe."

MikeMelendez 2004.02.28

Seems DOD is becoming aware of how the effectiveness of a practice is related to its context. -- MikeMelendez 2004-04-26

Is it really the practices which are useful or the people implementing them? Jerry once said that good managers will create processes where appropriate, perhaps this is a similar problem of mistaking the effect for the cause. I have been wondering if the power in these best practices comes from the person implementing them having an excuse to change organizational mind-sets more then any particular path the beauracratic paper shuffling takes.

Imagine for example my favorite manager comes in with a process improvement effort and announces that we will now implement the "putz" process. Does it really matter what this process is? I wonder if the attitude of the people following it is more important then the specific rules. Any process is filled with ambiguity and questions about "what does it mean to do putz?". In any process there will be inevitable whitespace that the manager could adjust "to make it work here". It is this "local tweaking" which seems to have the real power and effect the real attitudes of people doing the work. To borrow a phrase from David Schmalz "implementing Putz might be an excuse for getting what the manager wants".

KenEstes 2004.04.29

PhilStubbington 2004.04.29

Way up there, Johanna said, "I have to admit, I've always recommended FrequentBuilds. I haven't yet been in a context where building more frequently wouldn't be more helpful." What about circumstances in which they're already building plenty frequently? What about circumstances in which building frequently simply isn't important?

It would be very tempting at this point (I know!) to roll your eyes and say, "Well, OBVIOUSLY". So when is an organization building frequently enough? When might building more frequently be a hindrance, rather than a help?

I'm currently in a situation where new builds are kicked off every hour or so. For the developers, that's Just Right. For me, testing their code, that's Too Frequent. Who's right?

MichaelBolton 2005.11.01

Who says you have to test every build?

DonGray 2005.11.01

We finally decided we didn't both need to test every build. But we did not reach that decision easily or comfortably. -- JohannaRothman 2005.11.01

Exactly so. The tricks here are two - one mechanical and the other human.

• Mechanically, you somehow need to keep straight who's working with what. Very convenient when everybody's "on" the same thing. But, sometimes this doesn't happen. One big payoff of better (meaning flexible as well as accurate) CM is the ability to keep such stuff straight. Babich has a great, succinct reference on this.
  
  
• For the humans, you need to work out some way of working together that works for everyone involved. Or if that's too hard, write off someone's contribution. So you negotiate.

If you don't negotiate, the real message is the meta-message: "You are not as helpful to me in doing this, as is doing this my own, particular way." That's good to know.

- JimBullock 2005.11.01 (Sometimes helpful. Sometimes hard to help.)

Don: we do engineering builds several times a day, and "QA" builds once a day. Ideally, we would have automated tests that run whenever we do a build. We do have some unit tests, but not enough, and no automated acceptance tests, yet.

KeithRay 2005.11.02

Don: Who says you have to test every build?

Consensus, and context. And, of course, things are the way they are because they got that way.

MichaelBolton 2005-11-02

Jerry has this great exercise ranking 10 items from the Guiness Book of World Records. Consensus groups generate the worst (lowest correct number) scores.

Do you get the testing completed in an hour?

And, of course, things are the way they are because they got that way

Instead of getting some other way. So asking for a change would involve modifying the groupthink and overcoming the existing inertia.

DonGray 2005.11.03