It seems that in today’s age every business will sooner or later need a programmer, or developer as some of them like to call themselves. Whether it be for a website, for data management, or to build an application. They come into your office offering the world, tell you how great they are and the great things they will do for your business, use tons of technical words you don’t understand, and take all the time in the world to complete a project – if they complete it.
Do not be intimated by their big fancy words, and extensive experience. Do not get scared by their prophecies of doom and gloom if you do not do things their way. Do not allow them to dictate what your company needs. You know what it needs, you know what your clients want, and how they want it. I was once told, that I was running my company incorrectly and that my clients should change how they do things to run more efficiently. You are not hiring a developer to change what your business is. You are hiring them to build something that will aid you in being more successful doing what you already know to do.
I have been misled in the past. I have had developers on payroll developing applications that took years to complete, and yet never was fully functional. I have heard all the one liners: “it’s almost done”, “we’re really close”, “it’s done, it just needs a little tweaking”, “soon, very soon”, “this will be state of the art”, “the hard part is done, the rest is fast”, “it’ll be run your company before you know it”. I love the last one, as I’m pretty sure I’ll know what’s running my company and when.
An important step is to not forget the goal: a new tool for your business to strive. Each time a developer tries to divert with ideas of grandeur, ask yourself, will it still do what I need for my clients? Sure making hot coffee in space sounds cool, but unless your clients are astronauts, who cares! The person(s) you hire to develop your applications must stick to the spec or don’t pay them!
Often a programmer will ask you to buy hardware that you intend on using with the applications. After having spent much money on hardware that has never been used, I have learned that you only buy the hardware when the software is ready to use it. Never mind the “Oh get it now, and when we’re ready it will be in the office ready for us”. Between delays, changes in direction, and new advances, the hardware needs can change from the start of a project to the end. A simple example of this was buying a plethora of servers, and power-supplies, for running concurrent events. Technology has advanced such that I now only use laptops as servers, they’re portable, has a battery, their own screen, keyboard and mouse.
Hardware costs are not the only thing that can get away from you. Time… time slips though a programmers fingers like they were grains of sand in an hourglass. Programmers have no concept of time. I have never seen a programmer accurately estimate the time required for a project. They claim that there are complexities that must be researched. They tell you it’s not a simple request.
Programmers blame “project creep”, or rather change requests, on what was originally requested. I often wonder if this is a chicken or egg situation, did we the client not think things through adequately, or has the project taken so long that the business has evolved since it started? They blame us for not understanding what they are talking about. In truth, they are right. I am not a programmer, and I don’t get the tech terminology they are using.
Too often it is our fault as well. Too often we are too proud to say we don’t understand what they are talking about. We don’t like to admit we don’t know the technical language, and sit there and just nodding and agreeing instead of raising a concern. I have learned to come right out and say “Ok this is where you are losing me”, “I was unaware there would be math”, “Your explanation is going beyond my technical comprehension” or “I don’t understand what you are saying and don’t really care, just tell me: will it work?” In the end, whatever they are doing, and however they want to explain how they did it, the result needs to do what you wanted it to do.
A good developer will listen to what you are saying, and adapt his ways to your needs. They speak of “agile” programming, they should also be agile in adapting to the client needs. He/she should take the time to learn about your company and how it runs, before making conclusions on what you need. In truth, we should all do this when approaching a client…
Moral of the story: In looking for a developer, find someone who can speak your language in addition to tech-speak, and understands that you run a business with budget limits.