Frank Carver's Punch Barrel

I know this article was written back in October, but I can’t believe that nobody has pointed out its flaws. No Scott, measuring “acceleration” is not the same as measuring delivery of value!

IBM developerWorks : Blogs : Agility@Scale: Strategies for Scaling Agile Software Development

Scott Ambler, an author who I generally have a lot of time for seems to have completely lost it in an article at IBM developerworks. In this article he goes to some lengths to justify measuring teams on “acceleration” (in effect, measuring the proportional increase in story points processed per iteration) and thereby assessing their value. While this may have some merit, the article insists on contrasting it against other methods of attempting to measure actual productivity.

Unfortunately such a comparison does not make sense.

• A high-accelaration team may be worse over time than a low-acceleration team, if their starting productivity is less.
• A high-accelaration team may be worse over time than a low-acceleration team, if their maximum productivity is less.
• Ambler’s analysis assumes that the entire surrounding process is constant, including task estimation. This is very unlikely

Fundamentally Acceleration and speed are quite different things. I can wait at the lights on my pushbike and burn off nearby cars, because of my higher acceleration, but fifty feet later they will overtake me and carry much more stuff a much further distance.

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.

1. Remember to breathe. You’ve probably worked for two years to get to this moment, and there’s no guarantee you’ll ever get to do it again. You might as well enjoy it.

2. The computer is a Buddha. It sees the world as it is and does exactly what you tell it. It doesn’t implement your expectations or your fantasies. Try to see as the computer sees.

3. No design survives contact with the users. Research, analyse, test and prepare. Then be ready to throw it all away when real users don’t do it like that.

4. A good idea can come from anywhere. You might as well listen to what others have to say because you’re going to get the credit (and blame) anyway. Your programmers, salesmen, accountants, admin folks, project managers, cleaners and so on have probably used a wider range of software than you have even heard of. Joel Spolsky calls this “hallway usability testing”

5. Life is messy. It doesn’t stop while you’re talking on the telephone. If it feels too comfortable, it’s probably wrong; if it feels right it’s probably too slow.

6. No software can ever be simple enough. Surgeons, cops and priests have a lot on their minds, but they still need your software to work right.

7. A user’s attention span is even shorter than yours. Give them something useful, valuable, compelling and obvious everywhere, all the time. As Steve Krug puts it, “Don’t make me think”!

8. The users define the software, the software doesn’t define the users. Unless you have a style, don’t act as if you do.

9. Make your software for one person at a time. Imagine your fourth grade teacher sitting alone in the dark.

10. Where there is no solution there is no problem. At some point in every project, the company management loses faith in the product and the employees loses faith in the company management. Somehow it all works out.

If you are more interested in making movies, see the original at: Ed Zwick’s Golden Moviemaking Rules | MovieMaker Magazine.

In my dark moments I worry about the security of cloud computing. I used to be pretty upbeat about security, until some servers I was using to run a small specialist java hosting business were hacked. This resulted in the collapse of that business and the loss of several customer sites. Since then I have been painfully aware of the need to keep any public system scrupulously up-to-date with security patches and suchlike.

My security worries give me concerns about launching a business based on Amazon’s EC2, as I cannot see at the moment how the fiddly details of keeping the virtual system images patched an up to date will happen. Please feel free to reassure me!

When I read the title of this article from the Java Developer’s Journal, this was my immediate thought. The article does not address this particular issue, but instead covers some of the problems of protecting data in transit between distributed systems.

This article really helps join the dots for a project I’m thinking about a lot at the moment.

Connecting Apple’s iPhone to Google’s cloud computing offerings.

I’ve still not got fully up to speed on using Amazon’s cloud services, but this looks useful. A whole bunch of code examples and libraries for a variety of languages

Amazon Web Services Developer Community : Amazon SimpleDB.

This is an interesting thought.  Some commentators seem to think it’s not feasible, but I’m not so sure.  Just take a look at the street prices of MP3 players, mobile phones, and handheld computers such as the Nintendo DS. All of these have CPU, RAM, screens, batteries etc.

India to Unveil $10 Laptop | JAVA Developer’s Journal.

A collection of useful links and tutorials about using the git version control system.

GIT 101 | Xebia Blog

Jason Yip from Thoughtworks has a nice summary of points to remember when organising or managing stand-up meetings.

You’d think with all my video game experience that I’d be more prepared for this: A quick summary of how I like do stand-ups

No database schema or default dataset is ever perfect, things always change as software evolves. It can become tricky to ensure that each deployed version of a system gets the right database configuration. At present in our project we attach a growing list of “roll forward” and “roll backward” scripts to each project, and rely on whoever does the deployment to make sure that the correct set of scripts is run before the application is started.

Always in the back of our minds is the search for a more robust and automatic solution. It looks like “LiquiBase” might be such a solution.

home [LiquiBase]