Frank Carver's Punch Barrel

Monday was a bank holiday, so I found a little time to catch up with some of the web videos in my queue.

First I watched an inspiring session from TechCrunch Nordic which likens achieving an “exit” for a startup company to dating. Fun, and with a strand of truth.

TechCrunch Nordic – Tommy Ahlers from Mike Butcher on Vimeo.

Anyone running a startup, or thinking about it, should watch this one.

Second I watched a presentation ostensibly about Kanban and “single piece flow”, but really about much wider issues in planning and managing software development. I found the approach presented particularly interesting as it correlates very well with where my thoughts are at right now.

This video is best watched at infoq, to see both the presenters and the slides

Anyone working in software development, or managing a software project really needs to watch this one.

I’m currently on my fourth or fifth project using the Sinatra web framework. Each project has taught me more about Sinatra, and Ruby, and all the other little things that go into making a web application using these tools. One thing which has been puzzling me, though, is how best to structure the directories and files which comprise each project.

I have been developing Java web applications for so long that I have a familiar and generally useful project structure which I can quickly build from memory. With these new tools I’m not so confident that I would not be storing up problems if I attempt to create my own structure.

So I was intrigued to encounter Monk recently. A system for generating project starting points for projects using a lot of the tools I have come to enjoy. It’s presumably aimed at the simplicity of starting a Rails project, but for a different set of tools.

On my Ubuntu system it was a bit tricky to get going. The documentation just recommends “sudo gem install monk” but this required some extra installations and some general fiddling around. Once installed it happily generated a project structure, which (after a few more installs) would run its tests using rake and start up a server serving “Hello, World” if asked.

I’ll give it a try on my next project, and see if it helps. I might even use the recommended No-SQL storage engine Redis instead of Sqlite or PStore which I have used in the past.

Read some more at » Monk – Quickstart Sinatra Projects Gittr.

I have just listened to an excellent podcast interview with Andy Singleton from Assembla in which the discussion ranges around his extreme views on how to run highly productive distributed software teams.

Top tips include “don’t interview when hiring”, “don’t estimate work”, “don’t do conference calls”, etc… Contentious, but very well explained and justified. This podcast is so packed with thoughtful stuff that I’m sure I’ll listen to it again.

Podcast on Managing Distributed Agile Projects

As you may recall from a previous post, I am looking for some decent project hosting both for my open source software and for some business ideas. I want a single point of contact which offers as a minimum: version control, wiki, bug/ticket tracking, calendar and tasks/todo. Nice to haves include time-tracking, collaborative planning and continuous integration.

Eventually I have found two likely candidates: unfuddle and assembla. Both offer most of what I want, but with a few differences.

Unfuddle is probably the simpler of the two. It offers subversion and git hosting, a kind of wiki called “Notebook”, a kind of low-rent bulletin board called “Messages” for discussions, deadline management using simple text milestones, and bugs/tickets using Trac. It also provides RSS and iCal feeds of workspace events and upcoming milestones. With increased monthly payment you can also get time tracking and file attachment storage for messages.

Assembla offers subversion, mercurial and git hosting (and can integrate with remote subversion and github repositories), a wiki with extensions to directly reference tickets, bugs, software versions etc., similar “messages” to unfuddle but with file attachment storage included, bugs/tickets using trac or a proprietary alternative, similar milestones to unfuddle (but I can’t find any iCal feeds which is a shame), time recording, scrum-style progress reporting, and a few other options such as a “chat” facility and a specialist repository for storing and annotating images. It can provide updates of events using twitter or by HTTP call-outs, which seems pretty flexible.

Neither one seems to have a very sophisticated calendar, so no arranging meetings etc. Neither one has any significant collaborative planning in the vein of Mingle or Silver Catalyst. Neither supports recording of anything other than time (money spent on each task would be very useful, for example.) And neither supports continuous integration as such (although it could probably be hacked together using Assembla’s HTTP call-outs.)

Pricing seems roughly similar, although calculated differently.

Unfuddle offers five price bands (free for open source, $9, $24, $49, and $99 per month). Each band offers larger quantities of storage, numbers of participants and projects etc. The $9/month plan offers 512MB of storage for 10 people on 4 projects, so for an example small private team of three developers the cost would be $9/month

Assembla determines pricing per user per “space” (a space seems roughly to equate to a single project). Free for public spaces. For private ones, each user/space is $2/month, and $3 per gigabyte of storage per month. So for the same small private team of three developers the cost would also be $9/month but for more features and more storage. The down side is that adding any new team member, even one who only needs occasional access, costs extra.

I have registered for free accounts on both systems and have started to try out everything I can. I’ll report back soon on my findings.

In the meanwhile I’d love to hear from anyone with any other suggestions for project hosting services along the lines of these two.

An interesting collection of articles. I have read a small number of them, but I’m looking forward to enjoying (or at least complaining about) the rest.

My 10 Favorites Agile Project Management Articles | From the Editor of Methods & Tools.

I’m still searching for decent project hosting. I now have several projects on the go, and several others bumping around in my head, and the fuss and bother of tying together all the various bits of a distributed software project development is making my head hurt.

All the bits I need are available separately, but so far I have not been able to find any single provider (free or paid for) which offers the combination of features I need. Essentially these are:

• Version control. Ideally git, but at a pinch one of the other distributed VCS tools or even subversion would probably do if everything else was in place. GitHub seems good for this.
• A project wiki. Using any other system for project docs just seems so clumsy. There are plenty of these; I use WikiDot for one project.
• Sensible bug/feature tracking. This is a bit more tricky – there is plenty of bug-tracker software, but not much that works equally well for managing unimplemented feature stories and associated tasks. Ideally this should link in with the version control, allowing code and change metadata to be updated in one go. Trac seems a possibility for this.
• Calendar management. For recording and communicating meetings, deadlines etc.. Something which works well with calendar syndication, so that anyone working on the project can see project events in with the rest of their appointments. Plenty of these: Google calendar, 30 boxes, etc. They all have their quirks, though.
• Task (todo) management. I find it amazing that task management is so poor in on-line calendars. There are standalone task tools such as Remember The Milk, but it is integration which is needed.

There are also a few other features which are definitely in the “useful to have” category, but I’m practical enough to use manual or off-line tools if necessary.

• Effort recording, tracking and reporting. For velocity tracking, process improvement, and even billing.
• Collaborative planning and prioritisation. Mingle tries to simulate a task wall, but is somewhat clumsy and irritatingly expensive; I have heard of on-line tools to run “Planning Poker” sessions, but as usual, not integrated with anything else.
• Continuous Integration. I’m not aware of any really smart tools to make use of distributed version control for this, yet. Our Cruise Control installation just stops and complains when something breaks, for example, but it should be possible to just “park” the failing patch and continue building with others in a real dvcs-based approach.

If anyone has any suggestions – or wants to build a product which does all this stuff – please let me know!

For interest, here are a few associated links.

Cuberick: Distribute Your Software Just Like Ubuntu With Launchpad

Comparison of open source software hosting facilities: Wikipedia

We have a large project wall, on which paper/card stories, bugs and tasks progress from submitted through to tested. This is great for a quick view of state, but the physical movement of tokens does not help in tracking and analysing progress.

Akshay Dhavle suggests the use of “finger charts” to get a better and more useful of project progress, in particular to help identify time-related problems.

Business Analysis: Finger Charts

I’ll admit that I don’t have a lot of experience with Python, but one of the things which always gets me in a tangle is project structure, modules, packages, importing and how they all play together. So far I have not found much by way of resources to help newbie Python folks get to grips with “best practice” in this area.

This post looks like it might be helpful, though.

jcalderone: Filesystem structure of a Python project

To make software development work, everyone involved needs a good working knowledge of the product, the domain, the solution and so on. Communicating enough, but not too much, information can be tricky, especially in an agile environment where anything can change at any time.

Tarek Abdelmaguid has an interesting list of ways to communicate while working on a project. I have done almost all of them with various clients and employers, and also made a lot of use of instant messaging. There is definitely scope for using more structured communications such as mailing lists, internal blogs and forums, though.

On Programming and Applications Development: Project Development Knowledge: Sharing and Enduring