Older blog entries for ianclatworthy (starting at number 12)

Last week, my battle with colorectal cancer turned ugly again with confirmation that it had returned. After 15+ months of radiation treatment, major surgery x 2, hyperbaric oxygen treatment, chemotherapy and recovering from a stoma reversal, it was news I could have done without.
The good news is that my liver looks OK. The bad news is that the cancer has reached my lungs and possibly the pelvis bone. Chemotherapy started again last Monday.

As you can imagine, I have a lot on my mind right now. Two things keep popping into my head though: bacteria under rocks in Antarctica and a quote by Steve Jobs. I keep thinking of the first thing because it reminds me that, no matter how harsh the circumstances, life finds a way to survive. The quote by Steve is equally interesting: “We’re here to make a dent”. My job in this lifetime is far from done so I plan being around for a long time yet.

While building a GUI application is pretty easy these days, designing a good one remains a difficult problem. It took many years before I found GUI emails clients more productive than pine and just as long before programming in an IDE was more productive than the best editors around. As a dedicated fan/developer of Bazaar, I’ve spent most of the last few years being a command-line junkie. In recent weeks though, I’ve started up a project that aims to change that: Bazaar Explorer.

Bazaar Explorer is a cross-platform desktop application that runs on Windows, GNOME, KDE and OS X. It doesn’t try to be a poor implementation of a file manager or a brain-dead IDE. Instead, it focuses on version control stuff: managing branches, managing changes and collaboration. While it’s not cooked enough yet for me to completely abandon the command line, it’s coming along nicely and is proving just as productive, if not more so, for some common version control tasks. Here’s a brief introduction by pictures.

On start-up, a Welcome page is presented if a location isn’t specified:

As shown above, I’ve created bookmarks to several of the repositories I have on my PC, one repository per project. I also have some bookmarks that navigate straight to commonly accessed branches. (”core” is the core Bazaar project btw.)

Double-clicking on a repository opens the repository view:

At the top are the branches (and other objects) nested inside the repository. Below that are details about the currently selected object. Double-clicking on a branch opens it:

This gives a status report on the current working tree: any conflicts found, what’s new, what’s changed, etc. From the report, you can click on a file to open it in your editor or see the per-file diff. The full diff, together with a heap of other branch operations, is available by clicking on the relevant toolbar button.

Easy access to Bazaar’s various configuration files is provided by the Settings menu:

Furthermore, you can define your own tools and launch them from the Tools menu. In Explorer, a tool is either a special bzr command (like lp-open or pqm-submit), a local application (like KCacheGrind or Qt Designer) or a web site.

Explorer recognises that many users have different needs at different times: one open source project vs another, work vs home, one client vs another, advanced user vs trainer, etc. As such, you can create, download and switch “hats” – collections of tools and bookmarks you want to use together.

Even better than defining your own tools is reusing a set of tools that someone else has already put together! If you’re a core developer or team leader on a project, you can define a hat for others to use and include links to all the important websites they’ll need: the issue tracker, wiki, build server, qa results, etc. That ought to mean less ramp up time for new contributors on open source projects or new staff on in-house projects. See http://bazaar-vcs.org/BzrExplorer/Hats for details.

In summary, I think Bazaar Explorer is pretty cool. For a weekend project that only started in June, I’m blown away by how quickly it’s come together. I can thank the combination of cool technology (Python, Qt, bzrlib, QBzr, bzr-gtk) and keen early adopters for that. A special thanks goes to Alexander Belchenko who has helped heaps, removing bugs almost as quickly as I’ve put them in. If you haven’t already, please give Bazaar Explorer a try. If you like it, please consider translating it to your native language and/or joining the Bazaar Explorer Developers team. We’d love to have more developers on board, particularly if you’re a KDE or OS X user.

I’m pleased to announce a new project that aims to extend Agile software development with successful practices used in the Open Source community. The goal is to create and support a process framework that teams and communities, both open source and commercial, can download and customize to meet their needs.

To start the ball rolling, I’m pleased to announce the Manifesto for Community-Agile Software Guidance. Anyone can sign this - simply go to the page and add a comment indicating that you agree! More importantly, a paper explaining the values, principles and practices is available in numerous formats including html and pdf. (I was planning to present this paper at OSCON 2008 but unfortunately can’t travel at this time.)

To get involved, visit https://launchpad.net/~community-agile and join the team!

Exactly two weeks ago, I received some bad news which will undoubtedly change my life - I have bowel cancer. At 41, I’m much too young to die and I’m pleased to say that I’m not likely to in the near future. Even so, I’m in for several months of treatment, surgery and recovery. Nothing like a wake-up call like that to trigger re-assessing one’s priorities in life!

When I started this blog in 2007, I explicitly made the decision to focus it on professional topics and avoid making it about life in general. I gave it the title Agile Teams, Open Software, Passionate Users .. Life is too short for anything else. You can tell it’s not about life in general because I left Good Wine out of the title. There are times like now though when separating professional from personal just doesn’t make any sense. We simply spend such a large percentage of our waking hours working that happiness at work is directly related to personal happiness for many of us, and good personal health directly impacts our productivity and relationships at work.

In my case, I’m extremely lucky to be doing the work I do at Canonical. It’s something I feel deeply passionate about: making it easier to produce great software more efficiently. I also have the privilege of working with a bunch of really smart people and I learn something new from them each and every week, if not every day.

My family and I have been overwhelmed by the amount of support everyone has offered. Almost every one we know has contacted us on hearing the news asking what they can do to help. I’m writing this article because I want to let people know, regardless of where they live, that they can help. Here’s how:

1. Don’t take your health for granted like I did. Early detection of many diseases in the only real defence so go and get those tests done you’re been putting off because you feel fine.
2. Do something you enjoy and do it well. Life truly is too short to be working in a job you hate or to be wasting time using unproductive processes and tools. (If you use a computer, try Ubuntu. If you develop software, try Bazaar.)
3. Take care of the people close to you.

We live in a society where talking about one’s butt simply isn’t done - no-one ever goes to the toilet in any novel I’ve ever read! It’s not easy telling people that I have rectal cancer, but it’s common and often fatal. If sharing my story means other people catch it or another disease sooner, then I’m pleased to have done it.

I’m presenting a paper later this year at OSDC 2007 on why distributed version control matters and how to implement it effectively. A draft can be found online here: Distributed Version Control - Why and How. If anyone has any feedback, please let me know soon so I can improve the final version.

Can you name a single successful software product where more resources (time and money) were spend on developing it than integrating it with other products and systems? I don’t believe such software products exist. Is that likely to change? If not, what can we do about it as software developers? And what does that mean for those of us interested in streamlining how developers work in general and delivering better version control tools in particular?

#5 on my list of criteria for evaluating version control tools is Integration. Software exists to get things done and it rarely, if ever, exists in isolation. The more successful software is, the more pressure there is to integrate it with other tools and systems. I believe lack of mature integration with other systems will be the #1 reason for many teams delaying their move from a central VCS tool (like CVS and SVN) to a distributed VCS tool (like Bazaar, Git or Mercurial) in the next 12 months. The good news is that the new breed of VCS tools all do a lot right in terms of enabling integration but we need to do much more. Firstly, we could and ought to be doing more at the core of the new products. Secondly, we need to get behind the really important integration add-ons and help them reach maturity faster.

At the core product level, Design for Integration comes down to four key things … (more…)

There’s no such thing as the perfect version control tool and there never will be. That’s why extensibility is #4 on my list of evaluation criteria for VCS tools. There will always be pressure on these tools to enable new ways of working, provide more information for decision making and provide smarter integration with other tools. Over and above that, extensibility is really important for both technical and social reasons.

Technically, trying to ship a tool which is all things to all people creates all sorts of problems particularly w.r.t. reliability, my #1 evaluation criteria. Bloatware takes longer to ship each time, quality typically drops regardless, and the extra features don’t necessarily hit the mark anyway. As Mozilla has shown with Firefox and Thunderbird in recent years, it is far better to produce a rock solid core product that supports plug-ins in a documented way. Done right, the result is higher quality, better performance, and extensions that better meet the needs of the user base anyway.

Socially, a plug-in architecture increases the engagement of the community that grows around successful products. Whether open source or commercial, it takes a community to raise great software and plug-ins let that community scratch their itches in a sanctioned way.

There are different ways of tackling the extensibility challenge but the best way in my experience is by explicitly supporting plug-ins as Bazaar and Mercurial do. Other tools like Git have gone down the well worn toolkit path, and while that’s much better than having a monolithic application, I believe the plug-in path is a wiser one for a host of reasons.

(more…)

In earlier posts, I outlined the top 6 criteria that teams ought to consider when investigating and selecting a VCS tool: reliability, adaptability, usability, extensibility, integration and low administration. I’ve just announced the availability of Bazaar 0.18 Release Candidate 1 so now seems a great time to discuss my most important criteria - reliability.

In terms of impact on team success, tools are pretty low in the pecking order of things when compared to clear leadership, motivated people and just right processes. However, the new breed of version control tools are exciting precisely because they change the software development game: they enable new ways of communicating and that in turn enables new ways of thinking about software development. But outside the AlphaGeeks, Distributed Version Control will only reach criteria mass as a technology across the open source world and in commercial software development shops if we can show the technology is ultra-reliable. To me, that means 3 things: Design for Reliability, extensive test suites and strong auditing, e.g. cryptographic signing of commits.

(more…)

So much to read, so little time.

Software technologies - operating systems, applications, programming languages - rapidly evolve, so I find the Web a better choice than buying book after book on something with such a short half life. As Grady Booch says though in his interesting look 50 years into the future (warning: 12.6 MB), software engineering fundamentals never go out of style. The fundamentals are the values, principles and best practices of what we do: Requirements, Architecture, Design, Construction and so on. I keep a list of what I believe are the best books in each of these areas. I hope you find it useful reading as much for what I’ve left out as included. I welcome input on evolving this list as we learn more as a profession on the numerous challenges of software development, operations and support.

Last week, I outlined the criteria I felt were most important in Version Control software and focused on Adaptability. This week, I want to focus on #3 on that list - Usability. What aspects of usability really matter? How can we maximize the chances of building great software that users will love to use? These are important questions relevant to most software teams in my opinion.

Many teams makes the mistake of thinking that usability is primarily about ease of use. Other teams make fast performance their main focus and make compromises accordingly that hurt overall usability. Both ease of use and fast performance are important but the real key to usability is task efficiency.

In the end, users simply want to get things done. Ease of use is important because it lowers the time required to learn software. Easy to use software also assists users complete infrequent tasks (which can be most tasks for casual users). Performance is important because time is a precious commodity in our busy lives and every few minutes - even seconds - count, particularly for power users. However, focusing on these and forgetting task efficiency is a massive mistake, one so large that it almost cost the IT industry its credibility in the business world …

(more…)