Agile Otter Blog

Say someone wants some aspect of my behavior to change: dress, schedule, food, drink, speech, whatever. I initially get a little upset, defensive. But that's not productive. That's just anger and ego protection. Is there a more excellent way? I'm told that the secret to success is to replace judgment ('that's none of your business", "you are trying to control me", "screw off, I do what I want", "that's not fair") with curiosity . "replace judgment with curiosity " Curiosity. Hmmm. Let's try that. I wonder where that will lead. I'll have to suspend my anger and judgment and blame and quit assigning motives to others if I'm going to process this with curiosity. So much is possible now, and there are so many questions: So, why is it so important to you that I change how I behave? Is it for a purpose?  Does it serve you in some way?  Is it because you care about me and think it ...

Most of agile is about delivering sooner and a lot more often , so that you can incorporate the client's desires and feedback into your daily work.  The rest is about how to make that sustainable for development teams.

Ideally, we would have excellent and obvious names for all variables, classes, packages, methods, etc. But it's hard to be excellent all the time. People building the java libraries struggled with names, I can tell, and though I don't always appreciate their choices I recognize that this is a multifaceted problem. Maybe a moment of agonizing over a bad name might help share a mental model, and some patterns or smells for naming methods. Let's give it a shot. A Tiny Example Here is a tiny, dull, dumb snippet:  Date now = new Date();  DateFormat df = DateFormat.getDateInstance(LONG, Locale.FRENCH);  System.out.println(df.format(now)); Java has a method called getDateInstance() . Does it return an instance of a date? No, it does not. If it lived in a package called Date then it would be a terribly wrong name, but it doesn't live there. It returns an instance of a date formatter, whose class is called DateFormat. DateFormat doesn't seem like such a...

I wrote a question for the twitterverse: I assigned a story each to Sarah and Joe. Joe's feature made the company 4x as much as Sarah's, so Joe is the better programmer, right? — Tim Ottinger (@tottinge) February 10, 2016 Give that question a moment's thought and tell me what you think as a knee-jerk reaction. About Joe and Sarah Of course Joe and Sarah are fictional characters. No this isn't a gender question. I thought it would be wrong of me to pick two female names or two male names. I figured that there is really no way that I am going to get out of this without answering to questions (or charges) of gender bias no matter what I do, and so I decided to pick two names roughly at random. It didn't dawn on me that they're both European/American kinds of names until later -- so bias is probably real there. But what if one was an Indian name and the other Chinese? I can see that having all kinds of issues too. So I have two names, and please ...

I want to drop in a quick note about variable and class naming, one of my favorite hobby horses. I talked a little bit about choosing more completable names already. I think that is very important, and you would be well-served by paying attention to that bit. Today let's consider the serial position effect . In any programming namespace, we're going to come across some naming issues. Here is a non-comprehensive, non-exclusive list: Objects with a common base will want to include the base class name in the derived class, leaving us with MonoNUnitTestRunner derived from NUnitTestRunner derived from TestRunner , possibly breaking naming in its derivation from CodeEvaluationRunner and on and on. Objects in languages with declared interfaces have a tendency to want to declare the interfaces in their names. An iUserAction will have a UserActionImpl in many cases, whose children may follow the prior rule above.  People love naming the patterns they use in implementing an ...

Productivity is clearly some kind of ratio; it is some kind of N:M relationship, but it's hard to know quite what the N and M are. Of all the poor ways one may define Productivity for software developers, there are some really horrible formulae including "lines of code per developer" and "story points per iteration", measures which really measure all the wrong things and which might send Charles Goodhart into a tizzy. Rather than rant more on those, let's cut to the chase and give the definition that most people really use: (what you did) ---------------------------- (what I wanted) You see, management is really not a data science. It is generally practiced as a semi-educated gut feel, because most managers in software organizations are really programmers risen through the ranks. Maybe 1/3 of them have studied computer science (judging by the popularly quoted folk-statistic that 30% of people work in the area of their college major).  M...

Over at Reddit  there is a discussion about my Stop Per-Person Swimlanes article at Industrial Logic . This surfaced what seems to be a common misunderstanding. Some people think that the board was designed to facilitate public shaming. It's to motivate members in a team to work harder. When your personal progress and responsibilities are put on a clearly visible chart somewhere it's a bit different than a sea of todo's some of which are labeled with your name.  There are a lot of answers, agreeing or disagreeing (mostly disagreeing).  This one stands out: It's different. Whether it's a good thing or a bad thing is EXTREMELY unclear.   My take is that in most corporate environments that is a BAD thing. Why? Because, rather than thinking about the overall health of the code, coder's main concern is getting that ticket closed [emphasis mine - tro] .   Which is a very straight path to the quick codebase degradation.   Meanwhile, your v...