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.

I’ve taken the decision to split my blogging activities into two (three if you count my infrequently updated Nottingham Forest Football Club blog).

From now on, 3hv (that’s here) will be the place to find out about business (strategies, tactics and stuff I learn along the way). In other words, the perfect place to find out more about 3hv as a company.

And made of stone will be the place to find out about the intricacies of Ruby on Rails and software development in general. The perfect place for your inner geek (or the geek that lives in your basement and is afraid of sunlight and soap).

Of course, you can subscribe to both blogs - 3hv here and made of stone here.

Aim high but grow slowly.

I had no idea how I would do this, but I figured if humans had the capability to put a rover on Mars and launch satellites into space, then there must be some way to clear out 80,000 emails in 3 weeks. If it is humanly possible, then it’s not impossible. It’s just a matter of figuring out a way to do it.

After just over a year in business, we still have a long way to go in ‘proving’ anything, but because we’ve used the same grassroots approach to building our own business (which has been successfully busy from day 1 without going into any debt), we are walking the walk. There are no shortcuts to gratification here and, in fact, some days are really hard.

or why you should call a slut a slut

Do you think it’s because I said ‘slut’? Are people really that conservative? Maybe I should tone it down a bit. But if I tone it down a bit, I won’t be being myself. I don’t want subscribers who don’t like me for who I am. Then again, I want to write a book. I want people to buy it. I don’t care who they are. Am I pissing off the Bible belters?

Naomi’s a fantastic writer, linking red wine, sluts, naked men and balls into a series of articles about business. Recommended.

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.

Need a web-site but don’t have the technical knowledge to do it yourself?

Choosing a supplier can be a daunting task. How can you trust the techie guy when you don’t know your PHP from your RSS? Just what is the difference between a designer and a developer? Are you being overcharged? What exactly does that word on the invoice mean?

Firstly, it helps if you have some idea what you want. What is the goal of your site? Is it to let people know you exist? Is it to boost sales? Is it a portfolio of your work? A good designer should tailor their designs to meet these criteria.

Who is going to be visiting your site? Where do you want them to go? If you’re wanting an online store, which set of pages does your typical customer have to navigate to place an order. It can be useful to draw up a quick flowchart of how you see your “average” visitor moving through the site. In theory, this can give your designer an idea of how many pages you need and what needs to be on each one. However, be prepared for this to change. A decent designer will also know what works and what doesn’t and should be able to modify your ideas accordingly (of course, explaining why these changes are needed).

The flowchart plus a few ideas on the goals, design and layout should be more than enough for the designer to prepare a quote. Watch out if the quote is simply a price - if so, ask for a detailed breakdown. There are two reasons for this - firstly it forces the designer to think through exactly what needs to be done; secondly, it gives you the opportunity to question any of the items you are not sure about. If you are not satisfied with their explanation of what an item is then just walk away. Most problems with web design and software development stem from miscommunication and misunderstanding. If they cannot express what needs to be done in terms that you can understand, at this early stage, you can be sure that there will be problems down the line.

Next, you need to ask how they will deal with changes to the specification or design. This is because you can be absolutely sure that changes will be required at some point - when you see the final layout you decide that you want it a different shade of green, or they may come across some unforeseen technical problem that mandates a change of tack. No matter what the cause it will happen and your supplier needs to be able to deal with it - preferably without adding a zero onto the price!

Then, ask how the project will be delivered. Will you sit there, twiddling your thumbs until, magically, X weeks later, you see the finished article (and then decide upon that different shade of green)? Or do they break the project down into “milestones” giving you the opportunity to comment and feed back early in the process (when changes are easier and cheaper to make)? This also links to another important point - when do they pay the bill? Is it a deposit up-front and the rest on completion? Or staged payments, linked to each milestone? And what is the sign-off process - how do you and they agree on that what was delivered is what was required?

Lastly, what happens after completion? If you want changes making, do they charge an hourly rate or do they charge a percentage per year as a “support fee”? Do they host the site and charge annually for that as well? And, this one is vital, who owns the source code (the computer code that makes up your site)? If they own it and you decide to switch suppliers for whatever reason, your new supplier will have to start from scratch. If you own it, your new supplier may (or may not) be able to use it as a starting point (depending upon the technologies used, the competence of the initial supplier in writing the code and the competence of the new supplier in reading the code).

As for technology, don’t let anyone bamboozle you. Most web technologies (ASP, ASP.Net, PHP, Python, Perl, Ruby on Rails) are all much of a muchness. I prefer Ruby on Rails - it has a number of benefits to me - however, the benefit to you should be reflected in a lower quote and smoother project delivery. Beyond that, you shouldn’t need to care.

Of course, the easiest way is to contact 3hv.

It’s basically an ad for Squidoo but it makes sense and should work. i wouldn’t use Typepad though - maybe more on that later.