Web Development Principles: Develop for What Is, Not What Could Be
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.
I’m Jens, and I’m an engineering lead and author. I’ve worked as a technical lead for Google, I’m close to W3C and WHATWG, and I write and review books for O’Reilly. I love trying things, sometimes including philosophy, art, and adventure. Here on meiert.com I share some of my views and experiences.
If you have a question or suggestion about what I write, please leave a comment (if available) or a message. Thank you!
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! 😊
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.
Maybe this is interesting to you, too:
- Next: Print Style Sheets and URLs
- Previous: Exposing Reset Style Sheets
- More under Web Development, or from 2011
- Most popular posts
Looking for a way to comment? Comments have been disabled, unfortunately.
Get a good look at web development? Try The Web Development Glossary (2020). With explanations and definitions for literally thousands of terms from Web Development and related fields, building on Wikipedia as well as the MDN Web Docs. Available at Apple Books, Kobo, Google Play Books, and Leanpub.