I was first introduced to Trac by Bruce D’Arcus in December of 2004. At that point in history one could easily claim that setting up Trac was very much NOT Pythonic**.

On the other hand, using Trac for the first time was my initial introduction to the “Pythonic method” (if there is such a thing), in this case, the Pythonic approach to managing software development.

Firstly, what is Trac?

Trac is an enhanced wiki and issue tracking system for software development projects. Trac uses a minimalistic approach to web-based software project management. Our mission; to help developers write great software while staying out of the way. Trac should impose as little as possible on a team’s established development process and policies.

Okay, so while the focus is primarily on software development, in my own experience, Trac can easily be used for managing MUCH more than just software development. In fact, I would definitely go as far as suggesting that in many ways Trac implements (again, if there is such a thing) the Pythonic method to workflow management, and as such, can be applied to any type of project, software and non-software related alike.

Just to clear things up, what does it mean to be Pythonic?

A quick search for the term “Pythonic” will result in several links that provide definitions in proper context. For example,

To be Pythonic is to use the Python constructs and datastructures with clean, readable idioms. It is Pythonic is to exploit dynamic typing for instance, and it’s definitely not Pythonic to introduce static-type style verbosity into the picture where not needed. To be Pythonic is to avoid surprising experienced Python programmers with unfamiliar ways to accomplish a task.

Before moving forward lets check-in with what Sean has to say,

ITworld.com - Does work actually flow?

In my experience, workflows - even very complex ones - can be gross over-simplifications of the real world. In mechanizing a workflow, architects typically use concepts of task, role and transition. Simply put, a workflow is a combination of tasks. Tasks are ‘resting places’ in a workflow. To move a workflow from one resting place to another, somebody playing the right role must move the work along by doing something. The ’something’ that they do must be a valid something per the workflow. It must result in an approved transition from one resting place to another. If you don’t have the right role or if you are doing the wrong thing or trying an unapproved transition, the computer will stop you. It will beep or start sulking or turn various options of gray on you.

While I am happy to see efforts being put forth in regards to products such as the Windows Workflow Foundation, I must admit that I am 100% behind what Sean has put forward. Work doesn’t flow in a manner that is machine readable. In fact, in some cases, work doesn’t flow at all.

Then again, sometimes it does.

And other times it doesn’t. And it’s these other times that I would venture to state match the 80% side of the 80/20 rule. Or in other words, it takes 20% of the time to complete 80% of the work(in this example, this would represent the “flow”), and 80% of the time to complete the remaining 20% (in this example this would represent that in which does not “flow”, potentially defined using the term: chaos.)

Ask yourself this question: How many projects have you worked on that were “this >< close” to completion, and yet never quite got finished? (I’d answer this question myself, but I am a bit too embarrassed to admit the answer. Suffice it to say, LOTS (and LOTS and LOTS (and LOTS)))

Dr. Michael Kay once made the paraphrased comment to me that,

“… there are starters and there are finishers in this world. Its rare to find someone who has the ability to do both, and both traits are necessary and important pieces of the overall development process.”

(I’ll let you guess which one he is and which one I am ;)

Okay, so I think he was just being polite, but his point was well taken, and even further, completely on target to the reality of what the world is truly like.

Extending from his point, it is my own belief that the very best project managers don’t actually manage a projects workflow.

Instead, they capture chaos and then get the hell out of the way before chaos captures them right back.

Just like a well written Python program such as Trac.

Thanks for the snap-back into reality, Sean!

–
** In “modern” times, Trac is quite simple to install.

EXTENDED-NOTE: I realize I didn’t go into much detail in regards to why Trac is such a fantastic project management system, but its not the kind of thing you can really put into words. Its just something you have to discover for yourself. As such, I would encourage you to do just that.