Agile Otter Blog

Imagine if you would a class in an object-oriented language. Notice that x() and y() are not constructors. Now, a "good" user of an instance of Trouble will do something like this: t.x(); // always call x() before y()    t.y();  Whereas a naive user of the class might do something more like this: t.y(); In this case the value of i1 (used by function y )  is either undefined or possibly some leftover value from earlier uses of instance t. How Do You Know? The functions x and y have an implicit temporal binding.  When you look at the object diagram, or if you use code completion, nothing you see will tell you that you must call x before y . Either: You don't know about it, and have been "just lucky" so far You don't know, and are currently making bugs you don't know about You know because you've read the code from top to bottom and understand the implicit temporal coupling.  You copied someone else's example after y...

Your employee “wastes” time doing a feature you didn’t approve. You find out about the feature as it is being released to customers. Customers are enthusiastically happy with the new feature. Thrilled, in fact. They complement you and your team! Do you reign in your rogue employee  give her more influence in deciding future features ignore this one infraction since it worked out okay Quickly write down your answer and then read the next paragraph. ... Okay, you've written down your answer. It doesn't matter so much to me what answer you chose, or if you chose one not given above. What I want to know is what were the principles on which you based your answer. How important was the outcome v. the process?  How crucial is conformance and predictability of action v. success of action and engagement?  Was the employee's act one of insubordination or service to customers?  Which is more important?  If you complete this little meditat...

The question was asked: In Test-Driven Development, what does it mean to start with a failing test?  This is not a complicated question, so let me give the short answer: Write a test that can't possibly succeed because you have not yet implemented the feature; but which would succeed if the part of the feature it's testing were written. You want it to be a good test: clear, obvious, simple, discrete. You want it to fail, so you see what the error message will look like -- whether it will provide enough information when someday it fails unexpectedly. Then you write enough feature that the test passes works (but not the whole feature). The idea is like a video game. You write a test, which is your first challenge. Then you beat that challenge and save your game (to version control) so you can come back. You layer on the challenges until you've beat the game (written the feature). There is more to the TDD cycle, but this is enough to answer the one questi...

Sometimes I receive bizarre statistics in email. So: Rank of world for  agileotter .blogspot.com is 14,111,324 It sounds like my blog has ranked this world the 14-millionth favorite, but I think it means the opposite. I have plenty of margin here so that I can improve without running out of space.  Whew!

if we all could put curiosity and interest in others over the warm self-righteous glow of disdaining and judging, then we could do all things. As long as we go about magnifying the differences and heaping shame on people who see things differently, we will continue this path. It’s a choice. Maybe your vote isn't the most important choice you could make this month.

An old story I’d almost forgotten resurfaced for me today. A guy who spent his entire career in the same company, in the same state, mostly in the same building, mostly with the same bosses who were of the same management philosophy once corrected me when I was talking by saying “yes, but in the real world…” It was the first time it became clear to me that “in the real world” could not only suggest that my views are naive, but that the speaker is from a very specific (and perhaps naive) context. It didn't have to be. Sometimes I am naive, but not every time. "In the real world" only meant that my experiences did not coincide with his, and therefore my sense of cause-and-effect seemed far different from the "laws of work" where he spent his time. I must have looked like an alien to him, as he did to me. The things I said about trust, team work, values, and practices sounded entirely unworkable because they didn't follow the rules of his control-...

Yeah, I know that title is going to be a bit inflammatory, and everyone knows what they expect when they see it up there. But that's okay. My topic is really about such things. I want you to consider: Saying hurtful things Not being politically correct Telling the truth What I want you to consider is that these are three entirely orthogonal concepts. One can make statements which are any one of the above, without being the others.   One may easily say offensive things which are entirely politically correct. It's a common event on the internet to see people shaming others in the name of Political Correctness (which should be all about being fair and kind to others, but outrage is virtue these days). Some of the shaming statements could be true, and some could not be true.  One can certainly state truths in kind ways, full of compassion and empathy. Even ugly truths can be delivered in considerate ways.  One can say things that are true and not ...