Thursday, August 24, 2006

Size does matter

When it comes to managing an Agile project team, one question usually arises for planners and managers is how big should a story really be. For the most people a story should be sized at the minimum as something that can be completed within an iteration by someone (or a programming pair). Each story is tagged with a difficulty level, whether you measure using 1-2-3 ideal development days or gummy bears, for best-guess estimates on how long it will take to implement the solution for the story.

I think while it looks trivial, story sizes is very important to an Agile team to manage business wishes of the application and development delivery of business values.

On some projects, a story could be one small thing on one screen (eg. enter customer address). Others, it spans multiple screens (eg. enter, edit, and delete customer info). For me, I would much prefer they being as small as they can be. For something like entering, editing, and customer info, strive to break things out to something meaningfully small, like:
- enter customer name
- enter customer address
- enter customer billing info
- edit customer name
- edit customer address
- edit customer billing info
- delete a customer

Small story has a few advantages:

More tailored to business needs
Suppose you have a specific need for a desktop computer, like you are a professional graphics designer or gamer. Would you be more satisfied for your purchase if you spend your budget at an online store for one of their 20 brand computers, or custom build it with hardware parts you get to play with one by one to address your specific needs? Is 1GB RAM gonna be enough? How about 2GB? Or 1GB plus more video card memory is good? If you purchase your computer parts by parts, chances are you will be buying something much more tailored to what you need now, at the same time pay for something that can accomodate tomorrow's change better (eg. a motherboard with more RAM slots than normal). The smaller your application's features are, the more flexibility you have. But don't go overboard and purchase your parts at microscopic level (buying transistors) which will cause you nightmare.

You can need it later, or YAGNI at all
You are building your dream vehicle from scratch. You have a tight budget, and a tight deadline. Do these constraints sound familiar? We are all working in this competitive business environment every day. So if you are building this car you need, can it satisfy your need with only 2 wheels like a motorbike? Does it still address your needs if it has three wheels? Do you need this car to have a 5th backup tire? Of course all these depends on what you use your car for. You might only need 2 wheels and as light weight as possible for a marathon or endurance race, or you might absolutely need a 5th wheel if you use it in the Africa dessert where there is no concrete. But the tight budget and deadline does not change, what changes is the delivery and whether the users' needs are satisfied. So, between one story that says "build 5 wheels for the vehicle" and five stories that says "add 1 additional wheel to the vehicle", what would you pick? Prioritization is key.

More consistent and better measured velocity
As previously mentioned, stories should be sized as something that can be completed in one iteration. Based on last iteration's performance, if you are planning for 3 stories to play the following iteration, constituting a 1-point, 2-point, and 3-point story. If the team were 99% complete with it but was unable to complete that 3-point story, your team's velocity dropped from a 6 down to a 3. This is a pretty big change in velocity. Now imagine you redo your iteration with 8 stories, same scope, a total of 20 points based on last iteration velocity. At the end of the iteration if your team cannot deliver one 2-point story and one 3-point story (note: much smaller scale), you team's velocity is 15. Your tracking of your development team's progress can be more accurately measured simply by splitting your stories up.
But with smaller stories it does come at a cost. There are some disadvantages.

Code is better, analysis is easier
Smaller stories encourage team members to complete something faster, meaning they get a chance to go back and refactor code easier and more often. It also allows programming pair to switch pairing partner more often to get more understanding of the code base. Smaller stories can also be defined in much more granularly fashion. Things that business do not understand yet can be split out to another story in order to get things going. Better tested and better understanding the code and stories, obviously makes your application more robust and easier to change.

With smaller stories, one must also understand there are drawbacks too. Here are a few I can think of:

Story explosion
Most people use an Excel spreadsheet to manage their day-to-day story progress. Having a spreadsheet of 60 stories is alright, now consider representing the same story list with 180 stories. If you are organizationally challenged, you will quickly run into issues with your tracking. How to categorize such information? Well, in today's blogsphere world there is something called tagging. You can tag a story with multiple tags, and later click on a tag topic (eg. UI) and a list of things you previously tagged will show up. This allows someone to quickly sort and filter the obviously larger story list. I don't know if there is a product out there that supports such information sorting and filtering yet, but I would start looking there if I were to solve this issue. is a good place to explore tagging.

Story selections
When there are more stories to choose from, playing the right stories becomes more tricky. It is common to have groups of stories that are tied to an area that is under heavy business analysis and are subject to change completely, and groups of stories that are fairly stable and not prone to change. But only picking stories that are stable and easy to complete is not the correct way to play stories. Whichever stories to play should depend on the complexity of the technical solution
and business value that can be recouped from that solution. The application is meaningless to the business if out of the 180 stories, 90 are complete, 60 are still under intense business analysis and are subject to change, and 30 are ready to go, while the business value generated by those 90 completed stories are trivial. Get down to the dirty aspect of the problem the application is trying to solve, and start flushing them out. Without a defined problem to solve, any application is way to expensive to build.

So should you go with diet size story or super-sized story? This question is like asking how diverse your investment portfolio should be. It depends. Now that you know why size does matter, apply your thinker's head to see whether it applies to the project you are on!

Friday, August 18, 2006

The "Not-Enough-Objects" anti-pattern

This is a pattern that every single programmer in the world had used at one point or another in their programming careers. Classes become unnecessarily bloated and multi-talented in their ability to single-handedly accomplish almost anything and everything an application requires.

Root Causes:
Being lazy to create new classes for new but not aligned behaviors into existing objects; being ignorant on good objects commuication and interactions; lack of concern of each objects' goal of existence; failure to realize the importance of programming to interfaces; putting off code refactoring forever (the "kitchen sink" syndrome 1); embraces code babies2 as if they are the next American Idols; failure to effectively organize, categorize, and classify application functionalities.


+ OrderSoda() ~20 LOC
+ Sleep() ~100 LOC
+ RPCCallTolMom() ~250 LOC
+ PlayTVGames() ~500 LOC
+ WebServiceCallToWalkMyDog() ~3,000 LOC
+ RepeatRoutineEveryDay() ~275 LOC
(many more methods)

When it appears in your code, they make your code become demoralizingly hard to read or comprehend; extremely difficult to touch code without introducing new errors; code become very brittle; code starts to look like POOP (Procedural Object-Oriented Programming); exponentially increase your programmers' after-hour caffeine consumption to life-threatening level against others (e.g. "I will kill the xxx if I knew who wrote this").

How to Avoid:
Avoid 1,000 line classes and/or 200 line methods; avoid class behaviors that are mutually exclusive; avoid class states that are mutually exclusive; avoid classes to have multiple responsibilities in favor of delegating to new objects that the classes use; avoid too many if-else statements in favor of object hierarchy (see Strategy); effectively categorize or organize your classes/namespace/file/folder structures into meaningful and humanitarian fashion; encourage collective code-ownership; frequently communicate with team members the intent of each object; feverishly unit test the heck out of each class and object using mocks and stubs; use TDD as test-driven design to think how other objects will use the object you are unit testing; pair-program with someone who reminds you of code quality is of utmost importance.

Short List of Skills Required to Avoid:
1. Programming to abstraction and not implementation
2. Object encapsulation
3. "Tell, Don't Ask" and the Law (or guideline) of Demeter (link), go back to #2 if you do not understand
4. Short methods/classes with well-intended names in favor of plethora of comments
5. Unit testing
6. All your unit tests run in sub-10 secs. because you understand Mock vs. Stub (link)
7. Dependency Injection (link)
8. Decoupling and cohesiveness (related to object-to-object communications)
9. Knowledge of design patterns of all types
10. Knowledge of anti-patterns

Have we understood why good programmers are rare?

(1) kitchen sink syndrome: If it is clean, it stays clean. Once dirty dishes goes in and no one bothers cleaning up, dishes will start piling up and they never get cleaned.
(2) code babies: A snippet or chunk of code, or application functionality that is given birth by its genetically related programmer that no one else in the planet understands or dares to understand.

Sunday, August 13, 2006

Time is money... Stop using your Quick Launch or Start menu

Do you have a list of 30+ icons of applications you use daily in you Quick Launch taskbar and you turned on its auto-hide feature? Do you try to actively manage your Start/Programs folders to make it easier for you to find and launch applications? Are you running out of keyboard shortcuts to launch your favourite applications? If you say yes to all these questions, chances are you are a power keyboard-driven user of your computer. It's simply a breeze without having to move your hands away from the keyboard and do everything on your computer.

To add more ammunition to you keyboard freaks, download and try Colibri. This is an application that lets you launch your apps by simply typing in a pattern that matches your apps' names! I mapped it to the F12 key on my laptop. When I want to launch Firefox, I press F12, then type in "fox", and hit enter and it is launched; When I want to launch MSN Messenger, I press F12, type in "mess", hit enter and it is launched...

It's pretty much similar to Google Desktop, but in GD after typing I have to use the up and down arrows multiple times to nav away from other doc types to get to app's exe. Colibri is strictly for app launching. If I type in "mess" for MSN Messenger, it will remember that you have used it to launch MSN Messenger, so next time rather than suggesting you to launch Y! Messenger it will default to MSN Messenger, while letting you to arrow down to select Y! Messenger should you want to.

I rarely use my Quick Launch or my Start menu anymore...

Bonus Tip 1: Did you know shift-F10 opens up your mouse right-click menu?
Bonus Tip 2: Turn on your "Begin finding when you begin typing" feature in your Firefox. I use this to "type-and-hit-enter" to surf the web =P