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.

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

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.

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.

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?

Everyone’s favourite shared host, Dreamhost, has had a major fuck-up. They accidentally billed a lot of their customers for a year in advance. Some of them were billed repeatedly. Some had accounts suspended for non-payment, others incurred overdraft and credit limit fees.

Ignoring the fact that it never should have happened (test, test, and test again where money is concerned), Dreamhost responded in their standard way. An update on their status page and a jokey blog post. The status page is good - an apology, they pinpointed who made the mistake (rather than hiding behind corporate anonymity) and stated what they were doing to set things right.

It’s the blog post I have an issue with. When you have made a $7.5million mistake (that’s what they claim the extra billing adds up to), you shouldn’t make light of it. When you have caused your customers to incur bank charges and fees, you don’t joke around. But, fair enough, that’s Dreamhost’s style (and originally one of the things that I liked about them). Where I really have problems is with this statement:

Really, it’s sort of amazing this never happened before in the last ten years.

When you’ve fucked up royally, especially when it comes from not testing your systems properly, you can’t (in a joking manner) say “ho ho, well it was always going to happen one day, it just happened to be today”. It doesn’t exactly fill me with confidence that it isn’t going to happen again in a couple of months.

It just ain’t good enough, is it?

I have been planning this post, on and off, for months. Then I almost shelved it, when I read Shane’s excellent “Just like Air“.

You see I wanted to write something very similar. Not the bit about “money being like air” (although that would be nice, it’s not my goal). No, it’s the bit about small business being best.

When I decided to embark on this enterprise, I spent ages reading (mainly online, but a few books too) about how to proceed. One thing that still trips me up is how to refer to 3hv in articles. Should I use “I” as, at present, there is only me? Or should I use “we” as people won’t want to buy from a one man band?

And actually, I now use both, depending upon the circumstance. Firstly, 3hv is a one man band (at least for now). But I do work with others as needed.

And there is no reason for most “small to medium” size businesses not to want to work with a one man band. You see, I can offer things that the bigger companies can’t.

Personal Service: you will be speaking to the person doing the work. Not an account manager (who has no technical knowledge) or a help-desker (who has no idea about your particular circumstances). But me. The head honcho. The big kahuna. You can even have my mobile number if you want (in fact it’s on the web-site).

Fast Moving: the world of technology moves at a bewildering pace. Although I have been using Ruby on Rails for years if the time comes to switch I can switch. I don’t have a massive investment in existing technologies. I don’t have a vested interest in promoting one over the other. In fact, being small means that my major vested interest is in keeping costs down - and I can pass that on to you.

Better value: when you hire a large company, what are you paying for? It’s not just the team that is doing the work. There is the help-desk staff, the account managers, the HR Director, the big, fancy office, the company cars, the sales reps. With 3hv, you pay for me, any expenses that are incurred and any outside help we need to bring in to get the job done. Minimal overheads means more bang for your buck (as they say).

Decisions at the Speed of Light: I don’t have to run things by my manager, who has to run things by the regional manager who has to run things by the Finance Director. Because I do all three roles. Meaning that decisions get made quickly. Transparently.

Effective Communications: no chinese whispers as the sales guy says “X”, the implementer says “Y” and the developer says “Z”. The words travel from you to me and back again. Meaning less miscommunications, less wasted time and less frustration.

Priorities: I don’t have hundreds of clients. At the time of writing I have two major clients and a few minor ones. That means that when you hire me I have to treat you as a priority. Every single client is vitally important to me. Meaning I go out of my way to give you the best possible service.

As I say, read Shane’s article. It is inspiring. The wave of the future is micro-companies, doing what they love, exceeding expectations and delighting their customers in a way that is unlike the mega-corporations that surround us today. So join us - if you need a web-site, some software writing or a bit of advice on how best to proceed, contact 3hv today and see how things are changing.

Meeting Room photo by tsk.

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.

Yet another post in an occasional series detailing the way that 3hv works. Read more here or subscribe to be notified when a new article is posted, or find out why hiring 3hv will benefit your business.

This is the most important of the lot. Where the work gets done. Where I earn my money.

I believe in Test-Driven Development. This is a method of software development where, before you write any code, you write a test that proves the function.

So, the specification may read “the user goes to the product page, clicks the edit button and changes the product name. Upon clicking ’save’ the product listing is updated with the new name“. Using TDD I would write a test that simulates calling the product page, clicking the edit button (with its implied suggestion that this brings up a new page that lets you edit the product), change the product name, click ’save’ and then check that the product listing is updated.

Because the test is written first, I need to write some code to make it pass. Until the test passes I know that I haven’t met the specification. As soon as it passes I know that I am done. No overblown, complex code (complexity takes longer to write, is harder to debug and easier to break). I just write the bare minimum to make the test pass. As the test represents the specification, I know that I have done enough to meet the client’s expectations.

But TDD has extra benefits. I can go back and improve the code (maybe I discovered a more efficient way of performing an operation and need to change the existing code to use it). Making such changes often fills developers with dread as it could break stuff (”if it ain’t broke don’t fix it“) - but as I have a suite of tests I can make changes, safe in the knowledge that everything still works and meets the specification (in the trade, this is known as refactoring). Which means that the code stays beautiful - easy to read, easy to maintain, easy to improve. So you, the customer, benefits.

Want to know the secret of how to do it? Here it is - Implementing a Task

3hv is a small software company in Leeds, England. If you’re of a technical bent then take a look at the geek blog - made of stone. Otherwise just subscribe to be notified when new stuff is posted here.

This is one of an occasional series on how 3hv conducts its business processes. You can read more here, subscribe to be notified whenever a new article is posted or find out why hiring 3hv will benefit your business.

So I’ve got the sale. Nice work fella.

Now what?

Well, I want to make sure that I don’t lose money, and as a service business, time is money. Absolutely vital to the success of any business is that I keep a lid on the costs - my time in this case.

So the project (which, in most cases, is fixed price) needs to go into my time-tracking software (I’m currently using Freshbooks as I can invoice and get paid, online as well - but I’m not wedded to them). And my task list needs to go into Basecamp (because I make a living on the web and everyone uses Basecamp don’t they?).

Then, just plough through the tasks, one at a time (more on this in a later post). Once it is completed, the tests pass, the page looks nice and I’ve gone back and tidied up the code, tick the task in Basecamp and record the hours in Freshbooks.

Now, one of the most important bits. Post a message in Basecamp, addressed to the client, explaining what I have done, how it works (in English, not techno-shite) and why it works that way. Not forgetting to include a link to the new feature, so the client can evaluate it straight away. In other words, get feedback from the customer as early as possible. This minimises misunderstandings and means that I can react quickly to mis-steps and mis-communications (because they always happen). If there is feedback, deal with it (if necessary, negotiating an extra charge if it is beyond the scope of the original request).

Once all the tasks are completed (and they should be to the client’s satisfaction, as they have been checking as we go), I can build the invoice, send it to the customer and then watch my bank account like a hawk as the pennies come flooding in. Unless I need to chase them (well Freshbooks does that for me). When the payment comes in, update my accounts, have a nice sit down, glass of red wine and buy an iPhone (well maybe not).

Yeah yeah, them’s the words, where’s the pictures? Here - “Do a Project and Invoice it”

3hv is a small software company in the North of England. You can find out more by visiting the web-site - or just subscribe to be notified when new articles are posted (here or on the technical blog).