Archive for January, 2008

Cross Platform Development – testing on both platforms

Friday, January 25th, 2008

Internet Explorer versus CaminoLike a growing number of computer users, 3hv is an Apple Mac based company. Sometimes, this can lead to problems … most people use Microsoft Windows, which looks and works differently.

Never fear – since Apple switched to using Intel processors, companies such as VMWare and Parallels make it possible to run Mac software alongside Windows software. Making cross-platform testing a breeze.

How not to do it

Wednesday, January 16th, 2008

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?

Small Business

Monday, January 14th, 2008

Meeting Room by tskI 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.

The trouble with Ruby on Rails

Sunday, January 6th, 2008

Normally I wouldn’t talk about Ruby on Rails on this blog. That geek talk is found on the tech blog instead.

Wondering?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.