I cannot tell you how many times I have heard from clients and colleagues, “Programmers are a different and quirky breed, making them difficult to work with.” The real question is, “Why?” This statement does not apply to every programmer, as we are all unique and different. However, it seems that a majority of programmers do fit into this misconception of the programmer mold. I have learned the skill of bridging the gap from “programmer” to “normal” and can share a new perspective to our mystical world.
In the first article of this series I’m going to discuss proper communication and the importance it plays in a project. Like it or not, most programmers do not communicate well - it’s just the nature of the beast. This creates a double-edged sword, as the success of a project requires good communication.
Proper programming requires thinking through a virtual puzzle - connecting each piece within your mind to ensure the project fits together perfectly to create a seamless and flawless picture. Each piece interacts with another and every piece is vital to the picture as a whole.
When talking about a project, a programmer has a number of thoughts firing through their mind like a machine on overdrive. Imagine all of this happening with a client or boss on the other end of the phone or across the table waiting for an answer to "Can this be done?" or "How much time will this take?".
In order to put this puzzle together you need to have every piece of the puzzle in front of you. In almost every discussion of this nature the programmer is typically given only a portion of the full picture. Imagine being asked to draw half of a picture and only being told the other half of the picture looks something like the Mona Lisa. You could draw your half of the picture, but when you put the two pieces together they are not going to match up.
In programming, a single detail can change everything. I want a program that allows my client to select a date, book an appointment and then make a payment. This is a very high level request that a programmer typically receives. We could easily put a date selector on the page, and have the client select a date and time, request some personal information and run a payment. This seems easy when you think about it in a high-level manner, but I can guarantee you the client is expecting more than something this simple. Here is where the first “difficult programmer” scenario comes to the surface.
Let’s analyze just a few missing details that could turn this project from a one-hour project to multiple days of work.
1. Are the hours the same every day or do they change?
2. Will the schedule always be 5 days a week or 7 days a week?
3. Do we need to set the times available to a fixed schedule, or user modifiable schedule?
4. Do we need to account for holidays or days the shop is closed?
5. Are the appointments all for the same service or can they select different services? If so, is the schedule of Service A the same as Service B?
6. How are we accepting payment?
These are just a few examples of “small details” that are imperative to the success of the project. Yet these details can also change the time, scope, and budget of your project immensely.
It would be difficult to explain how or why these details can be so catastrophic in programming terms, so I will try and relate it to something that anyone can relate to. Imagine you need a 3-year-old child to perform the steps above. How would you define a set of instructions to ensure that this 3-year-old child was able to do the task perfectly every time?
In our high-level example you could simply instruct the child to ask for a date, ask for their name and then ask for their payment. Simple enough, right? I can almost guarantee that the end result is not going to meet the expectation you had. The child would ask for a date, but would not inform the user we are not open at 8 o’clock at night, nor would the child ask which stylist the client wanted to appointment with. The child would ask for the clients name but not require a full name or middle name, etc. The child would ask for payment but might accept a check even though you don’t accept checks. Why? Because the instructions provided did not tell the child otherwise - thus the need for low-level details.
A good programmer will sit down with a client after determining these low-level details and ask questions, get answers, and put together a plan to ensure that the application will meet your expectations. There are so many variables at the low-level that no person could possibly put them all together unless you know exactly what you need from experience. This is where most problems arise, and this is easily avoidable. Before you sit down with your programmer create a simple bullet-point list of everything you expect and need the program to do. For example:
- Allow client to book appointment
- Choose from 3 different services
- Each service will have different available times
- Times are based on a 5 day work week
- Each service will have different prices
- Need to be able to provide discount codes
- Need ability to mark holidays as not available
- User needs to be able to select which stylist they wish to book with
- We wish to accept Visa credit cards only
- We need the following information:
- First name
- Last name
- Full address
- Hair color
- Hair length
Providing a simple list like the above gives your programmer a much better starting point to develop the low level questions that provide the details required to develop your project on time and on budget. It’s all in the details, and having those details will remove a lot of frustration that develops during a programming project.