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?  

I recently went on holiday. To Spain. It was good.

Apart from it took me about four days to switch out of work mode. Constantly worrying about checking my mail. Has Basecamp been updated? What’s happening on Twitter? Given that I was only away for seven days, four days in work mode was not the best.

I made up my mind to try and keep things under control from now on. After a day of work, switch off. No reading blog entries, no checking emails, no tweets. Do something else, talk to a person who is physically present, watch the TV (OK, maybe that’s pushing it), play the guitar, get mauled by the cat. Just stop thinking about work!

Then, on my return, I was faced with the prospect of opening my FeedReader.

I remembered how my heart would sink when, opening it on a morning would reveal a red badge with a three digit number in it. “500 unread articles? I’ve only been asleep for six hours. It will take me that long to plough through those articles!” Imagine the unread count after being away for a week

I didn’t want to go back there.

So I made the choice not to open it. Ever.

Two weeks in and I don’t miss it.

I’ve got podcasts for the car through iTunes (yeah yeah, a glorified feed reader, but with six or seven “unread” items, not thousands).

I’ve got Northpack.

I’ve got the Geekup mailing list.

And I’ve got Twitter.

Thank buggery for Twitter.

People are always posting links in their tweets. I don’t have to read them. I use Twitterific, so it pops up on-screen for a couple of seconds. If I miss it, I miss it. If I see it I can choose to look at the link or ignore it. Decision made in less than five seconds.

No stress about the stuff I’ve not yet looked at. No stress about the stuff I’ve missed. In fact, no stress at all.

That’s how I’ve been dealing with the overload. How do you manage it?

It may seem stupid, given that 3hv has one employee, but I have just created my Organisation Chart.

Why?

Well how else can I swan about on a golf course like a real corporate executive? You’re not no-one until you’ve got an Org Chart.

Well, actually, there is a real reason for it. And it’s nothing to do with golf (thank goodness).

You see, this Organisation Chart isn’t about heirarchy or reports or line management. Instead it’s about communication. Who needs to communicate with whom. And as I grow my team it’s important to have an understanding of who does what and who they need to support them. I’ve already started outsourcing some of the bits I’m not too keen on (more on this another day) and if I really want to do a Ferris then I need to know what’s going on before it gets out of control.

Even this simple chart has shown me stuff that I like to do (grey) and stuff I’m not interested in (white). With the light grey development box being something I like to do but will have to (somehow) hand over - it’s the core of my business so I need to keep my hand in, but it’s also the single biggest bottleneck.

It’s also brought about some surprises. Who would have thought I would want to do QA? There’s a story to that - and that will probably be coming soon as well. As for marketing, I know very little, but I’m going to find out.

So why not give it a go? See which of the many functions you perform within your business; then decide which you like and which you would do well to get rid of.

Sorry - been busy.  Really busy.

Just enough time to update you on my goals.

• Revenue: Up.  By more than 10%.  Probably enough to give me grief in achieving the target next month.  But that’s the idea eh?  Also explains why I have been so busy.
  SUCCESS
• Hours: Still over 40 per  week, but down on last month.  In fact, they’re only just over 40. FAILish - half marks.
• Marketing: I’m turning down work.  SUCCESS
• People: Geekup and now the Leeds Ruby Thing.  SUCCESS

Not bad at all.  Just the hours to sort out.

No point having goals if you’re not going to follow through on them.

So here is my January score-card:

• Revenue. No 10% gain, in fact, it’s down on December. FAIL
• Hours: Averaging about 50 hours a week. FAIL
• Marketing: Outside help contacted, beginnings of a plan is in place. SUCCESS
• People: The last geekup was great, Jeremy and I have plans for a monthly Rails meeting and Northpack gets my name out and about. SUCCESS
• Debt: Total failure. I’m crap at managing my own money (good at the company money though). FAIL
• Car: Smaller car, cheaper petrol bill and I spend the time listening to podcasts, so it’s not entirely wasted. SUCCESS
• Freecycle: Not given anything away this year. I tried but my emails were not reaching their destination for some reason (?). FAIL
• Cooking: Yum. Yup, lots of that, and it’s good. SUCCESS

So a 50% success rate. Must try harder. How are you getting on with achieving your goals?

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.

I’ve added some recommendations onto the 3hv site.

It’s now three months since I quit my full-time job and became a free-lancer and/or mercenary contractor (depending upon for whom and why I am working).

It’s odd.

Where I was before, I had been there for nine years. Everyone knew me. I could string together long sequences of swear words without anyone batting an eyelid. I could insist that I work in Ruby on Rails when everyone else was in .Net. I could dress how I wanted. I could put offensive slogans on my screen-saver. No-one batted an eyelid cos they knew I was good at what I did.

Now, I’m starting over every time. No swearing. Dressing smart. Doing as I’m told (yeuch). All in the name of being “professional”. Wife left you? Keep it quiet and get on with it. Cat run over? Put on your best suit and smile at the client.

What does “professional” mean?

At its simplest it is doing something because you are paid for it. If you ask me that does not mean leaving your emotions, your personality, who you are at home. If who you are does not help you do your job then you should probably try a different job. It does not mean that you become an automaton, leaving yourself at home as your trudge to the office.

So if you hire me this is what you will get:

* My emotions will not be held in check. If I care about something I care about it. If I’m having a bad day and I ignore what is going on in my head, I will do shit work and have to redo it tomorrow.
* I will swear. Tough shit. I like it. I’m good at it. Twatbag.
* I will dress badly. Obviously I think I look fantastic. No-one else agrees. I like my three suits. My wife thinks I look good in them. I don’t wear them.
* I will be between 5 and 10 minutes late for every meeting. I always try to leave five or ten minutes earlier. I don’t manage it. I have no idea why.
* I will write beautiful code. It matters to me. It makes me feel good. It is important (see emotions, above).
* I know what I know - I also know what I don’t know. I have no illusions as to my areas of expertise. But what I know, I really, really know.
* I will be polite. “Please” and “Thank You” are important. More important than swearing? I can’t answer that.
* I work hard. Always. I was once told by my aunt “you realise that because you are brown you will have to work twice as hard to achieve the same … think that’s unfair? I’m a brown woman - I have to work four times as hard“.
* My family comes first. My girl has a hospital appointment? Your stuff will have to wait. I will make up the time (see above).
* I can talk to you about technical stuff. You will understand what I am saying. No jargon, no gobbledygook. It is, in fact, absolutely vital that we communicate clearly and so I will make sure that I put in the effort. But I am an introverted geek - so I’m pretty crap at small talk (as opposed to Smalltalk). Sorry.
* I will deliver something that does what is needed, in a reasonably stylish way. It may even make you smile. But you won’t be disappointed.

I guess that makes me “not professional” to many people. I don’t care. I’m not a zombie and you don’t want to hire one.

Business Card by xlucas

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.

Ruby on Rails won’t make you a better coder.
Ruby on Rails won’t deliver a bug-free project.
Ruby on Rails won’t ship your release on time.
Ruby on Rails is not a silver bullet.

I love Ruby on Rails.

I can work faster, more reliably, using “cool” technologies like Unix and Macs and get more done with less grief than any other technology I have ever used.

But Rails is not a silver bullet.

It is still possible to screw things up. Ugly code, buggy sites, slow applications. Rails may make it easy to do things the “right way” but old habits die hard.

Ultimately, what you need, more than anything, is a pervasive set of automated tests. And it’s easier to have a pervasive set of tests if you write them before you write your code.

Why is this important?

Tests give you confidence that the code you just wrote, over here, does not break the code you wrote last month, over there.
Tests give you confidence that the complex, interactive web page that you wrote does not break when you decide to change the way that it works.
Tests give you the ability to go back and tidy up that code that was written at 4:59 on a Friday afternoon - turning it from ugly to beautiful.
Tests become a living, breathing specification of your client’s requirements. Why oh why did we write that code that way? To make sure that “test_customer_order_value_must_not_be_negative” always passes.

So, if you’re just starting out with Rails, please bite the (silver) bullet and write those tests, unit, functional and, if necessary, integration. It may seem to slow you down today but you will not regret it tomorrow.