Tara Hunt’s presentation from Fuel is worth a look - not short, but an excellent overview of how community-based networking works.  

http://www.slideshare.net/missrogue/making-whuffie

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

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.

Often, a client has a good idea of exactly what it is they want building. This, in theory, makes my job very easy. Take the list of requirements, figure out how long they will take to build, calculate the price, sign the contract. Easy peasy. Lemon squeezy.

Of course, if it was that easy then IT would be known as one of the world’s favourite industries. As opposed to smelly geeks in bad T-shirts who cost a fortune, building stuff that never works.

The reason for this is that estimating a project is hard. If you were estimating the cost of building a bridge you have hundreds of years of previous experience to draw upon - you know the tolerances of the materials involved, you have a number of different architectural styles to draw upon. In other words, it is a known problem. Unfortunately, in software, often we are building stuff for the first time. We don’t know how the server will react. We don’t know what the best design to use is. That’s just the way it is with a young industry.

But, things are changing. In fact, there are libraries of patterns to draw upon - the famous “Gang of Four” book should be essential reading for every software developer. Ruby on Rails takes those patterns and forces you to follow them. It’s part of why I love it so. There are known procedures to follow to make your server scale.

And if you break the project down and divide it in small enough chunks (providing the actual requirements capture is accurate) you can build a decent estimate. One of the key features being that I assess the risk of each task and give myself some leeway if there is a chance that I may not know how to do things or that the feature may be misspecified.

The attached flowchart shows how I do it … New Project Estimate. Feel free to take a look - and leave your thoughts below.

This is the blog of 3hv Limited - a small software company based in Leeds, England. You can find out more by visiting the web-site - or just subscribe to be notified when new articles are posted - both here and on the technical blog.

We Ruby on Rails developers are used to the barbs. “Ruby doesn’t scale” they say. Ignoring the fact that Twitter famously deals with eleven thousand requests per second.

For those of you for whom the above was gibberish, let me explain. Scaling a web application is making it deal with large numbers of simultaneous users. That in-house application that happily deals with all thirty people in your office using it at the same time may fall apart if thirty thousand people start using it concurrently. And, in this age of Digg, Techcrunch, even Slashdot, getting hit by a sudden spike in users is quite likely.

But there is a problem with scaling. Namely the processes and procedures you need to follow to make an application scale can sometimes be in direct opposition to those processes you need to follow to make the application fast for a small number of users.

There is a similarity here with making a business scale. I have spent all of my career working for small companies (although many of my clients have been large). The reason? Just like a small-scale application can be fast and responsive, a small-scale company can make quick decisions and run fast and loose with its procedures. This means that every staff member needs to do a bit of everything, every staff member has a say in decisions, every staff member can make a real difference.

The problem comes when the business starts to grow. How do you keep your corporate culture when suddenly you find that “newcomers” out-number the “old-timers”? How do you keep that “folk knowledge” (no, we don’t do it like that - because two years ago X happened and we nearly lost two clients) when your staff no longer fit in a single room?

Now this is looking far-ahead for me. Currently, 3hv is a one-man band (the odd contractor or freelancer aside). My procedures live in my head; no-one can do the wrong thing because I get to decide what is right and what is wrong.

But I fully believe in starting as you mean to go on (reserving the right to change my mind at any time of course :0)). And, more importantly, as things stand now, there is a limit on my income. I have to eat and sleep, and most importantly, I have a family. That means I cannot spend more than ten to twelve hours per day earning (and ordinarily eight to ten hours is all I can manage). So, if I am paid by the hour, the only way to increase my income is to increase the number of chargeable hours. And the only way to do that (apart from a time machine) is by bringing in more staff. Yet once I do that, how can I guarantee that the quality of the work (the thing upon which 3hv’s reputation depends) is maintained? I don’t want to be hiring and then throwing away the extra hours by monitoring everything my staff do. At the very least, that is going to be totally demoralising to the staff.

So instead I must start to scale my business from the off. Document my procedures and processes. Emphasise (and write down) the values that make 3hv what it is. Share them with my customers, my (future) staff, my acquaintances. Like scaling an application this may make me slightly less responsive now. But, when the time comes, it means that I can grow as quickly as needed with no loss of quality.

And, of course, this being the age of transparent internet business, I intend to share these processes with you. Why? I get feedback (from you, dear reader), you get to watch 3hv grow and (hopefully) come back here to see what I will come up with next. And it should promote trust between me and my potential customers - as they can see exactly how 3hv works.

You know you want to subscribe to find out more. Or maybe you just want to hire a web developer who will talk to you in plain English and deliver you some code so beautiful you will cry with joy.

Photo of Oresund Bridge is by sundstrom.