Many of my clients have wasted money they spent on programming. I try to tell them how not to, even as the beneficiary of some of this waste. If they insist, though, at some point there’s nothing left to do but shrug and accept a bit more cash in my pocket.
The thing is, like most creative professionals, I like to do new and exciting work that efficiently solves problems way more than coding up the first iteration of some idea that is going to require many revisions before any of value results. That means if I make less money per task, but my client gets more value per dollar, I am actually far more likely to have that client come back over and over again.
In order to reach that sweet spot, here are a few things you, as the client, should know about programming.
Knowing will save you money by reducing how long things take to get done. It will also mean that the money you do spend produces features of your website or application that have more value.
- 1) How easy or hard it is to program a feature usually depends on factors other than what the end user sees.
- 2) The easier it is to use a new feature, the more work probably went into it by the programmer.
- 3) Estimating programming tasks is very difficult, especially the more vague the task description is.
1) How easy or hard it is to program a feature usually depends on factors other than what the end user sees.
There are multiple layers that go into building a piece of software or a feature on a website. Using website terminology, what the site visitor sees is what we call the user interface (UI). For example, a recent project has a UI requirement to display headshots of the cast for an event. The set of headshots might have color-tinted photos with the actor’s name displayed on the bottom and some sort of rollover effect that slides in from the bottom when the user hovers or taps.
The client needs to have a pool of actors and be able to build “teams” that can be attached to events. The headshot photos may have many purposes, so they won’t necessarily have a uniform size or aspect ratio.
Without diving too deep into what’s required, here’s a quick list of just some of the programming tasks required:
- Provide a way for a site manager to create team member profiles with a large headshot photo.
- Provide a team builder to group team members into ordered lists and note their roles on that team.
- Create a way to easily place that team on a page for display, along with a few options to allow for different usages.
- Crop the provided headshots to the right size and aspect ratio.
- Style the output to account for converting the photos to tinted grayscale.
- Accommodate different screen sizes and devices so that the final output looks good whether on a desktop or a mobile device.
These are only some of the tasks. During development, many other tasks have revealed themselves as necessary, most of which may have little to do with the final display seen by the site visitor but are necessary to making sure the feature not only works, but is efficient and doesn’t slow down the user experience.
When I’m building a feature, my first pass is usually to get something that works at all.
It’s like how an electrician gets a heavy cable run through long, narrow passages between walls in a building without tearing out all the walls first. He’ll tie a string to some small heavy object and throw it through the passage. Once that’s through, he’ll tie it to ever larger twine, rope, or cable to pull through the bigger lines until he has the cable he really wants in place.
I’ll build an end-to-end system that basically proves it works, then revise my code to make it better. Better in this case can mean faster, incorporates error checking, handles oddball or “edge” cases that don’t happen very often, or producing an optimized user interface. Given sufficient time to improve and polish, a feature that on the first pass is merely serviceable but clunky becomes a nice, slick UI that is trivially easy for the user.
Sometimes, this process can backfire a little if the client isn’t prepared. For example, seeing something really easy to use is often converted into a false equivalency that it was was easy to build. That’s actually backwards, in reality, easy tends to be hard.
A good programmer will explain this along the way but if the one you’re working with doesn’t, be sure to ask. Having the list of tasks from the above point can help guide that conversation.
3) Estimating programming tasks is very difficult, especially the more vague the task description is.
Imagine you’ve been in a car accident and you need your car fixed. Will you just send a photo of the car to your mechanic and then expect a proper estimate of the cost to fix it?
Good luck with that.
A sharp mechanic knows s/he can’t guarantee anything about the cost because there’s no way to determine what’s really wrong beyond obvious cosmetic body work. The mechanic’s smart move is is to either refuse an estimate or just give you a price based on simply replacing the car with a new one…then follow up by asking you to bring the vehicle into the shop.
Programming is similar and this final point is really the confluence of the first two.
If you’re vague about what how a feature needs to behave or the problem it’s trying to solve, set aside some of your budget to have the programmer perform a thorough examination. Opting against that almost always leads to much higher end project costs. Sometimes much higher.
think of it this way, you’re basically asking for a definite price for an indefinite task. In that scenario, the programmer can only protect him/her from future indentured servitude by quoting a price that covers the higher end of the potential range.
One common result from failing to prepare this way is you end up with a programmer that drops out of existence. to that end, here’s the process you want to avoid:
- Client gives vague requirements.
- Programmer quotes a price that ends up being too low for what the real work requires but the client believes s/he has a budget friendly fixed price.
- Programmer discovers the unfolding workload will, at the original price, result in working for less than minimum wage to honor.
Although the programmer should go back and renegotiate, that can create hard feelings. Instead, the sad reality is too many programmers go into passive aggressive mode dodging calls and waiting for the client to give up and go away.
By that point the client is really in trouble and ends up paying another programmer rush rates to get the new feature up and running.
Programmers are in high demand. That means their time is expensive. But not unlike a lot of fields with highly skilled professionals, it can also mean that their are plenty of charlatans out there, eager for extra income at the expense of the client.
But you can protect yourself, develop stronger working relationships with programmers, and be more efficient by following these three points.
As a bonus, you’ll begin to easily spot those that don’t know what they are doing or are happy to play ignorant at your expense thanks to not being able or willing to answer the questions or complete the research you might pay for up front.