Confessions of an Ecommerce Developer

Web developers, like other professionals, must overcome habits and opinions that they’ve acquired over time.

Web developers have standard processes and techniques to get their jobs done. They also have informal habits and opinions that influence their work — the kinds of things that no one is formally trained on but picks up from peers over time.

In this article, I’ll share a few common beliefs from developers that I’ve experienced — as a developer — since 2004. To be sure, not every developer shares these views.

Confessions of an Ecommerce Developer

Perfect features are impossible. You requested a feature from a developer, he finished it, and it’s nothing like what you wanted. This occurs all too often.

Building software that does exactly what someone wants is extremely difficult. It’s rare that it is right on the first try. Even when I’m working on my own software, many times a feature doesn’t end up exactly as I planned.

There are, typically, two root causes to this: failure in communication and not enough resources.

Communication failures occur when a client doesn’t share enough information with a developer, or maybe a developer didn’t ask a critical question, or maybe even the data that prompted the project was flawed.

The other cause is scarce resources. I often think that if I had infinite time, money, and people, I could create software to do anything.

In the real world of business that’s not the case. There’s a limited amount of time, money, people, and computing resources. Given those constraints, sometimes the feature just can’t be done as requested.

Thus, developers adopt the view that perfect features are impossible. But there is always room to improve communication with your developer. More resources will almost always help, too.

Never enough time. Another common feeling among developers is that there is never enough time.

• As the deadline approaches the feature gets rushed.

• The development was more difficult than anticipated and went over budget.

• There’s only enough time for an average job. An exceptional job will take longer.

• Bugs or bad data complicated the original feature. The developer must spend more time or deliver it with bugs.

• The client changed the feature request, creating wasted work by the developer.

There are many scenarios that lead developers to think that lack of time is the problem. In reality, each scenario is a different problem that can be solved in different ways.

Make it clear to your developers what would make a feature successful. If, say, three of the five options are ready within a week, is that good enough? Communicate that to your developers.

The code worked, but it should not have. Sometimes code works that, by all reasoning, should not. It’s a pleasant surprise to developers, but it can produce negative feelings. They see it working but they don’t understand why.

Sometimes this is related to inexperience or a lack of information. But other factors can cause it.

This is common with bugs, for example, wherein the client reports a bug, but then someone else fixes it without telling the developer. Then the developer can’t reproduce the problem and thinks it was a bad bug report.

When this happens, I try to test it more completely to make sure that it actually is working. If it’s good, then I shrug, count my blessings, and move on.

When a developer believes the bug is corrected, have her spend extra time testing it, to make sure. The extra testing time is almost always worth it.

Software systems are inherently unstable. One of the ironclad beliefs shared by experienced developers is how unstable software really is. It is seemingly a miracle how everything works together, and that it actually does function.

There are stories about popular and successful software systems that had someone behind the scenes rebooting the severs every hour just to keep it online. (Those stories didn’t come out until later, after the companies were successful.)

So a change that crashes your entire store is almost normal. The instances where everything always works are abnormal.

Experienced developers have created processes and tools to help stabilize software systems. (I addressed one last month, in fact, at “To Prevent Software Failures, Use Automated Testing.”) Ask your developers to use those processes and tools, recognizing that they will only improve stability, not guarantee it. Even Amazon has site-wide crashes.