“Agile” software development states you should try and get software out in front of people as soon as possible. Specifications are just documents, software is real - and you can’t get feedback, see what works or improve until what you have is out in the real world. 37Signals, creators of Ruby on Rails and Basecamp, call this the “Race to Running Software“. They even went as far as to launch Basecamp with no billing capabilities - using the 30-day period post-launch to add it in time for invoice day.

For the most part, I agree. Specifications are a dream, not reality. Paying customers pinpoint the important issues much more accurately than the development team. Working in small iterations means you always know where you are.

But it does have its downside - as experienced by the Northcrew at the moment. For as soon as you launch, you become public property. And if you are a success, as Northpack undoubtedly is, the public immediately wants a piece of you. “What are your plans?“, “Why doesn’t X do Y?“, “What about ownership issues?“, “What’s in it for me?” - all get thrown at you. And, having concentrated solely on getting something out of the door, this barrage must feel pretty overwhelming. Especially when it’s something done in your spare time, that costs you money and is given away for free (in Northpack’s case).

To be honest, I’m not sure what the answer is - you have to focus on the next stage, otherwise you don’t have a product. But you need to be prepared for three or four stages ahead or the barrage will drag you down. This becomes even more important if this is a commercial service - if you are taking people’s money they need to know what they will be getting for it. However, I’m not sure how divide your time between the very real needs of now and the potential needs of the future. Any ideas?

“Cyclists Racing” by sritenou.

In this day and age the conference call is a fact of life. It may no longer be on the telephone - Skype, VOIP and iChat have seen to that - but a group of geographically disparate people trying to speak without any visual contact is an increasingly common way of doing business. And it has to be said that nothing beats face-to-face contact for getting your point across and getting things done.

Given that, how can you ensure that your conference calls aren’t a massive waste of time?

1. Always treat your call as a meeting
2. Publish an agenda
3. Shut down your email client
4. Shut down your IM client
5. Switch off your phone
6. Start early

Treat the call as a meeting - cos that’s what it is. Yeah, you can’t see their faces and they can’t see you flicking the Vs at the phone but it is a meeting and, if you don’t want it to be a waste of your time, treat it as such.

Publish an agenda - like any meeting you don’t want it to drag on or go off at a tangent. So publish an agenda, circulate it beforehand and, if you can, stick a time limit on each item.

No Email, No IM - they can’t see you and you can see the “unread count” going up and up. It won’t do any harm will it? Well it will. You’re not paying attention and it’s rude. One trick with IM - if you know your attendees addresses you can see their status. Are they online or offline? If they are online are they “available” or “busy”?

Switch off your mobile - Much the same as above - you’re in a meeting, so it’s rude to allow interruptions.

Start Early - I admit it. I’m crap at turning up on time; but most conference calls are in my office (a handy one minute walk from my bed). So even I have no excuse for turning up late. Instead get started a couple of minutes early. Everyone always takes a while shuffling their papers, reading the agenda (you did circulate it didn’t you?) and making smalltalk. So get that out of the way so you can start at 10 on the dot. And get the whole shebang over and done with.

Conference calls will never come close to the effectiveness of a real meeting. But, given that yesterday I spent 7 hours travelling 100 miles (thank you Network Rail), if you can make them work, they are essential to running your business.

Oh, and lastly, if you have the option, choose iChat over Skype. For whatever reason the sound quality is vastly superior.

Normally I wouldn’t talk about Ruby on Rails on this blog. That geek talk is found on the tech blog instead.

But, despite being about Rails, this isn’t a tech post. It’s about a problem that you will face when trying to hire a Rails developer.

Rails has a number of advantages.

• It is a framework that gives you a massive head-start when building database-driven web sites.
• It is designed to make programming fun. Meaning that the developers shoot through the work with a smile on their faces (rather than scowling and procrastinating).
• It is opinionated and works much better if you follow the “Rails way” - that is a set of patterns and styles that are generally accepted as best practice within software development.

It is the last point that causes the problems.

You see, software development is still a relatively young industry. It is a craft, not a science. There are some who regard it as an art, maybe even a dark art. A lot of software development goes over budget simply because the staff are discovering new ways to do things - and you can’t budget for the unexpected.

But things are changing. Rails is proof of that. There is forty years of case history on the best way to solve certain kinds of problem. Most “business” applications are all about storing, retrieving and presenting information as easily as possible. The tricky, unknown, bit comes when you want to manipulate that data - but the majority usage is simple storage, retrieval and presentation.

And that is why Rails is great - it is designed to standardise storage, retrieval and presentation. It has rules that you should follow - and if you do your code will be elegant, reliable and on-budget.

The difficulty is knowing about those rules and why you should follow them. And herein lies the problem. When I discovered Rails (in the middle of 2005) it was a breath of fresh air. An environment that was about following the rules that we all knew we should, but never did. That actually made it easy to follow software-engineering-best-practice. That assumed you knew what you wanted to do and helped you do it. But the key was that I already knew the rules and why they were important, which in turn came because I had years of study and experience within my field.

If you hire a Rails developer tomorrow, how do you know that they understand those rules? Anyone can learn to program in Ruby - it’s a pretty easy language to learn. Anyone can knock together a few sites in Rails - it’s designed to get you started quickly. But do they know that your application logic belongs in models and not controllers? Do they know why your application logic belongs in models and not controllers? Don’t worry - you don’t need to know about models and controllers - that’s your geek’s job. However, if they can’t give a decent answer to either of those questions, they’re not a proper Rails developer. And you probably don’t know which questions to ask, let alone how to evaluate their answers.

Well, I have been using Rails, on commercial projects, for years now. The ideas behind it are second nature to me. I have seen how inexperienced developers can make a mess of a decent project yet still charge massive fees. I have seen how a project can take a wrong turn, when a simple explanation can change things for the better. How asking the right questions and looking in the right places can point you in the right direction.

So, if you are unsure of how your project is progressing, if you need to evaluate what your developers have produced, if your team is looking for guidance and if you want a series of specific recommendations for improvement then (although I am still finalising the exact details of the service) feel free to contact me today for more information on how 3hv can help. And, if you’re not quite ready, why not subscribe to make sure you stay up to date.

Update: You can read more about how this service works on the tech blog.
Photo: “Wondering” by bigevil600.

rake db:fixtures:load is probably one of the most useful commands I have used recently.

You see, I was meeting some people about some potential work. They wanted to see an example - preferably related to payment systems. I had some code but unfortunately, the service that is part of had been switched off (a number of reasons, none of which connected to my supreme stylings). I had a copy of said code on my machine, but no database and I had no time to prepare.

So how could I demo it? Easy peasy.

cd ~/Source/my_apprake db:migraterake db:fixtures:loadruby script/server

And then start Camino.

Because the application had been developed test-first I knew that there was a decent set of data within those fixtures. Data designed to show all the edge cases, all the complexities of the application. From users and logins through to payment records and customers.

It is fair to say that when writing your applications, test-first, the fixtures are the hardest thing. It can take ages and it is detailed, painstaking work. Especially if you are trying to build a narrative (:dave logs in, selects a :cucumber, goes to the :checkout, pays with his :expired_credit_card which is rejected).

But the benefit is there. Building a narrative helps you when you come back to the code in six months time. Defining a wide-range of test fixtures helps you when you make changes and need to ensure that it won’t break a feature over there. And it helps you demo your code in front of a prospective client when faced with the unexpected.

Data Highway by KLatham.

I’m just thinking out loud here - based on stuff I’ve done well in the past. But this is no rigorous scientific method - just a set of notes for me to refer back to.

* Write a couple of paragraphs describing the application. Note down keywords (especially important nouns and verbs) and maybe a “what, who, why and how” type analysis (when and where may or may not be applicable, depending upon the application).
* Show this to other people and get their feedback.
* Sketch out the UI. On paper, with a 6B pencil and an eraser, or on a whiteboard, with a camera. Do a flowchart for each of your major tasks (look at the verbs from before) and then a quick sketch of the pages involved. As you sketch out the pages you will probably find that you need to change the flowcharts. Think long and hard about it and then change if you must.
* Show this to other people and get their feedback.
* Create a new project and add it into subversion.
* Take your flowcharts and decide which controllers will be involved in each task. [I’m not sure about this point - but I reckon you probably don’t want a single controller to be involved in more than one task - however each task will probably require many controllers].
* Generate the controllers and then use them to create static HTML/CSS mockups of your UI. The only “active” portion of these mockups should be links navigating through the task. As you do the mockups you will probably think of new functionality - add these to your flowchart immediately - if it becomes apparent when you have actual pages in front of you it’s probably valid (as opposed to the “up in the air” additions above).
* Get your mockups to respond to a parameter: mockup_style; if this is blank then show the page, if this is “empty” then show the “blank slate” page, if this is “error” then show the “error” page. In other words, think about how it looks in those three important states up-front.
* Show these mockups to people and get their feedback.
* Write functional tests for your controllers. Deal with things like showing the blank slate page when there is no data to display (I like to use assert_select to search for a div called “whatever_blank_slate”).
* Dealing with each controller in turn, get the functional tests to pass. In order to do this, you will probably have to create models. As you create the model add unit tests and test fixtures - and then use these to make the functional tests actually work with real data in a real database.
* Do the bare minimum to the models, fixtures and unit tests to get the functional tests to pass. Even if you know the next controller will need a new method adding to the model, don’t add it in early. You never know - your boss may change his mind and decide that that function is not needed (or more likely, can wait till version 1.1) - in which case, why make things complicated before it is needed?
* Whenever you find yourself writing code that is similar to code elsewhere within the project stop and refactor it into a helper, a method on the controller, a base (inheritance) model class or a mixin module. Don’t Repeat Yourself.
* Related to the above, put business functionality into the models (unit tested) - for example if your view needs to show the last four invoices but one, add a method to your customer class called “last_four_invoices_but_one”. Don’t get your controller to grab all the invoices and slice the array itself.
* Once all your functional test passes, run the app in at least two (preferably three) browsers. In theory, if your functional tests are any good, you should see pretty much a working task. Any bugs you find should be reproduced in the tests, if at all possible, and then fixed.
* Show this to people and get their feedback.
* Refactor your controller and models to tidy them up. Remember you have very high test coverage so you should not break anything without being alerted to the problem.
* Move on to the next functional test.
* When they are all done - you should have a working application!
* When the inevitable changes requests come in, you should have full coverage of unit and functional tests, making change management easier than it would be without those tests.

As I say this is thinking out loud - I’ve never done all of these at the same time - but I’m certainly planning on following this process on one of my own projects in the near future.

Gears by csotelo.