Complexity in Web Development: A Simple Guide

On WPShout, a WordPress blog we run, I recently wrote about how long it takes a developer to do a number of discrete jobs in WordPress. The post was motivated by a great article at another site about how much a WordPress site should cost.

The main reason so few people discuss website pricing is because “a website” can cost literally any amount to build.

Both of these articles contain a lot of statements to the effect of, “These numbers are the best we can make them, but please don’t take any of them too seriously because they’re likely to be way off from your actual experience.”

These statements are true, and necessary. The main reason so few people discuss website pricing is because “a website” can cost literally any amount to build, depending on your needs for it.

You wouldn’t have the same problems in an article on, say, haircut prices—and an article like that wouldn’t take nearly as much audacity to write in the first place. Why is this?

A big part of the reason is complexity. Let’s look at that term as it relates to web projects.

Defining Complexity in Web Development

For a web developer, “complexity” can be defined as: Everything that is impossible or very difficult to know at the beginning of a project, and which only becomes clear during the project itself.

With complex web projects, almost the whole job is learning how to do the job itself.

The difference between a haircut and a web project is the degree of complexity. The job of giving a “men’s haircut” can vary a good deal based on the man in question, but the process is largely understood before it is begun, making it easy to price predictably.

With complex web projects, however, almost the whole job is learning how to do the job itself. That’s a lot trickier proposition.

An Analogy

Let’s examine complexity through an analogy to an activity with some similarities to web development: putting together jigsaw puzzles.

Let’s say you put jigsaw puzzles together professionally. Your clients want the puzzles put together as quickly and as cheaply as possible; they’re likely to hire the lowest-bidding puzzle builder, but they’ll also want the puzzle completed within that bid.

First, let’s ask what your job is. It’s not the manual process of putting pieces together. If you already know how everything fits together (say, if the pieces are numbered), then that process takes almost no time at all. What’s more, it can be done by anyone, certainly by someone much cheaper than you.

Instead, you’re being paid to figure out how the pieces all snap together—to work your way through the process of figuring out what you don’t already know. You’re being paid to wrangle with complexity.

Bidding on Complex Web Development Projects

The only thing you can do is guess, but you can guess with more or less skill.

So how do you estimate how long it’ll take you to resolve the complexity of a puzzle? If you knew the nature of the puzzle’s complexity, you’d already have solved it, and there would basically be no project (except maybe numbering all the pieces so someone else could snap them together for cheap). But there your employers are, wanting a firm number you’re ready to stand behind…

The only thing you can do is guess.

You can guess with more or less skill. Inexperienced puzzle makers are prone to throwing out a low number that will satisfy their employers, and then either abandoning the project or taking huge financial losses when the estimate turns out to be unachievable.

Experienced puzzle makers follow some established practices to get their guess as close as possible to the truth:

1. Look at what is known about the puzzle.
   Examining the image on the box—the finished product desired by the client—you may see one corner made of nearly uniformly colored clouds that you know will be a nightmare to put together, and another corner depicting a hill with a strong color gradient that will likely be a lot easier.
2. Look at past experience and make a conservative estimate.
   You may know that “most” 1000-piece puzzles take you around 12 hours to complete. However, those puzzles formed up into completely different images, and there’s no way to know beforehand how long it will take you to have the 999 small epiphanies that make up this job. What if the puzzle designer, in a bad mood, decided to divide those flat-colored cloudbanks up into 100 almost-identical pieces? You could be stuck for days. You’ll have to give your best guess and skew conservative—all without disgusting your clients so much they walk out. It’s a delicate process that never really gets easy.

Hopefully, this extended analogy has given you a bit of an idea what it’s like to bid on and execute complex development work. And, somewhat gratifyingly, I noticed that no one will give you a reliable answer for how long a 1,000-piece puzzle takes to complete—because of the complexity! So we’re on the right track here.

If you consider the differences between puzzles and web projects, you’ll realize that development work is significantly more unpredictable than puzzle assembling. For example, a web developer can hit dead ends, forcing him or her to rethink the final product itself.

Let’s take a look at some of the major sources of complexity in web work.

Sources of Complexity in Web Development

Developers often don’t know how to build a particular project until they’ve done it.

These are generic descriptions of some key reasons why developers often don’t know how to build a particular project until they’ve done it. There are doubtless many others, but these crop up all the time:

• Projects often require learning unfamiliar languages or programming practices.
  For example, a project may be complex enough that it requires a language framework such as Laravel to manage the data. The developer may need to budget for time to learn the Laravel paradigm, despite not knowing how difficult this will be.
• Projects often combine familiar elements in unfamiliar and untested ways.
  For example, a project may need to combine a home-built system for complex data storage and manipulation with WordPress for easy site administration. These two blocks of software may interact confusingly.
• Projects often must work properly across numerous dissimilar environments.
  For example, a website usually must work properly on numerous web browsers—each of which interprets HTML markup slightly differently, and some of which contain prominent flaws—and on numerous types of web-capable device, including computers, tablets, and smartphones of various sizes and resolutions. The steps needed to make all this work within a specific project usually only become clear during the project itself.
• Errors and setbacks are often nearly impossible to predict.
  For example, a web host may have a very restrictive memory limit or an obsolete version of PHP, causing significant problems when a site is migrated to it from other hosting. There is usually no good reason to suspect these problems before they happen, and there is no way to know how many of these types of problems will crop up and how difficult they will be to fix.

These fundamental sources of complexity are a big part of the reason why developers, acting in good faith, are prone to throw such crazy numbers around when they estimate a project.

How Complex is your Web Project?

Not all web projects are of equal complexity. Creating a simple site to display information about a small business, or a basic blog site, are both well-defined jobs with relatively little complexity. This means that it’s possible to predict how long they take and how much they should cost with much more accuracy than less repeatable projects.

Your web project becomes more complex as it requires more novel tasks.

Other projects are much more complex, and it’s hard to say much at all about them before diving in. In general, your web project becomes more complex as the number of novel tasks required to complete it increases. Anything a web developer has never done before is a pool of complexity.

Unfortunately, you, as a client, are not usually in a good place to judge what is and isn’t novel about your project. However, you can talk to a lot of developers and ask them what pieces can be handled using established practices, and you should start to get a sense.

In Conclusion…

Complexity makes web work unpredictable and very difficult to budget, but it’s also a lot of what makes it fun. Without complexity—without being paid to learn—web work becomes a race to see who can push buttons the fastest and cheapest. If you’re a developer and in the industry for the right reasons, that’s a race you want to lose.

I hope you’ve found this exploration of the dark, misty confusion of complexity simple and illuminating! If you have any questions or comments, I’d love to hear them below.