This post is something of a companion piece to our project manager, Rob Baxter’s post “The time is gone, the song is over“, where I give some final thoughts from my point-of-view as lead developer.
Firstly, I must say that this was a very enjoyable project and I’m sad that it has come to an end — there is still a lot I’d like to do and I firmly believe the Workbench has the potential to become a useful tool to a lot of developers in data-oriented projects.
The usability reviews by our resident usability expert Mike Jackson formed the backbone of the project, providing us with both a focus and an objective way of measuring and evaluating progress. Whilst similar could be said for the code reviews, the usability reviews provided a much more visible sense of progress that had a immediate impact. Despite this, I believe the code review was essential in revealing the extent of the technical issues in the project that need to be tackled in the long-term to have a truly maintainable and robust piece of software.
This was the first project that I’ve worked on where we were expected to write a regular blog. I’m quite a keen reader of software blogs, so I relished the chance to add a few words to the general blogosphere at the same time as keeping everyone up-to-date with progress on the project. I took the opportunity to write some posts on generic software development issues (such as On Code Quality) as well as providing specific advice to developers using certain technologies (such as this post on Graphiti) in addition to project updates. The more generic posts I submitted to news sites such as Reddit, which resulted in quite a few readers and comments. It pays to have a thick skin if you go down this road — most blog posts will attract more criticism than praise! Whether or not you go the news site route, I strongly recommend the blog approach to other teams as it is an excellent way of attracting new visitors to your site, making progress visible and keeping new and existing users up-to-date with news. The major disadvantage is that a largish blog-post will take most of a day to write, especially if you take the wise route of getting feedback and re-drafting before publishing. A nice alternative to a blog post is a short screencast, which if you have the right software (we used camtasia) is quick to produce and appealing to visitors. I still hope to find time to produce a final screencast showing the current workbench.
Picture by Jeff Kubina
My post On Code Quality arguably set myself standard that I was unable to live up to. Whilst I was aware that I wouldn’t have time to fix a lot of the existing issues, even entirely new parts of the workbench failed to live up to my guidelines in some respects, most notably in testing. Testing was a particularly thorny issue for the project as it is largely GUI based. Normally I would aim to follow an MVC (or similiar, e.g. MVP) approach and just test the model, relying on manual testing for the strictly GUI parts. This proved difficult with the Graphiti library used to build the new Graphical editor and I found the best approach was to use SWTBot to drive the testing. However, even with this tool, the process was difficult and frustrating. The maxim that unit testing should save you time was certainly not working here – it took much longer to figure out how to write tests for the code than it did to write the code itself, which forced me to the decision to forgo a lot of testing in return for continued progress on tracker items. Regardless of this, I am convinced that the software is more maintainable than it was at the start of the project (the move to Graphiti was a significant gain here).
Given more time to spend on the project, I would focus on creating more documentation for users, improving the usability of the various visualisers and trying to make the codebase considerably more maintainable.
Finally, the main goal of the project — the creation of the VM — offers a great way for users to easily investigate and play with the OGSA-DAI technology (even if it does way in at a hefty 2.2GB download!). Other projects with complicated or distributed architectures may well want to consider a similar approach.
Thanks to Rob, Mike and JISC for a great project!