Leif in Real Life

Scribblings of a software dude.

Discovering YAWL

On the train to work this morning, I was listening to the latest episode of Software Engineering Radio, which was an interview with business process management and workflow systems guru, Wil van der Aalst.

Even though I’ve been involved in several workflow-oriented software projects, I haven’t got much academic knowledge on the subject of process modelling. My involvement in said projects has primarily been about interviewing domain experts to understand “how things are done” in their organization, for then to distill this information into a graphical representation, usually in the form of swimlane diagrams. My graphical representations would then be used for reference when developing tailored software products.

Most of the concepts and tools that I use when working with domain experts, I have picked up by reading bits and pieces of Alec Sharp and Patrick McDermott’s book on Workflow Modeling on a “need-to-read basis.” I really should finish reading it; the pieces that I’ve read so far were very good. Time is a scarce resource.

To create my swimlane diagrams and other process models, I’ve used purely visual tools like Balsamiq, Lucidchart, Gliffy and even Adobe Illustrator. The programmer in me is embarrased to admit that it didn’t cross my mind to turn these diagrams into something executable…

I’m happy that I listened in on this podcast today, learned a thing or two about YAWL and other tools that I can turn my graphics into something verifiable and executable. This is definitely a path that I’m going to follow, at least for a little while, to see where it goes. In any case, this is a very interesting subject.

Many thanks to @seradio and @wvdaalst for the interview.

“Learn to Program” by Chris Pine

Do you want to learn how to program, but you don’t know where to start? If you like learning from books, then Chris Pine’s “Learn to Program” is the book you need to get started.

With examples in Ruby, not only will you learn the fundamentals of object-oriented programming; you’ll also get exposed to good practices and gain some insight into how programmers think when solving problems. Humour sprinkled throughout the book and exercises at the end of each chapter help solidify your knowledge.

You won’t be an expert by the end of it, but you’ll definitely be on the right track; capable of experimenting with your own programs and understanding some more advanced material.

From now on, this is the book I’ll recommend to friends who are interested in learning how to program. I’m also considering using this book in my introductory programming course for project managers.

How to Combine Git and DropBox—The Best of Both Worlds

Git is my preferred flavor of version control for code these days, and I’m also a fan of DropBox. Recently, I discovered a nifty way to combine the two.

But why would I need to do that? Wouldn’t Git be enough? Well… Sometimes, I want to continue working on another computer, but I don’t feel like my changes are ready to be committed just yet.

Sure, I could commit my changes to a separate “feature branch.”. But I like keeping my history clean, and I find it much easier not to dirty it up in the first place, than to manually rewrite my history when I’m ready to push.

Another reason for this is that I like to keep a backup of all my untracked work, in case of disaster. (I used to have a homemade script for this, but now it’s retired).

How I set up my projects

First, I’ll create a bare repository somewhere (usually on BitBucket).

Then I’ll create a new folder, somewhere in my DropBox: mkdir ~/Dropbox/code/new_project_name

After that, I’ll clone my new (empty) BitBucket repository into my new DropBox folder: cd ~/Dropbox/code/new_project_name git clone git@bitbucket.org:username/new_project_name.git

I don’t like working in my DropBox folder directly, so I’ll create a symbolic link from the new DropBox folder to my preferred workspace: ln -s path_to_new_dropbox_folder ~/code/new_project_name

Simple, eh? Now I can work on untracked and uncommitted files wherever I want and DropBox will take care of syncing it across all of my computers (including my iPhone).

I’ve also experimented with initializing a bare repository directly in DropBox and using that as my remote. It works when you’re flying solo, but you’ll start having problems if you share it with other developers.

“Agile Estimating and Planning” by Mike Cohn

I just finished reading Agile Estimation and Planning by Mike Cohn today and thought I’d write up some of my immediate thoughts.

This book is absolutely jam-packed with exceedingly practical tools and techniques. It’s also very well sectioned and organized, so it will definitely make for a good reference and guide in the trenches.

The main thing that sets this book apart from the rest, is that it shows you how to deal with things. Having participated in agile development on several small and large projects, I feel like this book really captures a lot of the real-world challenges you are likely to encounter and shows you how to deal with them.

Each chapter walks you through one fairly isolated subject; theory and examples. The last chapter takes you through a case study, where a lot of the tools and techniques presented throughout the previous chapters are applied.

My main take-aways from this book

  • Insight from an experienced agile practitioner on what does and does not work.
  • Being more conscious about factors to consider when prioritizing features.
  • Understanding the differences between date-driven and feature-driven projects.
  • Advice on when and how to forecast a team’s velocity.
  • Very useful techniques on how to split, merge and taskify user stories.
  • Exciting tools for financial prioritization of features (very unique for its genre!).
  • Two interesting tools for obtaining a feature’s desirability.
  • Knowing when and why to estimates in different units and ranges.
  • Understanding when and how to use “feature buffers” and “schedule buffers.”
  • How to use release and iteration burn-down charts more effectively.
  • A useful template for writing “iteration reports” if need be.
  • Some new techniques for interteam dependencies on multi-team projects.
  • Answered a lot of small, pointed questions that have been lingering for a while.

I recommend this book to…

  • Product Managers/Owners, marketing people and C-levels.
  • Project Managers who need practical advice on agile software development.
  • Developers who are above average interested in project planning and execution.
  • Anyone who wants to introduce (or improve) agile practices in their organization.

This book might answer a lot of your questions. It answered a lot of mine.

The Journal of an Agile Practitioner (Introduction)

Being a software developer who is more than a little bit interested in the practical application of Agile methods (understatement of the year), I frequently stumble upon interesting questions, discussions, thoughts and stories from my kins in the field.

Despite an overwhelming amount of really good books on the subject, there still seems to be a surprisingly high demand for information and insight from real-word experiences on what it means to be Agile. Stories from the trenches, so to speak.

This series of (upcoming) blog posts will be my humble attempt to share some of my candid thoughts and experiences. Perhaps someone else out there could make use of it for the greater good or, if nothing else, at least I will have lightened my head a little bit.

Oh, and if you have any questions or feel like you have some related story or trick that you would like to share with the world, then I would be thrilled to have you as a guest blogger in this series. Please drop me a line via my contact form if you’re interested.

Stay tuned for the first post in the series! Subscribe here (RSS).