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...