Older blog entries for ianclatworthy (starting at number 8)

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…)

The Version Control space is undergoing a renaissance right now thanks to the increasing popularity of Distributed Version Control Systems (DVCS) such as Arch, Bazaar, DARCS, Git, Mercurial, Monotone and SVK. Many really smart people believe these systems have the potential to dramatically change how software is built and I agree with them! But which ones actually will and why? I think the answer to that lies in a closer examination of the criteria teams use to adopt collaboration tools.

Beyond market acceptance, there are 6 main criteria I consider when evaluating collaboration tools:

1. Reliability
2. Adaptability
3. Usability
4. Extensibility
5. Integration
6. Administration (including Total Cost of Ownership)

The order given above is the one I use for version control tools - different collaboration tool categories deserve different orders. Every team is different so the criteria they consider may not be identical, but the ones above are those I’d expect every team to include in their evaluations.

While few people would be surprised to see Reliability at the top, few systems do a really good job of delivering the features that implies, so I plan to return to Reliability in another post. Today though, I want to explain why I think Adaptability is #2, even if that makes me “dumb and stupid” in the eyes of one of my heroes.

If you haven’t seen it already, I recommend watching the Google video of Linus Torvalds talk about Git. He makes a lot of excellent points about the advantages of Distributed VCS. Unfortunately in my mind, he also suggests that anyone using Central VCS tools, particularly CVS and Subversion, is dumb and stupid. I strongly disagree! The future of version control is neither Central nor Distributed - it’s Adaptive. It’s all comes down to the numbers …

(more…)

The most important thing every good engineering manager does is find and employ the right people. The second most important thing he or she does is develop them. It sounds so obvious and simple! In reality though, developing the careers of technical people well is one of the biggest challenges every IT company faces. Whether you’re responsible for managing technical people or simply interested in actively driving your own career, it helps a lot to have a good framework. And the name I’m giving mine is M.E.T.A. - Management, Engineering, Technology and Applications.

Have you ever wondered why open source teams often produce software faster than commercial teams? There are numerous reasons but more M.E.T.A. people is part of the answer. Agile methodologies work well for much the same reason: every team member is encouraged to take an interest and role in planning, tuning processes and using technology to deliver value to users. Having people that can see and balance all these aspects is a truly major win. Products get out the door sooner and quality, in terms of fitness for purpose, is often better as well.

Why is this so? As explained previously, software engineering is ultimately a communications challenge. As a consequence, a bunch of multi-skilled people all on similar wavelengths will win every time over a bunch of specialists each focused on just their part of the problem. Collectively, M.E.T.A represents the 4 pillars of software engineering success. It therefore represents the 4 dimensions every engineering manager needs to be thinking about when developing their staff.

So what does the M.E.T.A. model look like in more detail and how do the pillars interact?

(more…)

What’s the secret to developing and releasing great software that people love to use? That’s a question I’ve been fascinated by now for almost 25 years. I don’t pretend to have the answer but I do have some clear opinions after all that time on many of the necessary ingredients: clear leadership, motivated people, effective processes, great technology and tools.

If those things interest you as much as they do me, then there is no more exciting place in the world to be working right now than the open source community and in particular my employer for 3 months, Canonical. Canonical are best known as being the commercial sponsor of Ubuntu, the Linux distribution that could. But Canonical is exciting for reasons far bigger than Ubuntu …

(more…)