Agile Otter Blog

I know that companies have the best intentions. They want to provide opportunity for their employees in hopes of retaining them and encouraging desirable behaviors. They want to reward those who perform well and eliminate the dead wood. Even so, it is 2010 and career pathing is done, like annual reviews is done, like the 80s are done. This is doubly true for agile organizations where the dynamics are so very different. The old idea was that an employee would join a career path, and that path would lead them to some management or technical position that would provide them with respect from peers and superiors, autonomy (perhaps their own team to lead), and increased compensation. Employees could see if they were tracking or not, and this would provide incentive to excel by doing the things the employer most highly values. This is not a bad idea and it used to make a lot of sense. Now career-pathing is an answer to a question that nobody is asking. Formal roles and titles have never me...

So Scott and I are pair-programming, when we realize that there is code in our test setup that ought to be in the model. We look and find that it's not, but it is duplicated in a number of other test setup routines. Oh, no. Time to take a code improvement excursion. We know that it's bad form for test routines to contain code that duplicates the system, and this looks like a low-fidelity reproduction. So we find the class that OUGHT to contain it, and transfer the method. Now we go on a quick excursion through the code base and find the code that actually does the work in the middle of a fat method in a UI code-behind. Deep sigh. We change the production code so it is using the model, including our new code, correctly. Pop the stack, continue. Then we find (via resharper) the same code duplicated in a dozen or so other places in production code. Take a deep breath, push the stack again. We move through the code base simplifying a bunch of methods by replacing the duplicat...

Via AgileVoices, I found a a survey that asks all the wrong questions. On the first page, it asked me for my role in the agile team. I selected "other" and typed "member", since the other options segregated roles is a pre-agile way. The next page was all about whether my agile project was a success. Of course success is defined as being free from requirements changes, on budget, and on schedule. I didn't go any further. If we try to measure our agile projects by waterfall standards, I think we'll find them all to be pretty poor waterfall projects by the same sense that my son's dog is a very poor water dragon and his water dragon is a pretty lousy dog. The whole point of agile is not to commit to a set of unchanging requirements up front, but to deliver a useful product at the end. The point is that we all work together according to our strengths and the need of the hour, not that we segregate by roles and tasks. I'm simply disgusted. This is 20...

I once posted a blog about the meaning of the word "Simple" as used in "The Simplest Thing That Might Possibly Work", an activity that generated a little buzz and first steps toward resolution. The problem I realized is that "simple" gets mixed up with "easy", "primitive", and "clear" in ways most unfortunate. This was true of myself as well as others in the conversation. As I search the web for words like simple and complex, clear or confusing, perhaps easy and hard, I realize that we're all splitting hairs in different ways. I suggest that we consider some more crisp boundaries when discussing qualities of code. Here are the axes I suggest: Simple v. Complex: relating to number of parts and steps involved Clear v. Puzzling: relating to ease of comprehension Easy v. Difficult: relating to ease of implementation Developed v. Primitive: relating to degree of investment in types In this terminological divide, sim...

Many programmers see their jobs as a process of gluing together code fragments to make things work. Many of them produce results very quickly and are lauded for productivity. TDD, mocking libraries, dependency injection, and refactoring tools seem to them a silly waste of time; they can hack working examples together faster than most "craftsman" programmers. There is some validity to the approach. Quite often programmers find code samples on the web or in a very fine "python cookbook" or the like, and they copy them into their code base. Likewise, an API comes with example code for a reason. There is nothing wrong with starting from a good external example, as this will often jump-start your application's use of an api or technique. If plagiarism is avoided (ie samples are public domain or appropriately licensed) then this kind of copy-and-paste may be valid and useful. The problem comes when copying and pasting withing an application. In this context, it i...