threehv

Google’s Chrome browser is making big waves on the Internet. “Watch out Microsoft, Google is coming to get you” they are saying.

But they are wrong.

Mozilla should be worried. Even Apple should be worried. But Microsoft should not.

You see, if Chrome is successful it will take search revenue (from the little online search box) that Google pays to Mozilla and Apple every time you click on an advert (as opposed to a search result).

But that’s not Google’s aim.

Their aim is “fire and move”.

Just as Microsoft prepares an assault on Google’s search and advertising business, Google distracts them with an assault on the Windows desktop. A classic Microsoft ploy (see the Win16 API, the Win32 API, the .Net API) turned against them.

So, how do you respond to fire and move? Well, that’s the real question.

It’s not your technical ability.  That’s a given, otherwise you wouldn’t be in this job would you?

It’s not finding a push-over client.  The client is busy and has their own problems to solve.  

It’s a combination of organisation, management and communication.  

Stay organised.  Always know what is outstanding, who is doing it and when it will be done.  

Manage your client.  Software projects are strange in that so much of the process is intangible until final delivery.  So manage your client.  Guide them to where you need them to be.  Make it easier for them to be a good client than a bad one.  It won’t always work – sometimes there are clients who simply don’t fit – but for the most part it’s your job to keep them on the straight and narrow.  

Talk to them.  Always keep them up to date.  Respond to questions as quickly as possible – at least within a day.  Even if the answer is “I’m a bit busy at the moment but I’ll get back to you before the end of the week”.  With all these intangibles flying around the client looks to you to keep them grounded.  

A perfect example of this is a recent job I have been working on.  My client was a marketing agency.  Their client was a small business – we mainly dealt with the MD and Head of Marketing.  There was also a couple of people from an SEO involved.  

For some reason every job I did for them seemed to take a lot longer than the estimate.  I got the feeling that, despite the eventual, fantastic, results, there was a lingering undercurrent.  So I persuaded them to organise the project through good old Basecamp.  

And the reasons for the delays became immediately apparent to everyone, from the SEOs to the MD.  What would start out as 8 To-Do items assigned to me quickly became 30-odd To-Do items, assigned to everyone else involved – as questions were raised, slight changes in direction were needed and designs were reworked.  

With all this stuff out in the open the next phase of the project went much more smoothly than the earlier ones – because I managed the client into organising things through a better channel for communication.  

Because, the way I look at it is, at the end of the day, it’s your job, your client and your responsibility to keep things ticking over.  Don’t you think?  

Sometimes, it’s worth stating the basics for all to see:

• Follow the Model-View-Controller paradigm.  In particular, your views house your user-interface, your models handle the application and your controllers mediate between the two.  Controllers do not contain rules, conditionals dealing with business conditions, queries looking for objects related to the one in question.  All those things belong in the models.  
• Use ActiveRecord conventions at all times.  It may not be the most efficient thing in the world but for most of you out there, it doesn’t matter.  
• Use ActiveRecord and migrations to define and manage your database.  All your business related stuff stays in one place – the models – including defining relations (associations), validations and rules.  In particular, ActiveRecord associations makes some tasks easy (very simple many to many relations) and gives you things (such as polymorphic associations) that you can’t safely define using straightforward SQL.  With judicious use of validations you can ensure that the data stays safe.  
• Use RESTful designs in your controllers.  This means that your controller very rarely grows beyond seven actions (index, show, new, create, edit, show, destroy) – and RESTful routing ensures that GETs and POSTs go to the right places.  If you need to extend things then add a sub-controller.  For example, if you were transferring an employee to another, you could have a route: /employees/1 for the employee him/herself, /employees/1/transfers/new to let the user define which company the employee is moving to and /employees/1/transfers/create to actually do the transfer.  And if you’ve defined your model correctly, the implementation of /employees/1/transfers/create should be as simple as @employee.transfer_to(@company)
• Write your tests (or specs) first.  One – this gives you a series of small wins, which is good for your self-esteem.  Two – it helps to clarify your thinking.  ”I need to write something that does X and Y, resulting in Z … oh hang on, do I really need Y?  What about U and V?”
• Use mock objects when testing your controllers.  Why bother coming up with lots of test data when all you really need to say is “if I the model saves correctly then redirect to X, if it doesn’t save then show Y”.  In the “transferring employees” example above, you only need to test that the controller calls “transfer_to” on your model.  Of course, your model will have already tested that transfer_to does what is expected of it.  
• If you find yourself repeating a bit of code, or writing something similar then STOP and refactor.  Add methods to the application controller, create a new controller descendant, stick it in a view helper, add a module to your models, write a partial (and if it needs parameters, write a helper that takes a set of parameters and does the call to render :partial for you)
• Did I say write tests and specs first?
• Oh, and if it starts getting complicated you’re almost definitely doing it wrong.  

“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.

Like a growing number of computer users, 3hv is an Apple Mac based company. Sometimes, this can lead to problems … most people use Microsoft Windows, which looks and works differently.

Never fear – since Apple switched to using Intel processors, companies such as VMWare and Parallels make it possible to run Mac software alongside Windows software. Making cross-platform testing a breeze.

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.

You know how it is – there are some things that you are just not comfortable without. My phone in my back pocket, my wallet in my front pocket, the key in the front door when I go to bed (just in case there’s a fire and we have to make a hasty exit), the dog under my feet (tripping me up), one of my large collection of jackets (current favourite: leather biker jacket).

And so it is with Rails projects. Before I do anything I do the following:

• Load the Exception Notification plug-in and configure it with my email address
• Load the form_test_helper plug-in so I can confidently test my forms
• Load the ARTS plug-in so I can confidently test my AJAX user interfaces
• Load Markaby so my views are beautifully coded and semantically correct
• Create the Rails session store within the database (rake db:sessions:create)

Of these, the one I really can’t do without is Markaby (although ARTS comes a close second). I don’t know what it is (apart from Why the Lucky Stiff is genius). I can’t stand looking at rhtml files any more – too many angle brackets for a start. Instead, my mabs are things of beauty – and as I write the code to produce the views, I find that they are more semantically correct as well. For example:

div.row do  label "Email Address: "  text_field :person, :email_address  p.explanation "Please supply a valid email address so that we can send you a confirmation email"end

As I’m writing the Markaby code, class names like “explanation” seem to fit naturally – the code reads better, the HTML is semantic and the CSS is simple.

What more could you want?

There appears to be a lot of gnashing of teeth regarding the non-existence of the iPhone SDK. Some are saying that it is proof that Apple are evil and out to get us. There are rumours that the iPhone is about to undergo a platform shift and his Steveness is just saving Apple the trouble of yet another compatibility layer (although they must be getting good at them now). Even more likely is the idea that the iPhone is waiting for Leopard. Gruber’s take on this is:

It’s entirely possible that Apple is committed to opening up the iPhone to development but that they aren’t yet ready, and, as per their usual policy, are keeping their mouths shut in the meantime.

This strikes me as the most likely. We all know that his Steveness is not too keen on third-party developers, even ones with as much style as Mac developers. But it is a smartphone and as such will be pretty odd without an SDK.

However, it did make me think back to one time where I knocked together a Delphi component. We needed a UI component and could not find a third-party one that looked good for the right price. So I spent three or four days building one. I think I used to cost the company approximately £200 per day – so let’s say the component cost £800. I showed it to people and they thought it looked great – it did the job it needed to and did it reasonably well. Other people in the organisation started using it and, as a result of the feedback, I enhanced it. Probably another day – putting the cost at around £1000. Then my boss came over and asked what we would need to do to sell this component. Armed with a fountain pen, a piece of paper and some blind guesswork I came up with the following:

In other words, my £1000 project turns into a £6600 project – 1 week turns into over a month. And these were rough estimates with a high margin of error (and, it has to be said, subject to the vagueries of my memory, several years on). Of course you would then need to chuck in support staff of some sort, as soon as you get your first sale. Where the original code did what it did and could be passed around the organisation without a worry, as soon as you get third parties involved the whole enterprise becomes a whole order of magnitude more complicated. We never did sell the component – it just wasn’t worth the effort.

I’m sure that there is an iPhone SDK waiting to be released somewhere. But I bet it is Leopard dependent and I bet it is not ready for general consumption. The whiners will just have to wait.

Nuts by sundstrom.