[060] Improve style (Statement-first programming)

[martinmoene]

And here's another.

In this chapter there were a few (parenthetical) remarks that were hindering my reading and understanding of the sentence. I found the information not always important enough to devote words to it then and there, so I removed these. In other cases I tried to keep the main message together and added the remark as an extra sentence. You might judge differently ;)

I made the following change I'm uncertain of: deployment machine => development machine

You write:

There are several reasons and I will try to outline a few of them briefly.

You do not know whether the Statement can ever be false until you see it evaluate as false

To me it looks this is the only reason you describe (be it with three examples).

I've trouble to understand:

• (Unless your Statement is evaluated prior to being fulfilled.)
• Write false Statement (this step ensures that code has high testability)

At some point reading this chapter (can't remember where) I had the thought : Have you come across the term Future Perfect Thinking ?

I made quite a few changes, but I've tried hard to "keep it your text".

Let me know about any changes and clarifications you'd like to see.

cheers, Martin

[martinmoene]

Some further explanation.

I removed the mention of (SCRUM) Sprint commitment from:

Another reason might be time pressure. Let's be honest -- we are all in a hurry, we are all under pressure and when this pressure is too high, it triggers heroic behaviors in us, especially when there is a risk of not making it with the sprint commitment. ... If Specification is written at the end, it is often sacrificed on the altar of making it with the commitment, since the code is already written,

As 0) Not everybody is in a hurry, 1) not everyone does SCRUM, 2) it is not necessary for the subject of time pressure, and 3) most of all I suspect it may be problematic.

You may not intend to suggest that sprint-end-heroic behavior is normal/common or whatever, but I think mentioning it here is not supporting your main line --time-pressure-induced heroic behavior-- and may even harm it.

The scope of the work in a sprint is determined by estimating the time needed to implement its parts and see what likely fits. An estimate is not a guarantee and the commitment to the sprint does not mean a promise to complete it all [1][2]. (Other interesting reading on estimating [3][4].)

Not being able to complete all items of a sprint does not mean we must work harder, longer, differently to try and complete everything. However, the combination of the words sprint commitment, time pressure and heroic behavior do suggest that this is a common reaction and leaves it at that. As I don't think this location in your text is the right place and time to discuss it, it is perhaps best left out.

Hope this clarifies my approach.

cheers, Martin

References: [1] Serge Beaumont. "Committing" to a Sprint and failing is a GOOD thing! March 24, 2010. [2] Jose Luis Soria Teruel. Commitment vs. Forecast: A subtle but important change to Scrum. October 01, 2011. [3] Dan North. The perils of estimation. July 1, 2009. [4] Martin Fowler. PurposeOfEstimation. 27 February 2013.

[grzesiek-galezowski]

I wrote this chapter a long time ago. Looking at it now, I think it would benefit from some e-prime language ;-). I got an issue open (#38) to get back to this chapter and fix few things. I'll answer your concerns when I review all the changes, as I can't remember everything I wrote back then.

On sprint failures - I should have written that this was my observation that an end of a sprint looked like saving a sinking ship every time I looked (and commitment was being missed). This is backed by some other people's observation. I remember my intention was not to write that this is how things should be or that this is what SCRUM is about, so maybe I failed to state this intention. Speaking with some of my friends who work in several other companies, I came to think of it as being a common reaction. This is the reason I found it worth to discuss - because it was so common. I agree though that this has more to do with "missing a deadline" than with SCRUM in particular.

[martinmoene]

Meaning of Sprint commitment according to ref [1] above:

• fixing the scope of a Sprint.
• team pledges to each other that they will strive to reach the goal.
• not about accountability and holding a team in judgement after a Sprint.

[grzesiek-galezowski]

Some of the answers I still owe you:

"To me it looks this is the only reason you describe (be it with three examples)."

The reasons are:

• You do not know whether the Statement can ever be false until you see it evaluate as false
• “Test-After" ends up as “Test-Never"
• "Test-After" leads to design rework

The structure is a bit broken currently. I raised the issue #38 to address it after our last discussion on one of past pull requests (as far as I remember). Just give me some time :-) to finish the second chapter on value objects and I'll review the structure along with content to make it more logical.

Because (unless your Statement is evaluated prior to being fulfilled), your custom xml string will never actually be used!

This is in fact confusing. I think I meant that the string is not used unless the Statement using it is the first one to initialize the static variable. Otherwise, the Statement might always pass or sometimes fail, but for the wrong reason. Then, what I think I forgot to mention is that by writing a Statement first and seing it pass somehow while it should not allows to detect the problem. I need to revisit this example a bit. For now, could you incorporate this feedback into the text?

Write false Statement (this step ensures that code has high testability)

probably does not express what I meant as well. What I meant was that the place where we detect testability problems is moved to this step. Maybe it would be better to write something like:

" Write a Statement that is currently false (during this step, detect and correct testability issues even before the tested code is written)"

or something similar. What do you think?

[martinmoene]

Thanks, I'll have a look at it tomorrow.

[martinmoene]

I've changed the last two items above to:

Good for him, not so good for you. Why? Because, due to how initialization works in C#, either the original XML string will be used for all Statements or your custom one! Thus the Statements in this Specification may pass or fail for the wrong reason. Writing a Statement first that you expect to fail and see it pass might help to detect this.

and:

Write a Statement that is false to start with (during this step, detect and correct testability issues even before the tested code is written).

I'd like to suggest to defer more/other changes to after merging this PR and continue working from the updated text.

cheers, Martin

[grzesiek-galezowski]

Agree. I like the modifications you've made. Thank you for you hard work!