Agile Otter Blog

 I remember the 80s. It may have been before your time, but that's okay.  There was this cool new thing in the 70s -- a personal computer. People were hyping the heck out of them, and I guess they were right. There were people arguing against them, others getting on board, and others cautiously looking for good uses for this new boon.  Someone had this cool new program for computers, starting with VisiCalc for Apple ][.  Later on, other vendors jumped in with Lotus 1-2-3, Quattro Pro , and eventually Excel .  Anyone who could type, make lists, and do arithmetic could build a spreadsheet.  This sounds trivial now, because you're all used to these things, but it was huge and disruptive at the time. ANYONE who could type, make lists, and do math could have a custom program developed in minutes or hours, and didn't have to learn any programming languages, DDL, DML, file system arcana, ... none of that! The thought at the time was that this would change the wo...

Some time ago, Jeff Langr and I came up with seven virtues for code in Agile in a Flash , and we wrote more about them over the years.  The original set is:  Working, Unique, Simple, Clear, Easy, Developed, and Brief. The virtues give us some words for what we like about good code, and they've been remarkably stable, with two exceptions: 1. I've added the 8th Virtue ("Coherent") 2. I've dropped the ordering. Working is non-negotiable; the rest work in balance. Since I've added an 8th and people have expressed interest, it seems prudent to produce a new, fully unified version of the list with more examples and suggestions to help people translate the rules into skills. This write-up is for human consumption, of course, but there are notes and recommended readings that may help in other purposes. Let's begin: --- Evidence, Subjectivity, and Judgment The virtues are not all subjective qualities. Clear is subjective because clarity exists in the relationship...

 I don't know if there is another name for this pattern, but I've been calling it "progressive admission" and using it for many years. It is a story splitting skill, related to the "walking skelton" AKA "tracer bullet" technique. Say you are about to build a program that reads from a message queue and processes messages.  Start Closed The first stage is to build the end-to-end system (reader, checker) that does nothing. No matter what you feed it, the front-end checker (correctly) reports that it's not implemented. This is beginning all closed.  At this stage, you can start testing the clients and the exception handling/reporting.  First Admissions Now you pick the simplest message. It could be a health message or an ill-formed message. This one message or message type is admitted . The program correctly rejects the ill-formed message, or answers the health message with a hard-coded message result. At this time, all other messages are rejected ...