Archive for March, 2006

Fast Track Project Management on TuboGears

Optio software has released the Fast Track Project management application under an MPL license. I’ve got a SVN checkout of the code on my desktop right now and it looks like it will be very useful in a couple of different ways.

Project PreviewThe key to good project management is communicating clearly.

I think Fast Track is right on target, in terms of Project Management
theory — project management is about expectations, risks, and
commitment. FastTrack is a tool to facilitate project communication — not a tool to create gantt charts or work breakdown structures. I know some people who live and die by these tools, but think they usually do little more than get in the way of communication, and restrict your ability to adapt to changes in the project over time. In other words they make project management harder. Fast Track on the other hand is all about communicating various project status information in human language. Unlike other project management tools, Fast Track is makes sense to me, and is a tool I want to use.

The fast track code looks good.

I have a SVN checkout of the code on my desktop right now. So far it looks clean, usable, and easy to understand.

If you are new to TurboGears, and you want to understand how real applications are written, this is a great example.

In fact, if all goes well FastTrack will be one of main sources for real world example code in the TurboGears book that Kevin and I have been working on.

Lean Book Publication

Over on his blog, Dave Thomas talks about how other book publishers are imitating some of the changes that the Pragmatic Bookshelf has made. He points out that many of their competitors are adopting the surface changes they have instituted like “beta books” and PDF only books, while ignoring the deeper philosophical underpinnings that made those changes necessary and obvious.

He goes on to point out that this is much the same as the way American automotive manufacturers tried (and failed) to copy the success of Toyota by implementing “Lean Manufacturing”. They copied the things Toyota was doing, without understanding why Toyota was doing those things.

Behind all of the changes at The Pragmatic Bookshelf is a vision of eliminating waste, and making it easier to make changes to a book through the entire process. They moved a huge step forward just by having their entire book line under version control. Then they added an automated build system, which eliminates a lot of the time consuming — and error prone — process of manually doing the layout for every page.

These two simple things mean that the “Camera Ready” version of every book is regenerated after every author change. And the entire history of every author, proofreader, or editorial change is recorded in their version control system.

This makes it easy to accept updates to chapters, right up to the very last second.

Not only that, it also reduces the complexity of working together, and helps authors, editors, and proofreaders to do their job better. So, in one fell swoop they have eliminated significant waste, integrated production knowledge into the design process, and reduced their overall product development time significantly.

We are doing much the same thing with the TurboGears book.

Fortunately, I can say with total confidence that we are not just doing this to imitate the success of Pragmatic Bookshelf, we’re doing it because it makes our lives easier, because we want to design the best book we can — with the best methods and tools we have available to us — and because we are focused on eliminating wasted steps in the process.

We’ve got the text of the book in a subversion repository, along with screen-grabs, code, and all the other pieces necessary to build the whole book. And as soon as we get the templates from the publisher, I plan to build XML styles along with a simple script (written in Python of course!) so that we can auto-build the book with In-Design whenever we make changes.

While, I think the Pragmatic Bookshelf idea of a “beta book” is progress, it’s not good enough.

Those of us doing Agile software development have reduced the need for “beta” testing by delivering product incrementally. So, with that in mind, we are interested in moving the state of the art forward by adding incremental delivery to the book writing process. We have a Trac site where any number of volunteer reviewers can look at every revision of the book in real-time as it is produced and provide us with immediate feedback

And we have online and in-person classes where we are going to deliver the book incrementally to real users (people who want to learn TurboGears) and watch how they assimilate the information in the book. We’ll use the experience and knowledge we gain from these incremental releases to refine the book as we go.

Hopefully this makes a better book. But what I know right now from the trenches is that it sure makes the process a whole lot easier, and more fun.

Framework Comparison Video

Sean Kelly has posted an interesting comparison (warning 60 min video!) of Rails, TurboGears, Django, Plone, and Java Sevlets/JSP, and full fledged J2EE development.

There is a lot of interesting commentary on this movie floating around out there, so I thought it might be worth while to try to gather some of that commentary in one place.

Overall, I think the message of the video is: The “Dynamic Language Frameworks” are all demonstrably better than their Java counterparts for web based application development. These frameworks allow you to make small incremental changes to the user interface as you test your ideas with real users.

And this conclusion is exactly right — user interface design is hard, and it requires the ability to iterate and deploy incremental improvements.
But before I move on to other people’s commentary, let me say a couple of things from my own perspective:

  1. Plone rocks for a certain set of problems, which it can solve out of the box.
  2. Sean uses TurboGears 0.8. Had he used the newly released 0.9 he would have been able to get authentication and automatic CRUD. Someone made his application with something like 9 lines of TG 0.9 code! :)
  3. Rails and Django also have internationalization frameworks now too (For those of you where this is important, I think Django and TurboGears do internationalization better than Rails because of Python’s Unicode support).
  4. His application is pretty trivial — a real test for these applications would look better for the TurboGears framework.

On the web people have been saying (I’ll do my best to be complete, and get the attribution right):

  • He’s very kind to Zope/Plone, if you step out of the Plone box then the cliff is indeed there but if you stay inside Plone everything tends to look like Plone and act like Plone and that isn’t that useful. That said, I’m sticking with Zope. — Simon Lucy
  • This Lessig-style presentation is mostly good, especially if you want to compare J2EE to web frameworks in general… it clearly shows how using any of these frameworks will drastically decrease your development time and lines of code, and generally make your life a lot more fun. — Jeff Croft
  • I should point out, though, that his version of Django was a little outdated, and his impressions of it had a few inaccuracies. Django’s got excellent i18n support, and for a while now it’s been able to use it without a database. Still, as long as someone’s not using J2EE, that’s a win for all of us dynamic-language freaks :) Jacob Kaplan-Moss

My complaint (and it is a minor one) is that Sean seems to get a lot of things wrong about TurboGears, Django, and Rails, so it’s not very good at providing insight into which of these frameworks is going to be the best fit for your particular needs.

Most of the problems I have with his analysis stem from the fact that these three “dynamic language frameworks” are growing and evolving very quickly.

TurboGears, Rails, Django, Plone, and Zope 3 are building the future today. I’m most connected with the future of TurboGears, and I have to say that the changes that are coming present a lot of exciting possibilities. If this is any indication of what is happening in Django, Zope and Rails, then the future of Python web development frameworks looks very bright indeed.

Links from PyCon

Steve Holden has a blog, with very little Google-foo, but a lot of great content! I missed the IronPython talk, so I was very happy to find extensive notes on it.

Steve is the author of Python Web Programming, which is the granddaddy of all python books about the web, and still has a special place in my heart.

Some people who bought it were surprised to discover that it covered network programming, and building a web server, in detail, and spent less time dealing with how to get things done with existing web frameworks. But I actually liked that it covered the topic of web programming from top to bottom, and got you involved in all of the details of what was happening from the network packet level right on up to serving pages.

That’s a book that could only be written in a language like Python, and it’s a book with a much longer shelf life than something tied to a specific implementation technology.

“Always doing your best” considered harmful?

If it’s worth doing, it’s worth doing right!

I can’t dance well, and I’m a bit clumsy in general, but if my wife wants to dance, I won’t let my inability to do it right stop me from doing my best.

I’ve always thought that doing my best was a better guide than getting it “right,” but lately I’m more and more aware that even doing my best undercuts my ability to get things done.

My urge to always do my best is often the enemy of “good enough.” I have been avoiding hacking together a quick script to automate a frustrating chore, because whenever I start on it, I immediately think of all the corner cases where the script won’t work, and I know that I don’t have time to write a script that is smart enough to handle everything.

I suppose the other alternative is to spend a hour to automate the 80% of the cases where the script doesn’t have to be smart at all. Unfortunately, I don’t want to do that, because it’s ugly and hackish, and requires the user to know the corner cases where it won’t work. I suppose that  I could just have the script ask, “is this {corner case} true?” and bomb out if the user says yes, but that’s clearly not the best that I can do.

Unfortunately, I just don’t have time to do it right. If I can get out the mindset of either doing my best, or not doing it at all, I would notice that I have three choices:

  1. Keep doing everything manually, and spending a total of 20 hours on this task over the next year.
  2. Spend 60-80 hours automating the whole task.
  3. Spend 1-2 hours automating 80% of the task, and 4 hours doing the non-automated portion of the task this year.

Clearly when it’s laid out this way, option 3 seems great — it gets the job done in half a day rather than the two days to two weeks the other options. But because I have this internal rule “always do your best” I am tempted to waste nearly two weeks automating something that would only take 20 hours to do manually over the next year. And, who knows if we’ll still be using that system then…

Esther Derby’s Software Management blog talks about how managers can handle this task with A, B, and C tags for their task lists. The tags to the quality of work required for that task with A level items being work that would receive an A grade. I’m a big fan of the David Allen system for managing your tasks and projects, but I think something like this for makes sense for tagging items on your Projects list. I’m not yet tagging everything like this, but I am certainly working to make sure that I identify the tasks where quality matters less than getting to done.

And, of course, I’m working to communicate this information to people when I delegate responsibility for these tasks!

It is easy to allow people to do things to a higher quality level than necessary. After all, you don’t see the time they are wasting on building in unneeded features or unnecessary polish, but the fact that it’s not your time, and that you don’t see it directly, doesn’t make the time any less wasted.

If it’s worth doing, it’s worth doing poorly.

If it’s not worth doing poorly, it’s not worth doing at all. And of course, it might also be worth taking the extra time to do it right. But there are lots of things where good enough is less than the best you could give.

And even more humbling, there are lots of things in life where good enough is better than the best I can give, and so I have to either do them half way (when that’s better than nothing), or just leave them for somebody else to do.