Steven James' CNN Editorial on sugarcoating the bible

I think that this in an interesting article. However, I think that the author is doing a little filtering of his own. He is filtering differences in translation through modern ears. Part of a good translation is not necessarily translating word for word. Try reading a translated poet like Rilke and you'll know what I mean. When translating, especially when translating the metaphorical or the ...poetic, you need to be able to find phrases that have the same impact and color as the original language.

"... let’s pretend Paul said that he considered his good deeds “a pile of garbage” in Philippians 3:8 rather than a pile of crap, as the Greek would more accurately be translated."

A great example, this. How do we know that in ancient Greek, the language Philippians was originally written in, saying "pile of crap" has as big an impact as on our Victorian principled ears. Language, sensibilities, and customs all change throughout the years. Last night, on regular broadcast TV I heard the word "shit" and really thought very little of it. Can you imagine hearing that coming out of Jack Tripper's mouth in the late 70s? Everyone would have been aghast and up in arms. Times and sensibilities change. Words change. Sometimes they gain impact, sometimes they lose it. Perhaps in Greek 60 A.D., "crap" had as much impact as "garbage" does today. I don't speak a word of Greek; modern or ancient, so I don't really know. But I do know that the author of this 'opinion' doesn't even mention the possibility.
To claim that we can't "edit" the Bible, or to "filter" it with modern sensibilities, the same has to be said for those who created the modern translations from the original scripts. Perhaps they actually knew what they were doing and used words that had the same "oomph." Perhaps the author was right and they sugar-coated the text to make it more palatable. I don't know, and I posit, neither does Steven James. If he does, he doesn't give evidence of it in this article.

A groan escapes the lips of every software tester every time he’s asked to write a test plan.  Some of us know what they are.  Some of us know the pain in the a$$ that they are to write. Some of us know that they need to be done. Some of us know that they consist of many different types of information.  But what we all know is the following:

After a test plan is initially written, almost nobody ever looks at it again.

But still, we all know that buried in the “Definition of Objectives,” “Schedules,” “Target Equipment Required,” and all the other bits & pieces of a “Good Test Plan” there lurks a few bits of useful information.

Going off on a rogue testing excursion may produce and find a few bugs (or maybe even a lot of bugs), but it’s not going to give you any sense of confidence that you hit all the major areas you need to test.  You do need to plan somehow.  How, then, do you avoid wasting time on a document that nobody is going to read, but still produce something useful?  

I’ve found that Mind Maps are extremely helpful, imminently logical, and almost universally useful for everyone involved.  It’s easy to pick up a mind map, follow the logical path of your thought process and either let you know you’re a genius or point out a few things that you might have missed.  Secondly, mind maps can double as your test cases as well. 

Take this example for example (click the image to view the whole thing):

While at first glance, it might look complicated, but when you take a moment and really look, you can see how it fits together and how it could be useful to you.  Best of all, this is something that you can go back to when it comes time for regression.  It becomes very easy to insert items that you may have missed and further, it’s something that other people in your organization will be able to understand.  Developers can use this to quickly determine if they’ve covered all the use cases, or better yet if you have.  Openness and transparency has been proven time and again to be the best policy for producing rock solid software. 

This mind map was produced with a piece of software called  XMind; though a piece of paper, a whiteboard, or even a wall might work as well for you.

I’d love feedback on this, feel free to drop me an email with questions, suggestions, or corrections.

Powershell makes doing math on Date object easier than falling down!

   1: $time = Get-Date;

   2: 

   3: ##Show Minutes

   4: $time.Minutes;

   5: 

   6: ##Show Day

   7: $time.Day;

   8: 

   9: ##Find out NOW stuff

  10: (Get-Date).Day;

  11: (Get-Date).Millisecond;

  12:  

  13: ##What Will the Date be 90 days from now?

  14: (Get-Date).AddDays(90);

  15: 

  16: ##What was the day 90 days ago?

  17: (Get-Date).AddDays(-90);

  18: 

  19: ## And for something practical

  20: $startTime = Get-Date;

  21: $endTime = Get-Date;

  22: "DONE in less than " + ($endTime.AddMinutes(1) - $startTime).Minutes + " Minutes";

As you can see, wonderfully simple.

When you are writing in the script window, you can access your execution history.  Simply type a comment hash character “#” and hit [TAB].  That will pull up the last item in your history queue.  Continue hitting [TAB] to traverse up the history queue as if you were in the command line window hitting the up arrow.

We all know that a good user story (in the agile world) contains

• Enough facts to give the delivery team (Dev , QA, DBAs, Operations, etc.) a direction
• Enough proper estimation to allow the product owner to know when he might expect delivery of the story
• Enough detail to know when the team has completed the story.

We should all be familiar with the “As a [role], I can [feature] so that [reason]” format of writing a story (quote swiped from codesqueeze.com).  And we should all be familiar with Ron Jeffries’ 3 C’s (Card, conversation, and confirmation).  The thing that gets lost most often, I think is that second C. 

So I have two anecdotes for you to demonstrate the value of “conversation”.  (I’d call them stories, but that would just get confusing).  For the purposes of these anecdotes, the delivery team is represented by the store clerk and the product owner/manager is represented by the customer.

Anecdote #1:

Joe Customer goes into the EverythingMart where they sell absolutely everything (as the name implies) and finds Steve Storeclerk. 

“Hey there Steve!  I’m back again and I need something from you!”

“Sure,” Steve replies, “How can I help?”

Joe Customer rubs the back of his neck with a well worn handkerchief and says, “Well, I need to haul some stuff, so I need to buy a truck from you!”

Steve’s enthusiastic to help so he pulls up the catalog of trucks on his terminal, “Perfect, we’re getting some new ones in a couple weeks!  Why don’t we sit down and take a look at what will work for you.”

“Two weeks, eh?” Mr. Customer asks, “Well, alright, I suppose so. Let’s see what you’ve got.”

The pair of them look through the catalog and pick out a blue one with chrome bumpers, GPS, and a gun rack (they live in TX and it’s a free option, so why not?).

A week Joe Customer comes in with his check for $30,000 and drives his truck home and does his hauling.  Everyone seems happy.

Now, as a “Story” we could write this on a card as …

“As a customer, I can haul heavy things, so that I don’t kill my back.”

Seems to meet all the criteria for a good story, right?

Anecdote #2:

Joe Customer goes into the EverythingMart where they sell absolutely everything (as the name implies) and finds Steve Storeclerk.

“Hey there Steve! I’m back again and I need something from you!”

“Sure,” Steve replies, “How can I help?”

Joe Customer rubs the back of his neck with a well worn handkerchief and says, “Well, I need to haul some stuff, so I need to buy a truck from you!”

“Of course, I’m sure I can help you out.  What exactly do you need to haul?” Steve asked.

“Ummm…  I’ve got some bricks that I need to bring over to my neighbor’s house to help him build a barbecue.”

Steve nods sagely and asks, “Right… And how far do you gotta haul these bricks?”

“Just two houses down,” he’s told.

Steve then logs onto his workstation and starts to browse around looking at gardening implements.  “I think one of these wheel-barrows will do just fine.  And we have them in stock right now.”

Joe Customer’s eyebrows arch inquisitively. “So,” he asks, “you don’t think that I need a truck, but this wheel-barrow will do?”

“Absolutely!” Steve tells him.  “And this will save you a bundle!”

Joe nods, whips out his credit card and pays $50 for a brand new shiny wheel-barrow.  Sure, it’s going to take him two trips to get all the bricks moved, but he’s still going to be finished by the end of the day.

Now as a “Story” we could write this on a card as …

“As a customer, I can haul a load of bricks to my neighbor’s house, so that I don’t kill my back.”

Sure, the first story seemed well defined, the customer told Steve exactly what he wanted and got what he wanted, albeit at a pretty heavy cost in terms of $ and time.

In the second story, though, with conversation Joe Customer got what he needed immediately and at a substantially lessened financial burden.

We should never assume that the customer knows exactly what they need.  Instead of dictating a solution, conversation allows us to solve the need.

To paraphrase a Rolling Stones song…

“You can’t always get what you want (at a decent cost). But if you have a conversation, you just might find, you get what you need.”