If you were mentoring someone who is pretty new in java, you would surely tell them about JUnit and your favorite mocking framework and the language grammar. However, you know that Java is a culture and a history and a spoken language as much as a written language. You would start talking about jakarta, or tomcat, or a DI, or a bean, or a war file, or eclipse workspaces and your apprentice would scratch his head and stammer. The truth of the matter is that the grammar isn't but 10% of what java programmers know.
Which projects would you have your student study in order to soak up the rich history, culture, and language of the java programmer? What are Java's greatest hits and misses?
Tim Ottinger's thoughts on Software Development.
Thursday, April 21, 2011
Friday, April 8, 2011
"Managing" Velocity
The term velocity is very well-chosen. It means speed in a certain direction, with the intention that it refers to the teams rate of travel toward a product release. I have suggested that velocity is just capacity and my intention was good and maybe even right in many ways. Velocity is the practical measure of our capacity being applied toward the completion of a release. The term still stands superior to my older suggestion.
Lets start with the definition that velocity is the speed of progress in a given direction.
The direction part gets missed. People (including my slightly younger self) want to do things like track bugs ("failure demand") as velocity. It might be good to see how much capacity is being lost to failure demand, but it is not velocity toward the same goal, not really. We don't want to know that the team is busy, we want to see when the project will be done. So we do not count bugs toward velocity. We want to see quality problems drive velocity down; that's what velocity measurement is for. If bugs are driving velocity down, wrap a bunch of tests around your most volatile or hottest code and clean it up. Watch what happens to velocity after an iteration or two.
Some think that when I don't offer partial credit or bug points or meeting points it is because I don't care about velocity, but it is actually because I care too much about it to pollute it. Done well, velocity is the speed toward a goal.
The fact that we use words like "velocity" and "sprint" makes it sound like we are in a race. Indeed, one can see the goal as one of releasing as quickly as possible, and we can all applaud that goal. What, then, is the ideal velocity of a team? Infinity? Isn't faster always better? It feels wrong to have a velocity "dip" and teams will go to great lengths (often the wrong ones) to shore up their numbers.
Instead of seeking the maximum velocity, perhaps teams should seek the optimum velocity. What is the best speed today for working in the code we have, with the team we have, in the context we have? What is the best, instead of the highest possible speed?
What can we change/improve/descale so that a greater speed becomes optimal?
Too often a team will turn to chronic overtime to fix their velocity problem. This is a huge mistake. Velocity is the amount of capacity spent in the direction of completing a release, and attempting to inflate capacity does not solve the problem (see Goodhart's Law). In fact, overtime just leads to bigger, more unpredictable problems. Agile methods are supposed to uncover problems, so it may be best for a team to become transparent so that velocity measures actually become useful.
Likewise, adding people may be the wrong answer.We might want to consider the optimal size of our team, instead of the maximum possible size. If we find that our small team membership is the very issue that is constraining our best optimal speed, we may want to add more people in a measured way. Even then, we should consider the optimal way to add people, not the fastest possible awful way.
Generally, the best way to increase the capacity of a team to do work is to eliminate wasteful practices, wait states, and overburden. It may involve downsizing, upsizing, or leaving the team alone. It might require adding practices or removing them.
We can increase our ability to do work by making the code more workable and the team more skillful. The work might get easier and more pleasant over time instead of being a never-ending "trudge in the sludge."
This leaves us with velocity as the rate of progress at a sustainable pace toward a goal.
But it might lead to trending; is our velocity accelerating or decelerating? Are we doing less work with more people more haphazardly? Are we actually moving toward faster, easier, better releases that satisfy our customers?
Even so, velocity will fluctuate. You don't have the same capacity to expend every week. Maybe you're tired from overtime, or life at home is requiring more attention. Maybe it is because estimates are imprecise or because each iteration has troubles of its own. Maybe exciting new features need to be vetted by the team. Maybe a member gets pulled out for sales support. There could be an illness or a birth. Don't bother trying to force velocity. It will stabilize well enough if you don't mistreat it. Then you can separate normal variation from special variation and can monitor the trends over time
Since velocity has some normal variation, wise managers know to plan with a little slack. If you run your team at 100% capacity, there is no reserve to help with technical or requirement issues, no way to allow a programmer to participate in the proposal process or vet sales' ideas for new features. One dental appointment or a sudden bout of the stomach flu would ruin your plans for success. Too much good content is written for me to try to do this topic justice, so I'll spare you.
Velocity should be a measure of actual, non-waste progress toward a goal at a sustainable pace. For planning, velocity has a prudent amount of slack figured in, based on the team's history of normal variation.
This long ramble contains opinions and some link-mongering, whereas I only promised to write up a quick summary of my thoughts. I've done my part. According to the deal on Twitter, it's your turn to start beating on it so we both may learn something from the exchange.
Cheers.
Lets start with the definition that velocity is the speed of progress in a given direction.
The direction part gets missed. People (including my slightly younger self) want to do things like track bugs ("failure demand") as velocity. It might be good to see how much capacity is being lost to failure demand, but it is not velocity toward the same goal, not really. We don't want to know that the team is busy, we want to see when the project will be done. So we do not count bugs toward velocity. We want to see quality problems drive velocity down; that's what velocity measurement is for. If bugs are driving velocity down, wrap a bunch of tests around your most volatile or hottest code and clean it up. Watch what happens to velocity after an iteration or two.
Some think that when I don't offer partial credit or bug points or meeting points it is because I don't care about velocity, but it is actually because I care too much about it to pollute it. Done well, velocity is the speed toward a goal.
Optimals v. Maximals
The fact that we use words like "velocity" and "sprint" makes it sound like we are in a race. Indeed, one can see the goal as one of releasing as quickly as possible, and we can all applaud that goal. What, then, is the ideal velocity of a team? Infinity? Isn't faster always better? It feels wrong to have a velocity "dip" and teams will go to great lengths (often the wrong ones) to shore up their numbers.
Instead of seeking the maximum velocity, perhaps teams should seek the optimum velocity. What is the best speed today for working in the code we have, with the team we have, in the context we have? What is the best, instead of the highest possible speed?
What can we change/improve/descale so that a greater speed becomes optimal?
Too often a team will turn to chronic overtime to fix their velocity problem. This is a huge mistake. Velocity is the amount of capacity spent in the direction of completing a release, and attempting to inflate capacity does not solve the problem (see Goodhart's Law). In fact, overtime just leads to bigger, more unpredictable problems. Agile methods are supposed to uncover problems, so it may be best for a team to become transparent so that velocity measures actually become useful.
Likewise, adding people may be the wrong answer.We might want to consider the optimal size of our team, instead of the maximum possible size. If we find that our small team membership is the very issue that is constraining our best optimal speed, we may want to add more people in a measured way. Even then, we should consider the optimal way to add people, not the fastest possible awful way.
Generally, the best way to increase the capacity of a team to do work is to eliminate wasteful practices, wait states, and overburden. It may involve downsizing, upsizing, or leaving the team alone. It might require adding practices or removing them.
We can increase our ability to do work by making the code more workable and the team more skillful. The work might get easier and more pleasant over time instead of being a never-ending "trudge in the sludge."
This leaves us with velocity as the rate of progress at a sustainable pace toward a goal.
But it might lead to trending; is our velocity accelerating or decelerating? Are we doing less work with more people more haphazardly? Are we actually moving toward faster, easier, better releases that satisfy our customers?
Normal Variation
Even so, velocity will fluctuate. You don't have the same capacity to expend every week. Maybe you're tired from overtime, or life at home is requiring more attention. Maybe it is because estimates are imprecise or because each iteration has troubles of its own. Maybe exciting new features need to be vetted by the team. Maybe a member gets pulled out for sales support. There could be an illness or a birth. Don't bother trying to force velocity. It will stabilize well enough if you don't mistreat it. Then you can separate normal variation from special variation and can monitor the trends over time
Since velocity has some normal variation, wise managers know to plan with a little slack. If you run your team at 100% capacity, there is no reserve to help with technical or requirement issues, no way to allow a programmer to participate in the proposal process or vet sales' ideas for new features. One dental appointment or a sudden bout of the stomach flu would ruin your plans for success. Too much good content is written for me to try to do this topic justice, so I'll spare you.
Velocity should be a measure of actual, non-waste progress toward a goal at a sustainable pace. For planning, velocity has a prudent amount of slack figured in, based on the team's history of normal variation.
Wrapping Up
It's my belief that it would be better to not track velocity at all rather than fall prey to the typical pitfalls of velocity goals and velocity abuse. After all, velocity is a surrogate goal and doesn't consider the value and usefulness of the work that is created.
It would be better to have a low velocity and produce two useful features than to have a very high velocity and produce nothing but noise, cruft, and trouble for the users... but that is a different blog post.
It would be better to have a low velocity and produce two useful features than to have a very high velocity and produce nothing but noise, cruft, and trouble for the users... but that is a different blog post.
Cheers.
Monday, April 4, 2011
Overtime on Agile Teams?
My recent article on Overtime and Agile Teams was accepted and published in Software Quality Connection. Here are a few statements extracted from the article to summarize its direction:
- "Predicating project plans on constant overtime is a bad idea."
- "Agile requires whole people."
- "Overtime is for bumps."
- "You have to ask if your overtime is hiding problems instead of exposing them so that the team can solve them."
My OSS Software (inventory)
What I need to replace when I get the new machine:
Chrome, Firefox, Midori: Browsers - usually two or more open at one time.
gvim, git, svn, poor ole' cvs: Essentials for software dev, b/c I often have three or four bash sessions open.
Miro, Gpodder: audio and video subscribe/play - free video, audio, kept consistent.
FBReader, Calibre: ebook & magazine readers -- I need to move my ebook collection, too.
OpenShot, Arista transcoder, mencoder, Istanbul: video editing, transcoding, and screen capture
Inkscape, Gimp, F-Spot: svg drawing, image editing, image manager
OpenOffice: free office suite w/ word processor, drawing, spreadsheet, presentation
FreeMind: mind mapping
Skype, TeamViewer: remote pairing
Rhythmbox: music player and access to UbuntuOne DRM-free music store.
Eclipse: rare instances when I need to use an IDE (I don't do much Java).
Most of the stuff I do is with these. I am surprised that it's such a short list, but programming is mostly in gvim, using python (pip, etc) or a little ruby, and some fun stuff in bash. Not as many apps as I thought. An awful lot of what I do is "in the cloud" rather than local these days, and hopefully more if it will move that way.
Chrome, Firefox, Midori: Browsers - usually two or more open at one time.
gvim, git, svn, poor ole' cvs: Essentials for software dev, b/c I often have three or four bash sessions open.
Miro, Gpodder: audio and video subscribe/play - free video, audio, kept consistent.
FBReader, Calibre: ebook & magazine readers -- I need to move my ebook collection, too.
OpenShot, Arista transcoder, mencoder, Istanbul: video editing, transcoding, and screen capture
Inkscape, Gimp, F-Spot: svg drawing, image editing, image manager
OpenOffice: free office suite w/ word processor, drawing, spreadsheet, presentation
FreeMind: mind mapping
Skype, TeamViewer: remote pairing
Rhythmbox: music player and access to UbuntuOne DRM-free music store.
Eclipse: rare instances when I need to use an IDE (I don't do much Java).
Most of the stuff I do is with these. I am surprised that it's such a short list, but programming is mostly in gvim, using python (pip, etc) or a little ruby, and some fun stuff in bash. Not as many apps as I thought. An awful lot of what I do is "in the cloud" rather than local these days, and hopefully more if it will move that way.
Friday, April 1, 2011
Sell Me A Computer?
I do everything as a geek would do it, because I am a geek. This extends to buying a computer. I'm picking out my next home-wherever-I-am now, and I'm wanting to ask questions that nobody answers. Here's what I'm about:
I know that's not the normal set of questions, but that's why I'm so much fun to shop with.
I've had great luck with Thinkpads and my Asus EEE PC is just wonderful with Ubuntu. I don't have the battery life I want, but a guy makes compromises. We're pragmatists.
My only problems with the Asus EEE PC have been the oversensitive touchpad, lower battery life than desired (2 hours + with Ubuntu), smallish hard drive (160G), small RAM (1G originally), and being vga-only (later models solve this). For the money, I can heartily endorse these little netbooks. Actually, despite these problems, I've come to love the little beast. It's just underpowered for my needs now.
I'm thinking about a Thinkpad T410s, loaded with RAM, 500GB drive, and 9-cell battery. I'm betting it will come as close as anything to what I want.
I'm still considering a Mac, though. I don't like OS X as much as Ubuntu, but if it is solid and my windows VM runs okay, I bet I can comfort myself with a real *nix file system and a good bash shell. Last time I was frustrated by not having a great APT/YUM repositories (ports was not as good) and the whole issue of native app updates. Either each app checks for itself, or you have to go check for them and download new versions. On OS X, I had to do a lot more manual system management, and Windows was worse than that in addition to being slower and buggier.
On the other hand, OS/X had some great power management and ergonomics and the MBP had some really stellar hardware. It did work well, only crashing maybe twice in the year I had it (far better than windows, not as good as Ubuntu). The only thing I would consider superior about windows is its power management. My son's Asus EEE is identical to mine, but windows stretches the power use over a much greater period.
Well, unless someone talks me out of it, it will either be a MBP or a Thinkpad when I place my order. It will be either Ubuntu or OS/X and windows in a VM.
- Does it come with a non-shiny screen? I don't know how "glare" ever became a feature.
- If I'm just reading and editing text files, will the battery last all through a 6-hour flight?
- How much battery life can I get if I'm programming in python with autonose running?
- When I put Ubuntu on it, will it find drivers for everything? Video? Wifi? Camera?
- Which extended function keys won't work in Linux?
- Will the oversensitive touchpad register a mouse activity when I come within 1/2 inch of it? Can I shut it off?
- How badly will I get burned if I put the laptop on my knees while compiling a .NET project?
- Is there enough RAM for me to run my OS, a windows virtual box with VS.NET and resharper in it, a browser on the side?
- Can I use it comfortably on a train or on an airplane, even if the inconsiderate jerk in front of me slams his seat back against my knees like usual?
- How long is the fan going to last? Is it going to die after a measly 4 years like my previous two full-sized laptop computers?
- How much does it suck battery when suspended? How much does it eat on reboot if hibernated?
- Can I hook it up to digital video? HDMI?
- How water-resistant is it? If I spill one drop into the keyboard, is it gone forever, or is there some hope?
- How sturdy is the hinge? I've seen too many laptops gone forever when the hinge weakens.
I know that's not the normal set of questions, but that's why I'm so much fun to shop with.
I've had great luck with Thinkpads and my Asus EEE PC is just wonderful with Ubuntu. I don't have the battery life I want, but a guy makes compromises. We're pragmatists.
My only problems with the Asus EEE PC have been the oversensitive touchpad, lower battery life than desired (2 hours + with Ubuntu), smallish hard drive (160G), small RAM (1G originally), and being vga-only (later models solve this). For the money, I can heartily endorse these little netbooks. Actually, despite these problems, I've come to love the little beast. It's just underpowered for my needs now.
I'm thinking about a Thinkpad T410s, loaded with RAM, 500GB drive, and 9-cell battery. I'm betting it will come as close as anything to what I want.
I'm still considering a Mac, though. I don't like OS X as much as Ubuntu, but if it is solid and my windows VM runs okay, I bet I can comfort myself with a real *nix file system and a good bash shell. Last time I was frustrated by not having a great APT/YUM repositories (ports was not as good) and the whole issue of native app updates. Either each app checks for itself, or you have to go check for them and download new versions. On OS X, I had to do a lot more manual system management, and Windows was worse than that in addition to being slower and buggier.
On the other hand, OS/X had some great power management and ergonomics and the MBP had some really stellar hardware. It did work well, only crashing maybe twice in the year I had it (far better than windows, not as good as Ubuntu). The only thing I would consider superior about windows is its power management. My son's Asus EEE is identical to mine, but windows stretches the power use over a much greater period.
Well, unless someone talks me out of it, it will either be a MBP or a Thinkpad when I place my order. It will be either Ubuntu or OS/X and windows in a VM.
Subscribe to:
Posts (Atom)