Agile Otter Blog

I had a friend once tell me that he didn't understand what it meant to program computers. He was not really a computer user, and was just getting ready to try email at the time. He wasn't a gamer, and frankly the whole computer thing seemed too weird to him. After all, it's a machine, right? How do you program a machine? Is it like choosing a darkness setting on the toaster? Typing data into quickbooks? What? That was many years ago, but it still sticks with me. Some people (most in fact) really don't know what I do. If I tell them, they don't know any more than before. When most people hear "programmer" they think "IT", in which case I must be the guy who fixes network outages, distributes patches, and helps people when their machine crashes (admittedly, a weak view of what IT is about). But no, I'm not that guy. I love those guys, but I'm not one of them. A cousin of mine took an introductory course on programming, probably in Visu...

I've been quite busy of late, partly with holiday season, partly with medical matters (wife's ankle surgery), partly with church, partly with Agile In A Flash, and partly with the series of articles Jeff and I are writing for PragProg. Last month's PragProg article brought some good feedback and kind words from some of you and we're thankful. We have two more "big topic" articles to go (abstraction and volatility) and then we're back to the stories behind the AgileInAFlash cards (on pre-order via online outlets and expected in January). Please keep up with us there as well as here and at Agile In A Flash . I'm looking at some new projects next year, hopefully some that pay and some that allow me to improve my chops on open source development. I don't foresee another book just yet, but some writing is definitely in the works. The only other news is that I dived into Ruby for a little while, and will be chasing that down via the three books I ...

Today I was thinking about the phrase "under test" as in "we've got to get this code under test so we can fix it." I started of thinking about the way the app we were discussing was laid out. There was (at rock bottom) some persistence stuff. Above that was (on one side) reporting and query, and on the other was some business objects. Above the business objects are some model-like objects (sometimes) and above those are UI-related code. Starting at the "top", with UI presentation, we can test through a browser. That makes it the territory of human by-hand testing and also of browser emulators, browser drivers, and screen-scrapers. Such tests are going to exercise a fully-integrated system, and can be slow due to many features such as database access, file system access, network access to services, etc. Human testing is particularly slow, as it involves reading time, typing time, and time to evaluate results. Human tests we can measure in minu...

We tackled some code for refactoring, and I found an unusual construct. To wit: public class Base: Many, Varied, Bases { private int x; // ... public class Derived: Base { public setX(int value) { x = value; } } // ... } So here we have the derived class nested in its base class. I am quite comfortable with nested anythings in python or a few other languages, so that's not a problem. I nest 'testable' classes in tests all the time so I can override or stub a few methods. In python it's a normal way of life to nest functions and classes. This one is odd because it is a production class, nested inside a production class, and deriving from its outer class. It makes me think of a pregnant female, having a child inside it whose dna derives from the mother. So what powers does this odd nesting convey? My first thought is that it is some kind of closure, but this turns out to be false. There is no real closure ...

I recently collected up some information from Jira and git about our software process. I am mulling over an idea, and a little feedback is welcome. To help understand the context, among our products we have one codebase that was originally written pre-agile in a non-TDDed manner but greatly improved during and after the company's agile transition. It is pretty good stuff, and constantly improving in quality and functionality, consistently delivering real value to customers. We're pretty of proud of it and its future. There is a great team working on it. Sometimes, though, we find the need for a large-scale refactoring somewhere in the code base, and we have the courage to tackle these. Basically the problem is that refactoring sounds bad to product managers. When it's done well, there is no visible difference in the code. When it isn't done perfectly, it injects defects. The obvious knee-jerk reaction is to resist any large-scale refactoring efforts. As an a...

I had some fun recently after agonizing over the problem of bug prevention.  I put out the observation that bugs have a tendency to cluster, and that the more often code is edited the greater the need for the code to be frightfully virtuous , clean , and thoroughly tested . The problem was with determining which code should be cleaned up in order to reduce the injection of bugs. I considered various metrics and measurements, including cyclomatic complexity, code duplication, and various design details, but ultimately dismissed them for fear that they would be unconvincing. I didn't want my audience to think the heat maps is just "coach Tim lecturing."  In keeping with our description of effective information radiators we needed the information to be simple and stark. Our SCM is based on git, and our tracking software is Jira. We have to include a recognizable, open, Jira ticket id in every code commit. Many of the tickets are enhancements, improvements, or investig...

I write an automated acceptance test (AT) and I find that I would like to perform certain actions against the business objects.  I create a method on the business objects and my test stays slim while my model builds up more functions. So, there is potentially code in the production system that is only used in the tests. The debate today is whether that is "unnecessary bulk that solves no business need" or is instead "first-class code." I am betting that the code you need in the AT is code you probably also needed in the UI and/or APIs to external clients. I am supposing that it is needed in the test because it is likely written into the UIs instead of the model and so the tests' logic is duplication. I also think that even a reasonably poorly-written test is written to support business rules.  Therefore, the tests express business logic so methods required by the tests are methods required by business.  While some worry that a method on a busin...