Principles of Web Development

Published on February 16, 2017 (↻ September 10, 2024), filed under Development (RSS feed for all categories).

The predecessor to this article appeared at iX (German).

Web development, at more than 20 years of age, is becoming an increasingly mature profession. Web development is yet also subject to constant change, and the field produces more of that change, out of itself. More technological standards, possibilities, and practices; standards, possibilities, and practices that have attracted, but also frustrated us, the people in the field. But as many have observed, more recently perhaps Jeremy Keith in his Design Principles, there are principles for us to hold on to.

As a veteran developer who has worked on small to large-scale projects, and who has contributed to standards (W3C) and written about best practices (O’Reilly), I like to offer an updated, more tangible view on these principles. The principles that follow have guided some of our work in the past, and they are likely to serve us well going forward.

Contents

1. Focus on the User
2. Focus on Quality
3. Keep It Simple
4. Think Long-Term (and Beware of Fads)
5. Don’t Repeat Yourself (aka One Cannot Not Maintain)
6. Code Responsibly
7. Know Your Field

Focus on the User

No matter how deep we are in the trenches, we must first of all focus on the user. That is a Google principle for very good reasons, and may make doctrine for us as developers, too.

Yet—do we, as developers, even have users? Who are our users? Are our peers users? That leads us to two answers, and two user groups. Our peers, other developers, likely our team mates, are indeed users of our code. But everyone using the systems of whatever our code is part of, are also our users. And so for websites and web apps, different as they are, those sites’ and apps’ users are also our users, and those we need to focus on.

Many of us will nod, and we soon see the link more clearly. Accessibility, for example, is for end users, and much depends on developers. Code performance is measured from the end user’s end. And some functionality, even (or especially) around trivia like functioning links, also connects developers and users. One can say, indeed, that only design-related questions can create obscurity here—usability tests are about end users, but don’t necessarily affect us developers.

How do we focus on the user? By two means:

1. Setting up and enforcing coding standards. (For a start, see styleguides.io, cssguidelin.es, or perhaps my own book on coding standards, The Little Book of HTML/CSS Coding Guidelines.)

2. Focusing on quality:

Focus on Quality

This principle is what distinguishes the expert from the amateur, the professional from the hobbyist. Everyone can hack together a website—and we all know what that has done to our field—, but few can create a high quality one.

Focus on quality is abstract for it doesn’t come with clear directives. What we end up with is the need to cultivate a mindset of quality, set goals around quality, and implement (or develop) tools to measure and improve quality. That is easier said than done, hence the problems we face here, the need to raise awareness, and the necessity to make use of quality-related tools.

The takeaway here is best phrased as a double-question, to ask ourselves regularly: How can we tell how good our work is, and how can we make it better?

(Bonus: The quality-conscious, ambitious developer may wish to aim for excellence, somehow one-upping the quality principle. I want to call out the idea of excellence explicitly because at times our field has a tendency to sloppiness, a tendency we might be able to overcome if we pushed harder on excellence.)

Keep It Simple

There’s barely a better principle to adhere to than simplicity. It’s followed by the observation that less is, indeed, more. But why? Doesn’t “keep it simple” have a rather cheap ring to it, the ring of a catch-all phrase, tossed at us anytime someone aches to be witty?

Far from that. True, few people may really understand the power of and how to best utilize “keep it simple.” But when understood, that power is one to be reckoned with. It comes from knowledge of what matters and what doesn’t. Not keeping things simple is saying that everything matters; while that may occasionally be true, most of the time it’s not.

Similar to our focus on quality, keeping things simple is abstract. We can’t generally list everything that matters, for that depends on the context as well as the goals. Keeping things simple requires focus and experience. From that follows, however, that our growing focus and experience, and our knowledge of context and goals help us adhering to this important principle.

Think Long-Term (and Beware of Fads)

Next on our list of proven principles is long-term focus. This one isn’t easy to grab, either—we might well suspect that our principles work so well precisely because they’re a little broad and fluffy, and that they don’t absolve us from thinking and working. Long-term focus demands from us to go about our projects in a planned, sustainable fashion. That’s a good prompt to start listing what long-term thinking does and does not entail:

• looking into high quality content and service (and looking beyond campaign and landing pages);
• creating designs that are usable and appealing (and improving them through iterative processes);
• writing code to last (and making it maintainable, starting with avoiding code with a high chance of short- and mid-term changes);
• certainly, passionately rejecting “fire and forget.”

What else exemplifies long-term focus? How do we acquire, how do we instill it? Probably starting by noting how the opposite, short-term thinking, is costlier through all the extra work it causes—which, incidentally, brings us to the next principle:

Don’t Repeat Yourself (aka One Cannot Not Maintain)

This probably most important maintainability principle is so important because it significantly reduces the number of places as well as the amount of code that needs to be maintained. In the realm of style sheets, for example, we early observe a reduction of 20–40%, and with that a drastically decreased need for CSS variables (which, alas, has led to nothing). These savings don’t just materialize as less code–they also mean less time spent on maintenance.

Repetition can be avoided from two angles. One consists of avoiding actual code to be duplicated; the other in avoiding files to be duplicated. Both can be approached the same way: If it already exists, there should be a way not to produce and store (and maintain) it again. How do we go about this? Through awareness and diligence, and through automation. The former can’t be helped effectively here, and there seem to be no dedicated tools to prevent repetition.

The principle to be violated here: Don’t repeat yourself.

Code Responsibly

What the Code Responsibly campaign (disclaimer: I had initiated the project) has been promoting for many years, represents an important mantra: Web development means responsibility.

That responsibility concerns both ourselves and others, where others are again colleagues, shareholders, as well as users. The Code Responsibly initiative propagates learning, accessibility, performance, semantics, validation, maintainability, collaboration, documentation, quality, and teaching as key parameters; responsible web development, however, simply starts with a commitment to quality and professionalism.

What quality means we have discussed; for professionalism, this begins with common attributes like knowledge and skill, judgment and competency, as well as integrity and manners, and leads us back to the principles here, notably focusing on the user, thinking long-term, and knowing the field:

Know Your Field

The last important principle is to know our field, its neighbors, and its boundaries. At this point we all learned to do without specifics, that we need to do this work by ourselves.

Our field should be pretty clearly marked by web standards and related best practices.

The neighbors are everything that serves the usefulness and quality of the websites and apps we code—this begins with design (information design, interaction design, typography), involves usability and user experience, passes over accessibility, touches on psychology and human-computer interaction, and really kisses everything our sites and apps are about, for a technically healthy website is independent of its contents, but a great website blurs that line.

Non-blurred lines, and boundaries, we must be aware of, too, most notably when it comes to user agents. Our field has made some unnecessary and because of that silly ventures into that realm, with people trying to take on distant accessibility as well as user experience concerns. We need to know when something truly is our problem: Just because we can, doesn’t mean we should.

❧ Although we’ve seen that our principles are abstract, we better be careful with absolutes and truths. Web development is much about probabilities, and mileage may vary even for comparable projects. The principles we’ve looked at here—from user focus to knowledge of the field—give us direction and help making better decisions. What direction we go, and what decisions we make, is still something that’s up to each of us. Web development is meaningful.

About Me

I’m Jens (long: Jens Oliver Meiert), and I’m a frontend engineering leader and tech author/publisher. I’ve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, I’m a contributor to several web standards, 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. (Please be critical, interpret charitably, and give feedback.)