The IT sector lends itself very well for working as a freelancer. A lot of software developers actually have some freelancing experience. A lot of books and articles have been written about pleasing the client and delivering the right software at the right moment. Far less articles however have been written about the way clients should behave. That fact that clients pay our bills in the end doesn't mean we should tolerate their, sometimes, very rude behavior. This rant contains the subjects that, I think, are the most important.
Good software isn't cheap
A big problem I've stumbled across many times is customers who think they can have a full-featured company website for less than €500. Sure, my 12-year-old neighbor (which I just made up for the sake of the point I'm trying to make) could click-and-drag a nice Joomla website for you for a couple of hundred bucks. A professional software developer who really knows the framework(s) he's working with and who understands how to build secure, stable, and good working software is much much more expensive. Software developing is just hard compared to other professions. Most software developers I know went to the university and have been studying for years to get a good grasp of knowledge about creating good software.
Apart from the budget limit, customers very often tend to want far more things than agreed upon in the contract, and they want them to be included in the price. Yes, I too can build a basic website for you by deploying a nice framework with some template that you bought on the internet. But please accept that every requirement you have that will cause me to do a lot of custom work, will cost you money. Your doctor doesn't work for free, the gardener doesn't work for free, you probably don't work for free, so why should we?
I've seen lots of clients hiring these cheap self-proclaimed programmers or outsourcing their development to countries such as India or Vietnam, resulting in very unhappy clients. Yes, they seem to be a little cheaper, but the software they deliver is very often of such bizarre poor quality that it probably costs 5 times more in the long run because the maintenance is way more expensive because it's just way harder to maintain poorly built software. These kind of clients very often reject my proposals because they think I'm too expensive, returning to me after a couple of months because their little adventure turned out really bad.
Constantly changing requirements
We know it's hard to come up with a full list of requirements up front. That's why we invented techniques like 'Agile software development'. If you give us the wrong requirements however, we can't fully prevent delivering the wrong software. Yes, it's easy to blame us for that, but in the end you were the one that gave us the wrong requirements. This wastes a lot of our time, a lot of your time and as a result: a lot of money. Software developers might be very smart, but they are people who usually take things literally. As a client you (hopefully) know what you want, the software developer you are hiring doesn't. The things you take for granted often aren't so obvious. A software developer doesn't know the domain as good as you do, a software developing isn't going to do lots of extra work for free. If you want us to make what you have in mind, fully describe everything you have in mind.
Good software requires dedication
In order to deliver good software, the software developer should give his dedication to the project. But the fact that you are the one who is hiring someone to work for you doesn't mean you can just sit back and relax. You like to see correct software, delivered on time, meaning that we, as developers, have to keep in touch with you so we can constantly verify the requirements. This doesn't mean that you should be constantly watching over our shoulders while we're working, but it does imply that you should answer e-mails as fast as possible. Preferably within 24 hours. I've seen clients completely ignoring my attempts to keep in touch with them, leading to them being mad at me for not delivering their product before the end of the deadline. In fact I've seen clients ignoring my e-mails for more than 6 months, and then calling me furiously to investigate why their software is still not finished. Yea right.
Not every improvement is visible
Just because there isn't any fancy user interface with loads of new functionality doesn't mean that investing resources in certain parts of an application isn't useful. In fact in most applications more than half of the code has nothing to do with displaying stuff on the screen. There are lots of reasons why it's very often a good idea to invest some money to improve this back-end code: many applications are programmed very badly. Not all the code, but some parts of it. The Pareto principle says that 20% of the code is responsible for 80% of the problems. These problems may range from severe performance bottlenecks to very bad maintainability and data corruption. Yes, you probably won't see fancy new screens with lots of new functionality if you invest some more money in this 20% of the code, but in the end it will definitely avoid lots of problems that will probably cost you money.
It's very hard to give a time estimation up front
Prediction how long it will take to finish a product is hard in every sector. In the IT sector this is even harder because clients very often don't know exactly what they want. After telling us your idea we just can't tell you exactly how long it's going to take. Sure, we can give a very rough estimation, but it will be just that: an estimation. The requirements usually are going to change during the project, so please don't hold us responsible for that.
Software developers are human too
Yes, we may behave like robots, we may lock ourselves up in our room for very long times, but that doesn't mean we aren't human. When you eat at a restaurant you probably show appreciation to your waiter after dinner, when you travel by air you probably show your appreciation to the pilot after landing you successfully, when one of your family members gets cured at the hospitable, you probably show your appreciation to the doctor. Please show us your appreciation too. And don't send us rude e-mails that don't meet the (unwritten?) etiquette of social interaction via the internet (that includes writing full sentences, starting with capital letters and ending with interpunction).
Don't give us the solution but the problem you're trying to solve
People often ask me for advice because they have a problem and they've come up with a solution, they just don't know how to implement this solution. This is the other way around. Usually you state your problem, and the professional comes up with a solution. Please let the software developer do what he's good at: solving your problems. When it comes to IT, the software developer probably knows way more than the client. This means that he knows what the downsides of a solution are, meaning that he should choose the right solution. He might come up with solutions that you didn't even think about. Please don't make things way more complicated than they really are and just leave the technical aspects to the technical people, this may save you a lot of trouble and money in the long run.
Take our advice
As mentioned in the previous paragraph, as software developers we probably know more about the techniques than you do as a client. If you want a movie on your website that automatically starts playing, but your software developer advices you to stick with a movie that doesn't automatically start playing; take his advice. He has seen this before and knows it's extremely annoying to other people. You may like the movie, but others don't. If your software developer advices you not to use flash for displaying your content: believe him. He knows the downsides and the alternatives, you probably don't.
Software developers always have to do everything they can to deliver good software, lot's of books have been written on the subjects of quality assurance, requirements management, agile, etc. Something that deserves its own book however are the rules you as a client should obey when starting a new software project. The biggest problems are the fact that most customers want their software to be as cheap as possible, the ever changing requirements and the lack of communication.