Skip to content
Home » Blogs » JurgenAppelo's blog

Copy-Paste Reasoning

May 30, 2008 by JurgenAppelo

WrongWay I have a bit of trouble with people who use other people's opinions and arguments without thinking them through, or without analyzing a situation before applying their copied ideas. And worse than that: some people tell others that they are wrong, without bothering to investigate if their copied arguments actually hold within an unknown context.

I call it copy-paste reasoning.

Examples?

"You shouldn't do fixed price, fixed scope contracts, because..."
Fine, but that doesn't help me if that's the only thing my biggest customer wants.

"Big up-front requirements are wrong, because..."
I know, but my customer just handed me a 200 page requirements study and he pays me to implement it.

"Teams must be cross-functional, with all roles represented in the team, because..."
Sure, but the customer contracted another party for front-end design, on the other side of the country.

"You have to do iterations of four weeks each, because..."
Right, but that doesn't help me much if my project only lasts for three weeks, does it?

"You're wrong when your people carry out evaluations with on-line forms, because..."
Wow, are you psychic? Are you able to understand our people from the other side of the ocean?

I appreciate any kind of advice from any source, including advice that doesn't translate well to our context. It is an opportunity to learn and to understand how our situation compares to, and differs from, the world outside.

Context Matters
However, best practices are always context-dependent. You cannot tell someone else what to do, without understanding their context. Even if you're 95% right, people will only be digging their heels deeper when you don't acknowledge that their situation is slightly different.

So, I advise you not to apply Copy-Paste reasoning.

Use only apply Copy-Paste Special... and carefully select your options.

Bookmark/Search this post with:
  • Delicious
  • Digg
  • StumbleUpon
  • Propeller
  • Reddit
  • Technorati
Permalink

Comments

First adopt, then adapt...

May 30, 2008 by hmoeller, 31 weeks 3 days ago
Comment id: 1555

Well, I don't really get your point. You are publishing your articles on a blog called "Agile Software Development". This kind of sets a context, don't you agree? All those arguments are justifiable within this context - the only one we have in common.

I didn't understand "inspect and adapt" to be meant as a license to drop all those agile patterns and replace them by what we consider the only possible solution in our special context.

Prior to adapting the process, we have to adopt it. And I consider it a very good practice to first adopt it as consistent as possible.

I do agree that there most probably are lots of circumstances in our daily business which set really serious constraints on what we are able to adopt and what not. But this is part of the process. The trick is to continue adoption - probably by doing "Baby Steps" - where ever possible.

But what I disagree about is taking those constraints as an excuse for keeping old practices and labeling them "agile". I expect the risk of failure and in the end, this will be blamed to agile processes where it actually would have to be blamed to yet incomplete adoption.

Adapt, skip Adopt

May 30, 2008 by JurgenAppelo, 31 weeks 3 days ago
Comment id: 1558

@hmoeller: I think you're disagreeing with something I didn't write. I am not in favor of keeping old traditional practices. I am in favor of doing things the agile way. However, sometimes the adopt-adapt sequence doesn't work. Sometimes you have to go straight for adaptation, because adoption of the practice straight from the book is impossible. What I'm talking about in this post (which possible wasn't clear enough) is that I don't like people telling others that they are wrong when they skip adoption and go straight for adaptation.

skipping adoption is at least *risky*

June 6, 2008 by Ilja Preuß (not verified), 30 weeks 3 days ago
Comment id: 1571

In my opinion, the only way to really understand, say, a practice is to have tried it for a while. And adapting something to your own needs is the more risky the less you understand how it works when adopted as-is.

I agree that "you are wrong" is not a very helpful reaction. On the other hand, "we can't do that here" is as unhelpful - and often less than accurate. More often it means "doing it seems too hard" or "doing it seems too risky" or "I couldn't possibly get 'them' to agree doing it". And often those are based on false premises regarding how the practice really works, or what consequences applying it as-is would have.

That is, I see a lot of what I perceive as premature adaptation, and the results are disheartening. And worse, often enough the disheartening results are attributed to the original practice, not the adaptation. That's were a lot of the strong reactions are coming from...

@Ilja: That's a good

June 6, 2008 by JurgenAppelo, 30 weeks 3 days ago
Comment id: 1576

@Ilja: That's a good comment. I think we can agree on this: Sometimes you have to adapt, and not adopt. But not understanding the difference, and its consequences, might be worse than the cure. Thanks!

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <b> <i> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <img> <br> <blockquote>
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>. Beside the tag style "<foo>" it is also possible to use "[foo]".

More information about formatting options

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.

Best of AgileSoftwareDevelopment.com