Agile Otter Blog

Code degrades because it is strongly anchored to the past. Instead of updating, refactoring, reorganising, and rearchitecting the code as we learn over the years, a system tends to keep its original shape, as developers shoehorn new features in with If/else statements. Imagine you are one of N people working individually in the codebase, each of you on a personally assigned task, not in groups. Any change one of you makes has a non-zero chance of causing a merge conflict for someone else. The larger the change, the greater the chance that some part of it will conflict. Multiply that by the number of people making changes. Remember: when separately-made changes conflict, the first person to merge sees no problems, but the second person to merge has to resolve the conflict.  People hate resolving merge conflicts. It is tedious and exacting work. You have to understand not only your own change, but the other person's, and figure out how to harmonise them. If you get on...

When I said  tickets have almost nothing to do with agile software development,   I was greeted with some very odd looks and incredulous "huh?" sounds.   So... Agile and stories In the beginning, the processes that were to eventually become agile were focused on delivering early and often, getting frequent feedback, and applying what they learned to the codebase so that they can continue developing early and often. To do this sustainably, it was necessary to use taste, judgment, and good craft so that the code remains ready to take on new knowledge and new functionality. To support that, XP chose to always work in groups (pairs, generally) and to have lot of tests to support refactoring, and lots of refactoring. So how does one keep track of what needs to be done - what customers have asked for? For this we had user stories (likely no relation to what you've seen called 'user stories'). The user stories were typically written on a sticky note or a card, since team...

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