Friday, September 14, 2012

There is good news on this front. Apparently the copyright has been settled, and we have new copies printed last year by Solis press. You may still be able to buy a copy from Amazon!

Now on with the original post....

In 1926, Graham Wallas published a book which has been cited in organizational theory texts all over the world (as well as papers on the Philosophy of Art). It presaged cognitive psychology and built a model of creative thought that has helped millions of people recognize and appreciate their own ability to think creatively -- and teach it to others.

I don't have a copy of The Art of Thought. I know it by reputation and reference only. It seems like every once in a while I stumble across yet another reference to the Wallas Model of Creativity, and still I don't have a copy, and have never read a copy of the original work.

Most people who say "simple" don't mean simple. They mean "easy", with an implied "to think of" or "to type in" or "to do without researching." Easy is a virtue, but it's not the same virtue as "simple."

Most people who say "complex" don't mean complex. They mean "not easy to read." A very simple piece of code may be hard to read or hard to understand. Clarity is a virtue, but it's not simplicity.

I would love to start a worldwide movement to make these words more specific in daily usage. Please consider the code virtues as a starting point. Here's what we say there:

We like to think of simplicity as a measurable attribute, consisting of the number of unique names and operators in a given code component (class, method, function, subprogram, etc.). Some people have suggested that we call this virtue “structural simplicity.” That works for us.

Simple, then, doesn't mean easy or easy to read. It means uncomplicated. It has the minimal number of concerns, terms, and operations. It could be inobvious and hard as hell to read, and still be simple.

A design could be complex (have several intertwined concerns) and yet deemed easy to understand by its developers, who are familiar with all the intertwined concerns. Complexity is a measure of how many parts and concerns have been woven ("complected") together. It's not a measure of the programmer's understanding.

Likewise, a design might be easy to conceive or easy to implement, and not be simple by any measure. It might be another layer of cruft on the accumulated cruft of decades of maintenance coding. Simplicity is a measure of the state of the code, not the effort of the developer.

Now, I know that popular use is muddled. Simple means "readable" or "easy to write" to various people, but I think if we help tidy up our use of the word, we can actually have measures of simplicity and complexity that can help us produce quantifiably better code.

Readability ("clear" v. "confusing") is subjective, but it might be a combination of real simplicity and good naming -- it might be decomposable to more measurable and objective concerns. Wouldn't that be great?

A little rigor here, at least in our use of words, might lead us to something really great.

Friday, September 7, 2012

(note: I added a 15th, but was worried that changing the title would invalidate links, so you get a bonus observation at no extra cost)

I frequently have to address questions about velocity, so in the interest of time I present all the answers here in a short post:

Velocity is a gauge, not a control knob. You can't just turn up the velocity -- you can only break the gauge by trying.

Velocity is (frustratingly) a lagging indicator. It primarily tells you about the fundamental process and technical work you did weeks, months, or years ago. You seldom get an immediate, true improvement.

Though velocity is a gauge, it is subject to Goodhart's Law. It is rather dodgy when used as a basis for governance.

Velocity value is highly derivative of many factors, chief among them being the work structure of the organization. The more governance and procedure (permission steps, queuing and wait states, official limitations, risk of personal blame, reporting and recording, stockpiling of tasks for the sprint-end) the lower the velocity.

The amount of effort expended by the development team has a nearly trivial effect on velocity. A team can game it by working overtime, but that usually causes more problems than it solves. "Trying harder" doesn't scale and doesn't last.

Velocity is like a helium balloon: it goes up because it isn't held down, and it only goes down when forced. This is partly because people like to complete tasks and build on achievements. Nobody willingly reduces their level of accomplishment (though any sane person will stop "trying harder" week after week).

Perhaps surprisingly, the more team members "do their own work" and multitask, the lower the velocity tends to go.

Also perhaps surprisingly, most teams can complete four two-point stories faster than they can complete a single eight-point story, so the "area of the rectangle" (points x people) is not the same.

Although people often short quality to get things done sooner in the short term, velocity in all sprints is reduced if the quality of the code the team encounters is low. The code they encounter today is mostly the code they've written until now. Next months' could be better or worse depending on how they work today.

Skill and information have effect on the velocity of a team. As they learn and collaborate, the velocity comes up a bit -- but probably not nearly as much as movement toward an orderly and non-turbulent work flow.

When a team improves, either the velocity will go up and story points will remain roughly the same or the velocity will largely be the same and the points assigned to a story will reduce. However, quite often both will happen to some degree. This is one of the reasons you can't compare velocities across teams (there are may more reasons).

A poor PO can damage velocity, but a good one cannot improve it (other than to stop damaging it). The PO can improve value, but not velocity, because her job is establishing content and priority.

If you only count finished, planned work in your velocity then you can use last sprint's velocity to choose how much planned work you can do in the next sprint. Otherwise, it's largely useless.

One additional use is that "sine-waving" velocity is an indicator of "hangover" -- the practice of carrying stories to the next sprint and claiming full value for them in the latter sprint.

The biggest problems with velocity come from not understanding it, and treating it as a general indicator of productivity or busyness. The secret is to not take it too seriously, and improve your work system and organization instead of improving your velocity.

That's rather an unfocused ramble through the world of velocity, but perhaps you will find it useful.

Wednesday, September 5, 2012

Worst Case:

Just for a moment, imagine that you are the worst player on your team, but nobody tells you because they don't want you to feel bad. All the other programmers are fixing up your code so it works, your design sense is flawed, and everyone knows it but you.

Then you find out.

Of course, you'll have a sinking feeling and probably get mad. Let's say for a moment that quitting is not an option. The question is "what are you going to do about it?"

For some people the initial response would be shame and anger and abuse of one comforting substance or another (likely liquor, but possibly pizza, cookie dough, or a tub full of Mr. Bubble). At some point you will realize that you have to go back into the office.

Everyone there already knows. It is likely that they have heard that you found out. Now what? You could get discouraged but that's hardly helpful. There is only one thing to do: you have to get better.

What is the plan? How will you pick up on new skills and design sense? You could isolate and read, but that's not going to work during business hours. You can read more code, but you do need to produce something and you need the practice.

Likely Case

Then you find out that there are programmers in the world who could do what you do better, faster, easier. What is the plan?

I suspect you would do the same things to improve, only this time without shame and humiliation. You would do some research, try things differently, read something, get a second opinion, find a mentor.

Your Case

Guess what? You're probably a pretty good performer.

Still, there are guys out there who can do what you do a little better, faster, or easier.

Tuesday, September 4, 2012

I have an activity I like to use in training sessions to get to know the people who will be sharing my week. It's fairly obvious that this is useful in a classroom, but it might not be so obvious that this kind of exercise is valuable with people who have already gelled as a team.

Here is how it goes:

Everyone stands in a circle.

The leader (usually me) begins with his name and the answer to a question. Usually the first time I do this, I want to know why people have come to the training. The typical formulation is something like "I am Tim and the reason I came here today is because I was invited to talk about Object-Oriented design, a topic very near to my heart which I've taught and written about since the early 1990s."

The person on the leader's left does likewise, and so on through the circle. Each states their name and gives the answer to the question in a complete sentence (as the leader did).

This has a few advantages:

Everyone says their name. It is useful to hear people speak their own names when you don't know them as well as you'd like. It is doubly helpful if you don't know them at all. Sometimes there are little phonetic surprises, even with people you know (rolling Rs or hard consonants you've been mispronouncing for years). In addition, speaking their own name brings them into the circle as a person.

Everyone stands. Standing helps you manage time and also allegedly gives your brain 15% improvement in circulation. Ideally, this keeps the answers poignant and personal and (thankfully) short. A long answer is harder to remember, and harder to relate to. We don't like for people to leave the circle remembering only that "Fred is a long-winded guy."

Everyone has an equal chance to speak. Too often conversations about technical topics can be dominated by individuals who are outgoing and have strong opinions. Quieter, more introverted people are no less competent and and their opinions no less interesting. Sometimes we're surprised to actually meet the people around us.

Everyone receives the attention of the circle of individuals for just a second. However uncomfortable that might seem, it is actually a powerful moment in which an individual instructs us on how they would like us to think of them.

Now everyone knows something about someone else, and this information can be used to start a conversation or better understand a point of view.

Please consider the same simple exercise with an existing team, and drop me a comment to let me know what question you asked, what the answer taught you, and how the technique affects your team.