Agile Otter Blog

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

If a man was to borrow his his boss' car, drive it hard, fast and carelessly, and then return it with the interior filthy and ripped up, he would probably get fired (or be first in line for the next cut). Doesn't it seem funny how many people do the same thing with their employers' source code?