Subscribe
Posted on September 30th, 2008
Recently there has been a lot of talk in the Agile community about moving away from estimated stories into more of a Kanban-style “pull-based” system. At Agile 2008, Joshua Kerievsky did a talk on MicroReleases where he discussed how his team did just that. They base the next release (which is just a couple of days away) on a gut feel of what the can accomplish. However, when you are working with teams who have a much longer release cycle, velocity estimates can be vital to product planning for both the developers and the business.
For example, when I worked at CARFAX we had to coordinate our releases with marketing efforts, campaigns, TV ads, etc. This meant that we needed to have a projection system we could utilize to estimate when we’d be done. So the business (in our case, the Product Manager) would bring the user stories needed for that release. We as a team would estimate them based on level of difficulty – 1, 2, 4, 8, 16, etc. We would then add up all of the effort estimates and add two cards – a budget card and a change card, both equal to 10% of the effort.
We worked in weekly iterations, so the first week we would commit to completing (code complete, QA, and Business Verified) a certain set of stories. In subsequent weeks, we could “sign up” for as many story points as we completed in the last iteration (also known as “Yesterday’s Weather“)
What this allowed us to do was project the end date (the part we could control of scope/quality/date) with great accuracy. On 6-month projects, we typically could release the week we said we would.
On the team I’m currently working with, we are dealing with a fixed date, since our release is tied around an entire user conference. What this typically meant in the past was that the development team was handed a list of specs, they did their best to try to meet that, and the last 3 months of a 12-18 month release cycle were the typical “death march” of 14 hour days, weekends, etc.
One of the first things I did when I came on board was to bring all of the stories and features that were spread across SharePoint sites, Excel spreadsheets, emails and people’s heads into a centralized place, and have that place be the area where if the developers were working on something not in that system, they were in the wrong.
All of the items were estimated (or re-estimated in some cases) using the relative effort estimates. Our first iteration consisted of a gut feel of what they could complete. It seemed to go very well for them. The second iteration didn’t – mainly because the first iteration was technical tasks, and in the second iteration, the agreement of teams not getting velocity until the story was coded, QA’d and verified by the business came much more into play. One team went from a velocity of 27 in the first iteration to 1 (yes, one) in the second iteration.
However, once we worked through those issues, we turned our focus to the backlogs and burndown charts. Based on each team’s velocity, we projected out where we would be at the cut-off date for the product. What we found was that, at the date we wanted to be able to be code complete, each team would have 75% of their tasks remaining. As you can imagine, this was quite a shock to the management, who had been prepped for something like this to happen.
However, what happened next is one of the most important things a team can do, and perhaps the make or break point for almost any team. Knowing we couldn’t adjust cost or the date, we began to work together as a management team to reprioritize the features based on the velocity estimates. Our executives could have simply rejected the velocities and creeded 14-hour days. Or ignored the results. But, instead, they took the information they were given early in the process and can now craft a response to it in a calm fashion without having to back out of promises.
In other words, in a previous release, this information would have been discovered practically at the end of the cycle – long after the release plans had been sent to the customers of what would be in the release, and after the agendas had been made for the conference. Literally the only option the team had was to nearly kill themselves to finish everything. Now, we can have serious, but calm, discussions about our strategy for truly delivering the most important business value in the time allotted.
We were able to make these decisions because we had solid information at our hand of what the teams were capable of, and what kind of effort we had laid out before us. Of course, nothing is perfect, and I’m sure velocity may change somewhat, stories may get added, or bugs may be found. But having the ability to report to the decision-makers what they can expect, couple with their willingness to work closely with the teams to deliver business value, can dramatically change how you build software.
Posted on September 28th, 2008
Last week, we had a small incident arise with the team I’m working with. Our Continuous Integration server is now live, meaning that code gets compiled with every check-in. This is great from the perspective of rapid feedback – if there is a failure, we don’t have to wait for a nightly build – or for someone to have a problem on their machine – before we discover it.
However, this practice can be a bit overwhelming, especially in teams that haven’t conquered the Five Dysfunctions. In this case, some of the staff were a little nervous that every change would cause a build, and were adamant that they had a specific need to check in broken code.
In cases like this, especially as an external change agent, it is important to step back and look at what is going on, and what solutions are. In this case, I have the authority to say, “This is how it is” – but it is very challenging to win the trust of the team that way.
Instead, recognize what is going on:
- Something new has happened, and so there may be pushback because it is change
- The feeling may be that the breaks would be used as a metric-stick to beat the developers with. In reality it is a tool solely for them, but not everyone has the trust of that yet
- Some people may feel very uncomfortable being put in the spotlight
- The CI server automatically forces 2 of the 5 dysfunctions – inattention to results and avoidance of accountability. Well, assuming the team doesn’t just ignore the build server breaks
- There may truly be a need for someone to work in that manner. It may sound silly, but don’t rule this out
Given that we want to keep our mainline building, and that not running the CI server isn’t an option (nor having it not build on every checkin) what are the options we have?
- Work with the developers to understand their need, and offer help to mend the process so checking in broken code isn’t required
- Have them move forward with checking in with the understanding that you’ll work closely with them to fix any breaks
- Have them create a branch they can check in to, and then merge the changes back to the mainline once everything is in
So, even though it is tempting to just say, “Do it!”, we have options at our disposal. In this case, I recommended options 1-3 above. And once we had a chance to talk even more (because they felt more at ease) they were able to internalize more of the reasons for a CI server, and it turns out that they didn’t need any of the above.
So, as you work with your teams, it is vital to take into account the stages your team and the individuals are at. Sometimes we have to make tradeoffs in our process to account for the people. And People over Process is why we’re doing this at all.
Posted on September 24th, 2008
After some great comments in my last post and some judicious refactoring, I now present an entire binary clock in Ruby in less than 55 lines of code using Shoes:
Shoes.app {
@width = 40
@left = 10
@margin = 10
@top = 180
@offset = @width + @margin
@fill = red
@images = [[],[0],[1],[0,1],[2],[0,2],[1,2],[0,1,2],[3],[0,3]]
def gen_recs(num)
return stack {
fill @fill
num.times do |i|
rect :left => @left, :top => (@top - (i*@offset)), :width => @width
end
@left += @offset
}
end
def turn_on_images(num, stack1, stack2)
time = num.to_s.split(//)
t1 = []
t1 = @images[time[0].to_i] if time.length > 1
t2 = @images[time[time.length-1].to_i]
activate_images(stack1, t1)
activate_images(stack2, t2)
end
def activate_images(stack, image_pos_array)
stack.contents.each do |item|
item.style :fill => @fill
end
image_pos_array.each do |pos|
stack.contents[pos].style :fill => green
end
end
@hours1 = gen_recs(2)
@hours2 = gen_recs(4)
@minutes1 = gen_recs(3)
@minutes2 = gen_recs(4)
@seconds1 = gen_recs(3)
@seconds2 = gen_recs(4)
every(1) do
now = Time.new
turn_on_images(now.sec, @seconds1, @seconds2)
turn_on_images(now.min, @minutes1, @minutes2)
turn_on_images(now.hour, @hours1, @hours2)
end
}
Posted on September 21st, 2008
When Shoes – a “tiny graphics toolkit for Ruby” – first came out a month or two ago, I was excited, but didn’t really have much to do with it. Then it hit me – I love my Binary Clock on my iGoogle home page – why not build one?
The first thing to learn about Shoes is that you can stack things and then save them basically as an array. Since a binary clock has 6 columns, I created a variable for each column which contained the squares. This looked like:
@hours2 = stack {
fill @fill
4.times do |i|
rect :left => @left, :top => (@top - (i*@offset)), :width => @width
end
}
Which says to create a stack with the fill color of our fill, and draw four rectangles, bottom up.
Next, I had to figure out which images to turn on. The code to flip the seconds looked like:
sec = now.sec.to_s.split(//)
sec1 = []
sec1 = get_image_pos_to_turn_on(sec[0]) if sec.length > 1
sec2 = get_image_pos_to_turn_on(sec[sec.length-1])
turn_on_images(@seconds1, sec1)
turn_on_images(@seconds2, sec2)
Which isn’t all that pretty, but works. For example, the get_image_pos_to_turn_on method is just this:
def get_image_pos_to_turn_on(num)
images = []
images = [0] if num == "1"
images = [1] if num == "2"
images = [0,1] if num == "3"
images = [2] if num == "4"
images = [0,2] if num == "5"
images = [1,2] if num == "6"
images = [0,1,2] if num == "7"
images = [3] if num == "8"
images = [0,3] if num == "9"
return images
end
And, well, that’s it. Which is the beauty of the Shoes app. It makes simple things simple. Here’s a screen shot of it in action:
You can download the full source code from here: binary_clock.rb. You’ll also need to download Shoes from the above link, and run the app by doing shoes binary_clock.rb.
And, this being my first Shoes app, I’m more than happy to take comments and suggestions for better ways to do it. Considering I did this whole thing in about 30 minutes with having barely looked at Shoes before, I’m pretty happy.
Posted on September 12th, 2008
As developers, system admins, and a variety of other roles in IT, we have to deal with code on a daily basis. Sometimes it’s just one-off scripts we (hopefully) never have to see again. Sometimes (Ok, most of the time) we stare at something that, for the life of us, we can’t understand how it came out of a human mind (or, as the book puts it, has a high WTF/minute count). But there is a time when you find code that is a joy to use, to read and to understand. Clean Code sets out to help developers write that third kind of code through a series of essay-type chapters on a variety of topics. But does it really help?
I had the pleasure of attending Bob Martin (Uncle Bob)’s sessions at several agile software conferences over the past several years. In them, Bob has a unique way of showing us the value of clean code. This book is no different. There is a warning in the introduction that this is going to be hard work – this isn’t a “feel good” kind of book, but one where we slog through crappy code to understand how to make it better. The authors also point out that this is their view of what clean code is all about – and fully acknowledge that readers may “violently disagree” with some of the concepts.
The book wastes no time diving in covering “Meaningful Names”, “Functions” and “Comments” right in the first several chapters. While I could sum up the chapters by saying, “Use them”, “Keep them small” and “Comments don’t make up for bad code” it wouldn’t do the wisdom in the book justice. For example, in the meaningful names chapter, he talks about making pronounceable and searchable names – staying away from things like “genymdhms” (Generation date, year, month, day, hour, minute and second) and preferring things like MAX_STUDENTS_PER_CLASS.
After touching on formatting rules (including some very interesting graphs on the file and function length distributions in some common open source projects) he dives back into some more controversial topics – “Objects and Data Structures”, and “Error Handling”. The Objects chapter does a great job of drawing a line in the sand between Objects and Data Structures and why it really is both important, and clearer, to keep your privates in your private classes.
The Error Handling chapter is important because of the application of earlier chapters – the Do One Thing rule. Your functions should do one thing – either handle business logic, or exception handling, but not both. It’s the difference between this:
try {
s = new Socket(4000);
s.OpenSocket();
string data = s.ReadFromSocket();
if(data == "32")
data = "42";
printer.print(data);
} catch(Exception ex) {
if(ex == NetworkInterruptException) { //do something }
if(ex == PrinterOnFireException) { //do something }
logException(ex);
}
And this
try {
tryToPrintDataFromSocket();
} catch(Exception ex) {
logException(ex);
}
We then move on to “Boundaries” and “Unit Tests” – the critical points where we tend to really let code go. If we work hard, usually we can keep our own code clean. It’s when we have to begin interacting with other systems that things start to go astray. In these chapters, Bob and James Grenning show us how to keep our code at the boundaries clean – and how to keep our code working, period. The authors are proponents of Test-Driven Development, and the chapter on unit tests is a fresh reminder that those tests are just as much code, and need to be kept just as clean as any other code we write.
We then begin to move at a higher level, starting with “Classes” and “Systems”. The classes section should be familiar to most any OO programmer – keep the classes small, with a single responsibility, and low coupling. He also talks about Organizing for Change which is a great section on how to structure classes in a way that keeps them open to change. The Systems section continues along the path with the great reminder to “Separate Constructing a System from Using It”. Here they go into Dependency Injection and Aspect-Oriented Programming, which I’ll address in a bit.
Moving even higher up the chain, the book then tackles “Emergent Design”. The key is to keep the design simple, which according to Kent Beck, means:
- Runs all the tests
- Contains no duplication
- Expresses the intent of the programmer
- Minimizes the number of classes and methods
With the above list given in order of importance. Really this breaks out to “Runs all the Tests” and “Refactoring” or making the code better. Simple design is perhaps one of the harder things out there, and yet the most important. When you look at systems that highly scale, it’s because they are made up of simply designed components which work very well together.
After the Emergent Design chapter there is suddenly a chapter on Concurrency. This was not something I expected to see, but was very glad to. Too many times books about patterns and design don’t address problems like scaling and concurrency. But this chapter does a great job of introducing the necessary steps that need to be taken to deal with concurrency – while still keeping your code clean. The book also provides an appendix which goes even deeper into the concurrency topic which I found to be quite good. Both this chapter and the appendix provide some very valuable rules that I personally have used when writing concurrent systems – like “Get your nonthreaded code working first” and “Run with more threads than processors” to flush out problems.
Chapters 14-16 cover the cleaning up of three different sections of code – an argument processor, JUnit and SerialDate, which is part of the org.jfree package. These chapters really hold true to the warning in the introduction that we’d be going through some code. However, the refinements work very well, and I think that each of them show the value of how much cleaning up the code can improve the readability of even code that works well and seems clean.
The last chapter is a “Smells and Heuristics” chapter which I’m finding to be a handy reference guide for code smells I see. When something is bothering me with code I’m reading, I flip to this section first to see if they have it listed. And with things like “Replace Magic Numbers with Named Constants” you can be sure that all of the advice that should have been beaten into your head long ago is still there, and relevant.
All in all I think this is a very valuable book for any developer wanting to improve how they write code. For senior level people, some things may seem trivial, but if you really take the time to look at the structural changes being made and apply them, you will write better code. For functional developers – the authors believe in OO, but there are still valuable nuggets that are applicable outside of that (like “Use Copies of Data” in the concurrency section). And for any developer, the insights are really good, and you’ll find yourself writing down little snippets to hang on the wall.
The challenges with the book are first that it is just as they said – hard work. This is not a flip-through-with-your-mind-shut-off type book. If you want the most out of it, you have to be willing to really work at it. The other challenges are that at times it gets way too Java-centric. All of the code examples being in Java is fine, but some of the chapters (most notably the Systems chapter) really go heavy into Java tools and the Java way which, to me, weren’t always applicable across languages.
All in all, I’d highly recommend this book to anyone wanting to improve how they write code. You likely will find yourself violently disagreeing with parts, but the total sum more than makes up for it.
Posted on September 2nd, 2008
This topic has come up in several of my readings today. While I’ve seen several strategies for what to do when your planning game is going too long, the best one is perhaps the simplest, and comes from none other than Ron Jeffries on the Scrum Development mailing list:
I suspect you’re going into way too much detail. And if you
over-commit, so what? Learn from it.Try planning poker.
Or, maybe try an experiment. For each story, as soon as it is read,
everyone writes their estimate on a card and puts it face down.
After a few minutes of discussion, write down another estimate and
put it face down. (Mark the cards so you’ll know which is first
etc.) At the end of “enough” discussion, make a third card.Take the average of the first cards, of the second cards, and of the
third cards. If the averages do not vary widely, what does that
suggest? If they do, note how they vary. Figure out why.