The company chatter mill was discussing the recent blog-talk about the relatively low line count of tadalist. I’m not sure how one can disregard the framework line count and the years of other work which resulted in the RoR framework. Lets take a look at where this task management software is failing me, and ript it a bit.

First off the design seems to follow the personal shit/task list management style of clearing your lists proposed by management self help gurus such as David Allan and Timothy Ferris and The Steven Covey. What happens if you are not the typical type A person and you have a list that is growing like mint in spring, no matter its dead state over the winter it keeps growing back?

Figure 1. - My personal list.
This is a mix of people to call, crap to fix around the house etc. Hmm it quickly grew to around 20 items and seems to hover in this state no matter my relative mix of sitting my fat ass on the couch vs getting jacked up on coffee and “getting things done”.

So in this perpetual state of 20 items, the add another item link (btw, links are for navigation, buttons are for actions, but that is another point), is redonkulously placed in the middle of my list serving as the dividing line between stuff to do and stuff thats done. To rectify this problem I might throw the add link at the top instead. Maybe I’d put it at the bottom of the page, at least I’d be able to ctrl+end to get to the button. Maybe I could split the stuff to do vs stuff done lists in half, thereby pushing the bottom to the bottom, but that might invade on the google ads revenue on the right. In any case the last place the link belongs is in the middle. Finally I could add a keyboard shortcut to add a new item, this might be there but I tried some Usually combo strokes and did not find anything.

Figure 2 - DoubleClick to add an item.
Next, why the hell do I click a link call “add another item” only to expose a textbox, cancel link, and a button titled “add this item”. This design paradigm has the code smell of dhtml click-trickery. If a developer in my shop did this they would face a grilling about why we would force a user to click another link to perform a primary action, adding an item. The clutter of the textbox, button and link does not need to be hidden. This type of flashiness is common for people who are just learning the artistry of dhtml. Remember, just because some browsers supported the <marquee> or <blink> tag does not mean we should have used them.

I could continue on with how the separate click into reorder mode renders the act of prioritization more annoying than I want, or how I do not understand the sorting mechanism on the main my lists page, or how this page is not reorderable, but my point in this dissection is not to catalog the design issues.

While its an admirable but questionable fact that tadalist was written with 600 lines of code, the “simplicity” of this app actually has some critical flaws. An honest evaluation of clickability, and navigation could result in no more net lines of code but a better product. As we move agile into the mainstream look out for more sophisticated methodologies to synthesize client feedback to migrate products from KISS to KIMACS.

I picked this one up coming out of the agile dev practices conference in Orlando. The speakers I meet, Jeff Patton, Rob Myers, Jean Tabaka, James Shore and some folks from Rally Dev were jazzed to hear the key note of the book’s author Mary Poppendieck. Mary’s keynote pitch, stuffed with an abundance of historical comparisons, focused on agile’s step onto the main stage. I’d have to agree, I met many people there from companies such as State Farm, Lockheed Martin, and UPS. Agile has now has the potential to fail just like any other management philosophy before it.

A relatively quick read, the book is divided into 8 chapters:

1. Eliminate Waste
2. Amplify Learning
3. Decide as Late as Possible
4. Deliver as Fast as Possible
5. Empower the Team
6. Build Integrity In
7. See the Whole
8. Instructions and Warranty

Overall I’d put the value of the book at a 9 out of 10. It highlights principles that manufacturing has honed but the young knowledge based software industry sometimes forgets. While some people might call these principles obvious the book has provided me with a richer vocabulary for describing some practices I have already been using. I’ll pontificate about just one and let you read the rest since the source can always explain it better.

In Jean Tabaka’s Collaboration Explained: Facilitation Skills for Software Project Leaders (The Agile Software Development Series) workshop we discussed how to facilitate from divergent viewpoints through to convergence. These skills are extremely important if you are going to attempt the practice of set-based design.

In set-based development, communication is about constraints, not choices. This turns out to be a very powerful form of communication, requiring significantly less data to convey far more information.

You probably use this technique already. If you have a tight calendar then you know how to setup meetings in this fashion. Rather than asking the other person when they would like to meet or giving them one option you let them know you can meet Friday between 1-2 or Monday between 3-4. Always give them a face-saving way out, like “if these times do not work please let me know a better time within the next week.” This decision making process is much more efficient than asking open ended questions like, when can we meet? It usually only requires 1-2 rounds of negotiation rather than 3-4.

You might be wondering, what does this have to do with my current project? Well if your team struggles to move to convergence, and/or your development lifecycle is too long, then your set-based process will be in jeopardy as the divergence begins to affect product integrity. Communication about which state you are in convergence or divergence on any particular aspect of your development must be clearly stated.

If your attempting to “go agile”, read this book and then pass it on to your boss. And don’t forget to buy it through the link above :)

• “tests act like herding dogs, they keep the sheep together, but not in one place”
• “The intent of the code lives in the tests”
• “Legacy code is code without tests”, quote from someone else

Seems like I have been writing a lot of legacy code.