As I’ve advised a few teams this year who are making the switch to agile, I’ve found myself advocating more and more heavily for Kanban or “continuous flow” styles. I thought I’d take some time and write down what I think are the reasons I’m moving in that direction. Of course, Kanban is a frequent topic on DZone. I won’t waste your time by describing it, but hopefully I can find a fresh insight or two, or at least say something stupid enough to make people want to comment.

I’ve found myself advocating for Kanban methodologies as I’ve advised agile teams, and I’m working through my reasoning in the hopes of understanding it better myself. In the first article I talked about program oversight, in the second I talked about team dynamics, and in the third I talked about principals and agents. This time I want to talk about presenting status to management. I recognize I just lost half of what audience I hadn’t already chased away, but I just could not come up with a way to make that sound more interesting.

Since I’ve found myself advocating for Kanban more often as I’ve advised teams on agile, I decided to write down some of my reasoning. I started by discussing how sprints can become counter-productive in the context of program oversight. This time I want to talk about the dynamics within an agile team, and how some kinds of teams thrive on the flexibility that comes from a lean agile approach. Hopefully everyone has had the experience of working on a really good team.

I’ve found myself advocating for Kanban methodologies as I’ve advised agile teams, and I’m working through my reasoning in the hopes of understanding it better myself. In the first article I talked about program oversight, and in the second I talked about team dynamics. This time I’m admitting to the fact that I went to business school as I talk about the principal agent problem. At the University of Minnesota Carlson School of Management (Ski U Mah), I had a professor who wrote a book on franchising.

I spent a recent week working with a program that is starting up some work using an agile methodology, but has a mixed team, both in terms of time on the program and time with agile. So it was an interesting week, because I picked up a bunch of new ideas from people with experiences different from mine. It also means I’ve done a lot of thinking about agile, which hopefully will result in a few interesting thoughts to write down.

I recently resurrected an older but relatively small laptop to use in cattle class on an airplane, where a full size laptop is eternally in danger of being crushed by the seat in front. Unfortunately, the laptop was running Windows Vista, a curse inflicted on many laptops of its era, when Microsoft went through one of its phases of pretending that people seek deeper meaning from an operating system as opposed to just hoping it will keep running and not break their applications.

Reducing Unhappiness Imagine yourself in the role of a city planner. Your job is to find a place for some new undesirable thing, like an electrical substation (potential eyesore) or a treatment plant (potential nosesore, if that were a word). You want to choose a site that will irritate the smallest number of people, because irritated people tend to show up at city council meetings, and that makes the people you work for irritated with you.

I was thinking over the weekend about how to present certain aspects of agile to non-technical people. One aspect of agile that is particularly difficult to get across is the idea of accepting change. It feels wrong, at least in an industry like the defense industry, with carefully negotiated contracts and a history of cost overrun, to say that agile prefers accepting change over following a plan. At the same time, I firmly believe that agile, much of the time, reflects the way we really do engineering when we do it right.

Henrik Warne’s list of programming quotes was recently published on DZone. One great quote was from Fred Brooks, longtime head of Computer Science at the University of North Carolina, just around the corner from DZone itself. The quote was: “Much of the essence of building a program is in fact the debugging of the specification.” “Essence” is a word we use every day to mean “the heart” or “the center” of something, but as he explains in “No Silver Bullet”, the essay from which this quote comes, Brooks himself uses that term in the same way that Aristotle used it.

Zone: Java Recently I needed to put together some code to perform autowiring of dependencies using Java annotations. The annotation had an optional parameter specifying a name; if the name was missing, the dependency would be wired by type matching. So of course the core logic ended up looking like: private void wireDependency(Field field, Class<?> annotation, Object o) { if (!wireByName(field, annotation, o)) { wireByType(field, annotation, o); } } This falls under the category of “as simple as possible, but no simpler”.

I’ve been doing some work on team organization lately, and it’s caused me to return to an idea I had about “defining” “process”. Working in the defense industry, of course I’ve seen a lot of plans and procedures for writing software. One of my favorite things to do is to spot what I call the “magic happens here” step. It’s a fun game to play. Take a design process like this one.

My fellow Zone Leader Sam Atkinson wrote an excellent article on Beautiful Constructors. While I definitely agree that the constructors in his article are beautiful, I wasn’t as sure that his prescriptions could be universally applied. He graciously allowed me to use his piece as a springboard for a counterpoint, in the hope of some good discussion. Of course, the opinions in this article are my own. Collaborators The style of design Sam describes seems to me to work best for a collaborator class.

Like jelly in the PB&J, or Art in Simon and Garfunkel, the reducer gets second billing in the term MapReduce. But it really is the more mathematicaly interesting function of the two, as I hope to demonstrate. The secret to big data is of course the ability to do work in parallel. Modern Big Data engines like Hadoop don’t rely on the invention of clever new algorithms or artificial intelligence to produce impressive results; instead, they are based on the idea of taking lots of input, working on little pieces of it in lots of places at the same time, then bringing together the results.

Moving from a sequential to a parallel implementation of an algorithm usually means that something has to change, and it may mean that the whole algorithm has to be rethought. There are some important concepts that help us predict what kinds of changes will make an algorithm perform well when run in parallel. This article is a brief introduction. Simple Performance In the sequential case, we typically talk about algorithms in terms of the order of the algorithm (typically called Big O).

One of the things I emphasize when I teach Java classes is the fact that annotations are inert. In other words, they are just markers, potentially with some properties, but with no behavior of their own. So whenever you see an annotation on a piece of Java code, it means that there must be some other Java code somewhere that looks for that annotation and contains the real intelligence to do something useful with it.