10 reasons to get started with bug and issue management today

1. Build self-documenting projects.
2. Integrate issue tracking with your source control management system (you are using version control right?)
3. Help shape a clear development roadmap.
4. Increase development process transparency.
5. Prioritize important tasks.
6. Distill tasks into bite size portions any team member can tackle; dip in and out of projects.
7. Plan your day around multiple projects.
8. Gather feature requests in one place.
9. Identify your critical path; anticipate project holdups or delays.
10. Closing bugs just feels too good not to…

To get started I suggest you check out redmine if you’re a Ruby person (it’s what I use) or trac if you feel more comfortable with Python.

Presenting Rails for Flash at LFPUG

As usual, the London Flash Platform User Group event will be held on the last Thursday of the month; that’s this Thursday, October the 30th.

First up this month are the guys at Unit9, they’ll be taking you through their processes and how they keep everyone in the company communicating effectively for maximum result.

I will be following up with a presentation on Ruby on Rails and Flash; taking you through the steps needed to create a REST-ful Rails application that is read and writeable through a Flash Front end. This will give you an introduction to Ruby on Rails and how this powerful web application framework can make it ridiculously easy for you to kick-start your next, or first, database powered Flash application.

The LFPUG will be held at it’s usual location, Cosmobar on Clerkenwell Road (54-56) and the presentations start at 19:00. For more information on the sessions, and indeed on how to get there, see the official LFPUG site.

See you there!

Getting Real with Web Apps

I recently finished the 37Signals book entitled “Getting Real: The smarter, faster, easier way to build successful web applications” and it looks like 37signals have hit the nail on the head with this short and concise guide to building web applications. I read it in one sitting after flipping through a couple of the pages and getting hooked.

The cover of ‘Getting Real’

For those that don’t know, 37signals is pretty much the darling of the web2.0 application development companies. For a start, 37signals developed the wildly successful Ruby on Rails web application framework while building applications like BaseCamp, Campfire and Backpack. One things for sure, these guys know how to build a web app; and it shows when you read ‘Getting Real.’

‘Getting Real’ won’t show you how to build that trendy tag cloud, mash-it-up with an eternal api, or anything else about the specifics of building a web app. What it will do is put you in the right frame of mind to make it a success. The great thing about this kind of book is that it works for lots of different types of people: designers, developers, project managers and project planners.
As the title suggests,’Getting Real’ is a book with a healthy dose of reality: You’re building this app for real people, remember?
The first few chapters will help you put your app on a crash course diet, stripping it down to its most fundamental core. It helps you translate your idea into a number of real goals which will help you get something out in the wild as soon as possible.
The whole philosophy of ‘Getting Real’ becomes apparent, even when you read the index page. It could put you on the right track even if you never the read the rest of the book (I’m quite sure you will though.) It’s pretty obvious the 37signals crew have brought their web app philosophy with them when they started writing this book.

If you’re planning a web based application, or are knee-deep in production already, then one things for sure: you need to get this book.

Being the fine folks that they are, 37signals are offering an on-line version for free at http://gettingreal.37signals.com/toc.php. I highly suggest you fork out for the paperback though; its well worth it.

The importance of the first crumb

If you’ve ever worked on more than a handful of projects, I can heartily recommend taking a little time after each to leave behind a bit of contextual information relating to that project; the first crumb in the breadtrail if you will.

Now many of you may already be doing a good job of commenting your code, but with multiple class files in package structures, you can never assume anything will be read, especially comments. Basically it’s not enough to just comment your code, unless you plan on getting reacquainted with each project, every time you need to modify it.

To counter this, I’ve been leaving behind a trail of readme.txt files with little notes and out-of-the-ordinary contextual information; stuff you need to know before you even think about making changes by diving straight in. These little bits of information seem trivial when you’re actually working on the project, but a couple of months down the line you’ll be pretty pleased you managed to have the foresight to include them.
This morning I came across a readme.txt I had left behind about 3 months ago. I don’t even remember writing it anymore, but the information I found within jolted my memory and helped me make changes to the project as quickly and effectively as possible.

So start today and make yourself a readme text file, 5 months down the line you’ll be pretty chuffed you did.