Agile Otter Blog

We talk about failures a lot. Fail Fast! Safe to Fail! Learn from Failure! One would think that  people hire us to screw things up. Why the fascination with failures? Why not talk about successes? Admittedly, the dialog is off-base a bit. We're not really keen on failure at all. We don't like to be wrong, and would hesitate to ship a product if we knew it was the wrong thing to build, or it was built in the wrong way. There are problems that can be solved without error by one person who thinks about them for a little while and types in the code that solves the problem.  The term for this kind of problem is  uninteresting problems.  These problems are smaller than one brain, or else the solution is already well-known. We tend to either shuffle this problems off on the noobies, or else we scribble down the answer and move on without any real sense of accomplishment. Any problem that is interesting will involve experimentation and learning. Those problems cy...

Linda takes us from a negative to a positive affective style, from a posture of seeming or being to one of becoming.  There is just so much to know and understand here. If you don't already love Linda Rising, you surely will after this. Notice the tie-in to Seeming v. Being v. Becoming . Mine is derivative, of course.

A nice discussion about things that should not be done in Python code, but frequently are. Nice mention of Clean Code's naming rules (I'm a proud daddy).

I saw this in a python tutorial today: if os.path.exists("/tmp/uPlayer"): f = open("/tmp/uPlayer/STATUS", "w") f.write("IDLE") f.close else: os.mkdir("/tmp/uPlayer") f = open("/tmp/uPlayer/STATUS", "w") f.write("IDLE") f.close Really, now? We start by duplicating the whole open/write thing in order to create a directory? Maybe one of the problems people have with clean coding is that their examples are poor. If you write, it behooves you to write refrigerator code. Not to mention that close is a function, so it needs parentheses. This code doesn't even do what it thinks it is doing. It's closing the file when f goes out of scope, not when we reference the f.close bound method. It makes me sad for the children.

A friend of mine (Hi George D) suggested that this would make a good poster, but all I have is a couple of blogs, so here is the message that inspired my buddy. My experience is that the less well a team has done in the past, the more oversight is piled on, and that oversight reaches higher and higher levels. There really is no legitimate reason for the CEO to want to know which programmer 5 or more levels below was assigned to a particular task and if he's behind schedule by a week or so. In healthier organizations, the groups and managers that interface with the development group tend not to have the same meddlesome urges. In our transitions, the biggest problem we face tends to be peeling back the expensive and unnecessary oversight. If the team can be rebooted and work with a single stream of smaller, simpler stories (rest of agile practices included) then they can win over the rest of the org in relatively short order. Sometimes in only a year or two, som...