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.

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.

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

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.

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.