How I learnt that cheap staff cost more in the long run

Travis Williams started Box and Dice software after failing to find a software solution to manage his clients in the real estate business. Now, the company handles some of the biggest real estate agencies in Victoria, with turnover of $650,000 in 2009 and expectations of 30% growth for 2010.

But when the firm started five years ago, Williams attempted to cut costs by hiring junior programmers – a decision that ended up costing the company two years in development time.

To fix the problem, Williams had to hire a new technical lead and delegate some authority. He says small businesses should focus more on planning to avoid costly mistakes.

How has the past year been for you?

From 1995 to 2005 I was a real estate agent, and then I started Box and Dice. We’ve done really well over the past year and we service a lot of large clients including Hocking Stuart, Jellis Craig and Marshall White. Most of the big players in Victoria.

But we don’t want to become an underground brand, I’m launching a book, doing some other publicity and just trying to get our voice out there.

We’ve had a 30% increase in revenue, and we’ve commenced on a national growth strategy. Whereas previously, we have been a predominantly Victorian-based provider, we are now teaming up with national conferences like the RELC, and that has been very successful.

Can you describe the problem you had with your first piece of software?

The need to deliver software really quickly and urgently was of the highest importance at the start, in order to appease some clients. That was the key focus, to get a product up and working very quickly, so we were rushed.

And with regard to real estate, there were some features that were very highly expected, and in the absence of some thorough investigation, we were developing reactively to appease some customers’ needs.

How did you handle the pressure of that deadline?

I hired junior developers to save on costs, and keep control. At least, what I thought was control. I wanted to be in charge, in the thick of it, directing traffic, and so on. And we ended up with a simple, great application.

However, we found that after awhile, things were expanding, growing, and then we found that a lot of our time we were dealing with bugs and a lot of complaints. So then we spent two years refactoring a big chunk of the code. We have a stable business now, but it was hard work.

What exactly happened with the code – did it turn bad overnight?

We actually had an epiphany two years ago when we discovered that about 60-70% of our development was time spent fixing or changing existing code and bugs. And the direction we were heading in, that was only going to increase.

We had to figure out what we needed to do… and unfortunately disappointed some customers while we addressed those internal issues over that time period.

So how did you handle the problem?

Two years ago, I brought in a very experienced programmer to become the technical lead. I let go of all responsibility in that area to this person, and then we started developing a longer-term strategy for the company.

So how did the technical lead fix the issue?

In order to take over, we needed a technical person that really understood the application, any weaknesses and needed to see what we needed to achieve in the long-term to make that all work. We needed someone who could fix the problems in the software.

There were several options available to us, but we did have to develop a strategy quickly because there were some factions developing among the development team at the time.

With programmers, they tend to be a bit religious with their development environments. Unless you have one religion you end up with a civil war, so when this leadership changed there was a bit of a change… it just wasn’t the right fit for them. But we feel we are stronger now.

What was the biggest lesson you learned after this occurred?

I think the biggest lesson I learned was the importance of having a test-driven development environment. But I think these five years have provided a feeling of certainty and self-belief, because when you start developing you have no idea what you should be doing.

Do you have any advice for small businesses who might be rushing a project, or hiring juniors to save on costs?

I think about 50% of development is simply preparation and planning, which while tedious and difficult is also necessary. It’s so tempting to make assumptions when planning software, but you need to have the right people working on your product and trust they are able to do the job.

We have a general manager now who is able to run the business more day to day, and I’ve delegated myself back down to more of an analysing, strategic role. I think my mantra is to hire people smarter than yourself, and I think it’s working out.