Beyond the Button

Flash camp

I attended mn.swf camp. This event was an all-day "Flash camp," held in Minneapolis (organized by the Minnesota Flash/Flex programmer's group and presented by Flashbelt.)

There were about a dozen presentations, mostly focused on using Flex and AIR – two software packages that are positively dreamy for museum interactive developers.

Presentations about slowing down

Two lectures about process struck me. These are rooted in standard software development. One presenter, who talked a lot about ‘tips and techniques’ for developers was Jason Grey. Another presenter talking about 'slowing down' (Danny Patterson, one of the authors of Advanced ActionScript 3 with Design Patterns.) Both talked about the benefits of slowing down, and how developers can push back against the development process to enable a better development process. The rest of this entry will discuss techniques presented by both presenters about how to 'slow down' the development process. A lot of the techniques may be standard for managers -- but are filtered by my perspective of a museum multimedia developer.

The tips

Usually, in the development process, the idea of slowing down is very foreign (especially in the museum world…since it is already pretty slow as it is - and we are always trying to catch up with mainstream media expectations.) It is also a threatening and scary idea to tell project managers that you need to go slower – or to offer a bid on a contract job that is extra long, worrying that you might not get the bid on a project that is super-cool.

Some qualities of a good developer

Patterson dispelled the myth that a fast developer is a good developer – it is possible that a good developer could be fast – but a good developer will also have the qualities of being thorough, conscious (making plans), analytical. The ability to work quickly is then a result of that process of being thoughtful.

A better arc for a project

He discusses the idea of ‘project velocity’ – which he knows well as someone who has a lot of experience in software engineering. He says that project managers have an idea that the development process starts at the beginning, and works steadily to completion finishing perfectly at the end. He says that in reality, the last 5% takes 95% of the time working with that model. (True!)

He says that when the development starts slowing down – the symptoms of a project manager having mismatched expectations about how a project should proceed appear. These symptoms usually take the form of continuous daily meetings “Are you done yet? Are you done yet? Why are you taking so long?” – and really, all the harder stuff falls at this point: the documentation, maintenance, server configurations..and more!

This is a very bad model. The result is that developers, who are tired already, are basically getting the last ounces of strength beaten wrung from them, they start hearing about what’s coming up next, and how they have to deal with all the testing. It’s a very bad time and people just want the project to be over with.

Instead, Patterson presents a different idea – that develop follow a gentler progression to start, and build lightly through the production phase, until near the very end when you can build momentum. (Perhaps this is also rooted in a family of management practices? Well, I don’t know. I’m a developer.)

Plan a lot more, make the end of the project easier so it can be more positive

To achieve this, he proposes this model of development.

1. Planning
People sit far away from the computers. They develop clear formal specifications for the project. What will it do? What are we all expecting? Do we have everything we need?
As a tool for planning any programs one might write, he recommends UML – the unified modeling language created for software engineering…which is a way to diagram parts of a program.

Get the hard stuff over with first
Patterson recommends getting the documentation over with first...because otherwise you are four times less likely to ever do it (he cited a study about this.)

Will too much planning conflict with our plans to do agile development?
When discussing this practice with some colleagues, we wondered if this model conflicts with the idea of agile development. Probably not -- if you use agile development as a planning tool, or if you have some good habits of working even within your agile development. I can certainly benefit from both models of working.

Also, this does NOT mean that having clear plans takes years to work out every little last detail until it's perfect. You can have a clear small chunk of a specification to get started with - and then go about your normal iterative design process.

Here's my list of some problem areas for large institutions trying to get 'innovative' with technology:

• Your organization needs to support this work
• Developers should not have to bear the brunt this responsibility
• Your staff will need training. Time needs to be set aside for experimentation and working on the 'shop'
• Don't make your developers compete for the fun projects Causing developers to feel like they have to compete to get to do the fun stuff will force them into competitive situations - where some will win, and others will become disengaged.
• Establish a community of quality work Allowing anyone to get away with crappy work will give everyone else a reason to not bother to do everything they ought to do. Also, if work is shared -- one project full of hacks will allow others to hack that project...and it will quickly get messy.
• Don't skip clean up. If you develop, you should make time to clean up your code, fix your comments, fix ‘kludges’, ‘refactor’ your code (meaning, break it up, or completely re-write it in order to avoid ‘code smell’)
• Don't skip documentation. you should write out full documentation from the very beginning, and be building to the documentation and not the other way around.
• Don't skip testing. Developers can plan to write out all the ways in which your product can break. They can learn about real testing scenarios. If your developers have no access to fresh testers, you can really help them to find those people. In my experience, there are super formal testing...which is part of evaluation usually -- but then there is just functional testing for which most people need reminding.
• Don't skip evaluation. This one is pretty well vetted in the museum world.
• Don't skip automation. You can and should investigate automation tools…for your file transfers, file formatting, tests, archiving – anything you can. That time will be well spent because it makes your documentation more robust.

2. Development: In this phase, work doesn’t go very fast, but it is building slowly.

3. Alpha: before Alpha testing, momentum starts building. Parts of the project start coming together, you start getting feedback…you’ve done all the hard work already and this gives you the ability to have enthusiasm about your project. This momentum gets you through your testing and evaluation phases.

4. Beta: The momentum is still going. Patterson’s main note about this part of the process is that any changes you make have to be RE-tested.

Some notes for developers

Both presenters gave a few tips for developers wanting to push back and make their work environment more sane. These are pretty similar to guidelines for contractors…but worth revisiting in the light of the museum world.

• Always ask for a full formal specification. This is typical in contracting jobs – because you need a legal document to refer to about what you are supposed to build.
  But how do you apply this in the crazy non-profit world of museums? What if you work in a situation where you are designing new things, don’t know what you are going to be making, or are trying to respond quickly. The presenters did not discuss this, but the essence of what they are saying is that you can really benefit by that sit-down process, especially if you love to get your hands dirty, or notice that you are mired down making zillions of quick fixes to 20 different projects. That time to reflect might just help you decide your priorities, or whether or not the fix you were planning is really a fix at all.
• Work on your estimates. The other big tip that he gives is that you should try to not set a bad precedent for yourself of giving overly short estimates, or trying to out-compete your beloved colleagues by offering to do something faster. Before you freak out about that one, he advises this: it’s better in the long run. When he hires people, he checks to see that they don’t cut corners. Employers who think faster is better...well, are they going to be very good employers who help you grow to your real potential? And anyways…why are they cutting corners?

  So build in to your estimates all of the time you will need to fulfill a project according to the full development process. So, if you can never find time to clean up after yourself…add that in. If you don’t have time to think about roles and responsibilities, commenting, documenting, testing, evaluating…budget and estimate for all of that.

  Some coding recommendations:

  • Invite co-workers to your desk to check out your code.
  • Have 'clean up day' and have someone go over all the code
  • Set up a system to call out people on things that they didn't fix that week.

  Books for inspiration and information

  Refactoring: Improving the Design of Existing Code by Martin Fowler

  Code Complete: A Practical Handbook of Software Construction by Steve McConnell