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

I'm talking to users of statically-typed languages today. Functional and dynamic language people, cut them some slack and realize I'm not talking to you. Breaking with Conventional Wisdom There are certainly Object-Oriented design pundits who will argue that you should never, ever have public variables in a class. The reason is good enough, that the object should be responsible for its own state. You should tell it to do things, and it should do them. Likewise you should not manipulate its variables for it, since that requires a strong understanding of valid states for the objects, and this understanding is a strong coupling. Strong couplings between classes are bad things. All of that wisdom is correct and proven. However, many programmers make bean-ish objects where every private variable has a getter and a setter. This helps to preserve uniformity of access (you can't tell if it's calculated or stored, method or variable), but is otherwise the same as exposing pu...

SOLID design FIRST -rate tests Virtuous code I understand the "just get it done mindset" because there is a lot of learning, thinking, and doing behind those three simple links. It is daunting. Any developer who can sling code could become considerably better at coding and more desirable as a teammate if he would learn and apply these concepts in his daily work, but it won't happen overnight. Jeff and I built these 3x5 cards and simple explanations on the web site, but we don't pretend that you can live on these sound bites alone. The cards tell you what the words mean, and that's a good starting point (better than winging it), but the part that matters most is the part that won't fit on a card, the part where one practices. I like the word "practice." Wherever you are writing code today, it is practice. You are expected to apply principled development and get better, but even if you are slap-dash hacking things together, you are building your ...

My assertion today is: If we would read the code we're writing, we wouldn't write the code we're writing. We know the red->green->refactor cycle, but I find repeatedly that programmers are "optimizing" out the last step. It tends to run more like red->green->next. Perhaps there is confusion over what is supposed to happen when the test turns green. The first thing that is supposed to happen is that you read the code you've just written to see if it makes any sense at all. While this sounds perfectly sensible, it often does not happen. Programming is not just typing. It is easy for programmers to rush to complete their assignments and never really examine their work. I saw an example recently where the old code said: DateTime date = DateTime.Parse(datestring); As a minimal-perturbation change to push to green, the developer changed the code to say DateTime date = DateTime.Parse(DateTime.Now.ToString()); Had he or his partner actually read th...

My biggest problem with American culture is the concept of "the locker room speech that wins the game". I don't doubt that people get down and can use encouragement. A little validation can go a long way, and mistreatment breeds dysfunction. If you treat a winner like a loser, expect to see some losing. I get all of that (sparing you the painful personal history). My problem is with the absurdist version of the story: the mythical team that is filled with execution issues, poor teamwork, low degree of individual skill, and an enemy with both superior skill and a history of success. In this story, it is one stirring talk from the tough-but-beloved coach that turns the team around. They charge the field and play like a commando team, each overcoming all personal skill issues and all of them meshing into a perfect winning machine. In the real world, it is unlikely that the problems a technical team faces are motivational in nature. Maybe a team is struggling with ...