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

Post from June 7, 2011 (↻ May 2, 2017), reflecting Jens the Developer.

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

For any given project, web developers fare best when focusing on what is, not what could be. To fend off the first 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 has only 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 alone, 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—sometimes people struggle with that distinction) 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 follows the tailor metaphor I introduced around frameworks: You will 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 50 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 might like 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.

About the Author

Jens Oliver Meiert, photo of July 27, 2015.

Jens Oliver Meiert is a philosopher and developer (Google, W3C, O’Reilly). He experiments with art and adventure. Here on meiert.com he shares and generalizes and exaggerates some of his thoughts and experiences.

There’s more Jens in the archives and at Amazon. If you have any questions or concerns (or recommendations) about what he writes, leave a comment or a message.

Comments (Closed)

On June 7, 2011, 19:31 CEST, David said:

I’d like to see a TED talk (or similar) video in the future from you Jens! You have a way of getting to the gist of things with brevity. It’s always inspirational to see someone with clarity elaborate their ideas with succinctness and belief as you have here and have done in past posts. I want to see you talk and teach for an hour, or so, on the principles you preach. Keep doing it! You’re the chlorine in the proverbial pool! 😊
On June 10, 2011, 3:29 CEST, Marco Pivetta said:

I just wish to oppose my opinion when it comes to complex projects with long term deadlines…
I’ve been working on dozens of websites which were continuously adding features, and features and more features.

That can become something like a big assassin blob which will kill the project and force rewriting from scratch.

I usually work on the programming side, as the design work is quite fast if you keep templates as clean as possible, but in my opinion I have to plan dozens of features! Even if I don’t implement a half of them, I just mock them or write some interface that represents their base ideas and enforce all the project to follow their principles.

That allows me to have a project where people are constantly aware of future development, and I never (or almost never) reach a point where the customer asks me something I didn’t intercept before in an “interface” or “mockup”.

This kind of development is also strictly related to the fact that I tend to reuse my code everywhere, improving it in every project a bit, and in new project I take a huge advantage from all the ideas that came from the preceding ones, without loosing any possible feature. Even if not yet implemented, it’s there and we’ve written down the base concept that has just to be implemented 😊
On June 10, 2011, 22:08 CEST, Rob Huzzey said:

Whilst I do see your point, I also do see the need to code in such a way as to be flexible to changes in scope.

If this means adding a few extra lines to make it easier in the long run, I can’t see an issue.

There’s no need to go crazy adding in loads of features you will never use, this I agree with, thats just common sense.

I’m just saying code modular, code so you can add features in, if no extra features are added, yes your code is pointless, but have you ever worked on a project where scope didn’t change?
On June 10, 2011, 23:41 CEST, Roger Flanagan said:

The concept of coding for what is there is amazing in theory and would work for standard brochure sites. Most of the time a client can’t tell you everything they want or need until they click around on a live site. You should always code for what could be. I’m a front end developer and speaking from experience a client will always want to add an additional paragraph or one more contact button so always code with that in mind. Excellent article, I just haven’t met too many clients where this method would make sense.
On June 13, 2011, 19:38 CEST, Jens Oliver Meiert said:

Thanks David 😊

Marco, I’d be curious learning more about your project environment. From what I understand you have a good understanding of what’s coming your way, and correctly apply other development practices like modularization.

Rob, project scopes do of course change, sometimes in a healthy, sometimes in an unhealthy fashion. The more they change though the more useful it will typically be to stay close to the “what is,” even when that is just a snapshot 😊

Roger, I see where you are coming from and I’m also aware of that situation in practice… it’s just an incredibly expensive one, one one needs to get out of as soon as possible. It’s hard to hit when you don’t have a goal and in the situation you’re describing, defining goals and committing to them will probably be the first things to aim for. I hope the environment you’re referring to actually permits that.

Have a look at the most popular posts, possibly including:

Looking for a way to comment? Comments have been disabled, unfortunately.