Microtesting Python Album

I'm working with Industrial Logic's newest Python album on microtesting (not yet released) and was lucky enough to get to test out the automated critique.

So the way this eLearning works is that you download a problem to work on, and you're given tasks to perform. In this case, it's all about writing microtests for some simple python code. When you finish, you upload your results and an automated critique system digs through the code and gives you ratings and pointers. This is rather like having a mentor sitting with you, reviewing the code.

I tell people that the eLearning here is something like they've never seen, but people think I'm marketing or something. Today I have a story for you:

Yesterday I made a mistake and the automated critique busted me. The mistake was one where I constructed an object incorrectly and invalidated the premise of the test, yet I did this in such a way that the test passed for the wrong reason. I was feeling so sure I'd done it correctly that I thought the critique was wrong. I pasted a copy of the test into my error report before I realized I was in the wrong.

The coolness didn't stop there, though. Through all of this, my tests looked nothing like the tests that were presented in the course material. The eLearning system allowed for my stylistic differences only flagged the actual error in my code.

Slightly humbled, I corrected my test and uploaded it again for analysis. This time I was 100%. The online course gave me advice and allowed me to try again.

When it comes to developing skills, anyone in the business will tell you that guided experience is the best teacher, but I've never seen a system guide my skill development like this one does. Today I found out there's even more guiding intelligence on the way. Watch this space for details.

Short Reach Revived

This first appeared on the Object Mentor blog in 2007, but I had to get a cached copy from google to reread it. I'm reviving it here so we don't lose it forever. I think it is still carries a valid point, and I would like to revisit it in the near future.

Short Reach
Posted by tottinger on Monday, April 23, 2007

I’m always trying to find newer, better, shorter, more powerful ways to explain what Agile is about. I suppose I’m some kind of obsessive about expressive power and economy.

Finally I decided that Agile, as I understand it today, is about the short reach.

It seems to me that all of the agile practices are about shortening our reach, the distance in time-and-space that one leaves an assumption, decision, or line of code untested and unconfirmed. All the practices seem to follow this one rule.

• The customer/analyst is kept in the same room, in the same short reach. 
• We feed back the iterations to the customer/analyst so that his every decision has a shorter reach. 
• We do iterations to ensure our planning has short reach. 
• We keep our teammates very close, in the same room, so that it’s a shorter reach to them. 
• The test is written first, so that implementation has shorter feedback on correctness. 
• We compile/test frequently because our code time should have a short reach. 
• We pair so that our code is instantly vetted through a peer. We don’t pile it up and review it after the tests pass. 
• Our planning is based on “yesterday’s weather”, data collected a very short time ago. 
• We don’t plan the team structure and the assignments, we self-organize so that tasks are waiting for the shortest time possible. 
• We talk face-to-face, not across chat and email and official company documents. 
• Tell-dont-ask and the Law of Demeter guide us in keeping the reach of our objects very short. 
• We use unit tests to exercise a class directly, and we isolate with mocks to reduce the reach of our tests through the system. 
• Shared code ownership means that the guy sitting behind your keyboard has all the permission he needs to do excellent work, even if it impacts existing design. 
• Test-first development means that the guy who makes a change knows very quickly whether his change is safe or not. He doesn’t have to wait until the week before integration when the “real” tests are run. 

Where does Agile run into logistical or operational difficulties? Wherever a long reach is required or imposed. Where an organization chooses to continue in waterfall-style management, where the team is distributed among managers with appointed “point of contact” and “official channels”, and where the developers are not placed in a common work area agility is very difficult.

I’m not saying that agile techniques can’t work for large companies, but that is an area where a lot of experts are trying (maybe succeeding) to extend the agile techniques and where the average “agilist” finds challenges. When it works, it is almost certain it will be because someone has found a way to shorten the reach of the teams so that all they need to know is never more than a few seconds or minutes away.

At least that’s my half-baked observation of the day. Let me know if I’m wrong here. Or if I’m more right than I think I am.