Web Development Principles: Develop for What Is, Not What Could Be

Published on Jun 7, 2011 (updated Dec 14, 2024), filed under development (feed). (Share this on Mastodon or Bluesky?)

This and many other posts are also available as a pretty, well-behaved ebook: On Web Development.

For any given project, web developers fare best when focusing on what is, not what could be. To fend off misunderstandings, that focus includes what absolutely will be.

The reason for this principle is that you are not a psychic. That is, you may think that your site might feature a 12 column grid in the future, but if the mocks in front of you say it’s 8, it’s 8, not 12. If it only has one page type you don’t need two. If it doesn’t use tables you don’t need to style tables. Again: ignoring what could be doesn’t mean ignoring what will be, and that means if the designers you are working with are assuring you that the next site iteration will sport 12 columns, it would not be smart to ignore such probability.

What happens when you are not focusing on what is is that you are increasing cost, are introducing complexity and, eventually, technical debt right from the start. That is, documenting and explaining all the extra features you included in your site’s prototype cost money by the work you’re spending on it, then by its implementation, and also by the added maintenance cost going forward. Developing for what could be will make it more difficult (note: more difficult does not necessarily mean difficult—this distinction is important) to work with your project. Eventually, though we touched this with added maintenance cost, you are forced to carry around stuff that is not used at all and that hence just stands in the way when working on what is actually relevant.

Having an eye on what is reflects empiricism, which also informs the tailor metaphor I introduced around frameworks: You want to strive for the best possible solution and that means tailoring to actual needs. A good tailor will give you a little bit of extra room for your belly—and so will you give your design and code some room to grow or shrink a little—but he will not hand you a tent just in case you gain 100 pounds.

People working with me and people following my posts have heard me say this a few times: A good part of web development is about dealing with probabilities. You know that I’ve covered other principles in the past—see the most popular posts of this site—and that it’s likely that I’m going to talk about principles again.

Update (December 14, 2024)

I only realized later how this thinking corresponded with YAGNI.

About Me

I’m Jens (long: Jens Oliver Meiert), and I’m a web developer, manager, and author. I’ve been working as a technical lead and engineering manager for companies you’ve never heard of and companies you use every day, I’m an occasional contributor to web standards (like HTML, CSS, WCAG), and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development and engineering management, but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (I value you being critical, interpreting charitably, and giving feedback.)