Agile Otter Blog

Today we didn't make a lot of linear progress I think of quality in two ways.  One is the product quality that users perceive, and the other is the habitability of the code itself. One says whether the function points and UX are well-selected, and the other says whether it is worth your time to try to work in the code.  One can have crap code that seems great externally, and one can have beautiful code that doesn't do anything a user is interested in doing (the popularly presented dichotomy). Likewise one could have poor functionality written poorly, or great functionality written well.  Those who consider themselves professionals in software craft will desire great functionally written well. I often get to work in code that started out as good functionality badly written. I get to work on the teams that clean up the mess and make the system more useful, scalable, and performant. As we work, the code gathers external quality. It becomes increasingly virtuous .  S...

We say "embrace change" and "accept changes to requirements, even late in the process."  We also rant about focus and that developers should neither be interrupted nor allowed to multitask.  To a lot of people, this sounds just like a contradiction.  Are we hypocrites? There is no conflict in these statements. The problem is with the organization. Change In A Change-Resistant Culture If, for example, I plan a release in 10 months, and assign each of my developers a ten-month task (or a couple of five-month tasks) then I am not only at capacity, I'm likely well over and don't know it. Now, in month two I have a change I would like to see. I can't get any of my developers to put aside their work and take my task.  Those obstinate developers!! What's wrong with them?  Nothing is wrong with them.  They are doing the work they are assigned, and since they have no slack or reserve capacity they know that the new task puts their release in jeopard...

I wake up with odd memories. I think my brain is just getting exercise, staving off senility maybe. Yesterday I woke with a memory of a bug fix from long ago, probably 15 years or more. I was given a project which led me into the permissions-checking code of a billing system. When I got there, I saw the code was written in such a way as: permission* perm = GetPermission(thisPerm); if ( perm != null && perm.Allow == false) { return false; } return true; I know that's silly, but I am recreating from an old memory, and I remember the code having some silly uses of null & the like. I remember noticing right away that if a permission did not exist, it meant that the user can perform the activity. GetPermission() read from a database table, I think, so that all a user had to do to get unlimited access was to drop records from a table. Furthermore, if an installation tech didn't deny access to unpaid features, the customer got them for free. I don...