Why SitePoint Lost Against Incremental Evil

“All that is necessary for the triumph of evil is that good men do nothing.” — Edmund Burke

As a codebase ages, its Software Brittleness increases, making it more difficult and expensive to adapt to changing market conditions, add new features and fix bugs. At some point, the ROI for almost any change can be negative, leading to a product that can no longer keep up with its market changes. This is its local optimum.

Some systems may get stuck in a rut that requires enormous effort to overcome the initial slump before reaching new heights.

To achieve the global optimum (here meaning best viable product possible), the cost of implementing new features needs to come way down. This can be done by reducing the codebase’s brittleness and inversely increasing its malleability.

One way to get there is by re-writing the system from scratch. And that’s exactly what SitePoint did in 2013: they overhauled the entire website and made not an evolutionary change to their product, but a revolutionary one.

The SitePoint Redesign

Here is a before-and-after shot of SitePoint’s article design from their big announcement post:

It’s easy to see that the old design was stuck in a local optimum and getting from the “before” design to the “after” design would have required the following hurdles to be overcome:

  • Convince the Social Media team to get rid of the Like / Share / Tweet / Email buttons
  • Convince the CEO to make the logo smaller (see: Make The Logo Bigger Cream)
  • Convince the Bookstore Department to remove the “NEW SITEPOINT BOOK. Read Chapter 1 FREE!” ad
  • Convince the SEO team to remove the bright red category links

Since requesting any of these things would generally be met with furrowed brows and rejection, the designers were able to avoid the problem by starting from scratch.

The final writeup says the redesign allowed them to:

  1. Focus the user experience towards the actual article content
  2. Be stylish and sleek
  3. Implement responsive design
  4. Improve site search
  5. Improve page load time
  6. Increase discoverability
  7. Engage in a two-way conversation

These were all admirable features, and the redesign came out quite nice. It had a clear focus on the content and removed distractions. It cleaned up the colour palette and made the UI simpler. It made the pages load faster and the search deliver better results. But there’s one thing it didn’t do: it didn’t stay nice.

“For The Leaves, They Will Wither”

SitePoint has not had a major redesign since then. However, their once clean-and-performant website has devolved into a mess of ads, anti-patterns, bloat, privacy invasion and content obscuring.

Here’s what a user sees when visiting that same page today:

Wow. Take that UI in for a moment. Think of how much it really meets its original goals. Ask yourself:

  • Does this UI focus on the article content?
  • Is this stylish and sleek?
  • Does the page load the main content as fast as possible?

Upon first glance, the answer to all of these questions is no. Here’s an annotated version of what the user gets to experience now:

All the sections highlighted in red are the parts of the UI actively pulling the user’s attention away from the actual content, highlighted in green. That’s an astounding signal-to-noise ratio, and is made worse by the other dark patterns at play:

  • Instantly asking for push notifications permission
  • Obscuring the article with a darkening screen and cold-pushing the ebook (with the mandatory surrender of personal email data)
  • Having a bright-red, full-width banner at the top of the screen (that sticks there when the user scrolls down)
  • Adding a countdown timer that can flicker in the user’s peripheral vision every time the seconds counter ticks down
  • Informing the user that if they click anywhere in the page, they’ll opt-in to cross-site ad tracking
  • Having three sidebar advertisements visible above-the-fold

This user experience when taken as a whole is objectively bad. But clearly nobody set out to turn SitePoint into that mess — it devolved over time, degrading the UX not all at once, but getting slightly worse, bit-by-bit. The term for this is Incremental Evil.

How Incremental Evil Takes Hold

These dark patterns, ads and distractions tend to get added one at a time, usually under the guise of minor conversion improvements, or to coincide with other promotions.

For example, when the ebook was released, the SitePoint marketing team probably asked to add the email nag modal (or even circumvented the ownership of the product and did it themselves using some injectable digital marketing system). With no real evidence for rebuttal, the developers were forced to accept the addition. One single modal was no big deal, right?

Then later, one of the higher-ups hears that many browsers allow sites to send push notifications right onto the users’ device — a lucrative marketing vector too good to pass up. So, the developers add the push notification prompt. Sure, it’s annoying. Sure, it adds another thing standing between the user and the content they came to see, but it’s still just a minor thing, right?

Even later, the SEO team wants to try an optimisation experiment to see if users want to find related tutorials by topic. Thus, once again, the developers are asked re-implement the big list of category links that were so boldly removed in the redesign. They do it anyway because the SEO budget is very large and it’s really just one small thing, right?

Defending Against Incremental Evil

As the old saying goes, the water heats imperceptibly until the frog boils to death. In SitePoint’s case, it was the usability, simplicity and performance of the UI that was slowly eroded until site visitors were treated to an all-out assault on their attention, bandwidth and tolerance.

But why did this happen to SitePoint, and why do so many other software products experience this quality rot? I think the answer lies in the incremental nature of these changes and the lack of fundamental strategic principles.

If SitePoint’s designers and developers had a set of fundamental strategic principles, they could have been more effective user champions in the face of well-meaning but incrementally-evil changes.

I submit that a user champion need not be a person, but perhaps a written document. Such a document could define (in whatever detail) the framework and ground rules that a project or system must adhere to. With the right authority, such a document could assist in the prevention of quality rot and ensure that great products stay great.

A written artefact that underscores the fundamental guiding principles of a system, product or project can take many forms. There are several recognisable analogs throughout the history of society and business.


For centuries, nation states would write a Constitution; a document outlining the rights and rules by which all of its citizens must abide. The contents of these documents could be purposefully high-level and concerned with holistic governing practices, usually concerning citizenship, liberty and justice.

This mandated that legislators write laws which fell within the legal boundaries set out within the supreme authority of the higher-ruling constitution. Any single actor (such as a malevolent local governing body) who attempted to pass through legislation that would erode the rights of the citizenry would find that their laws were unconstitutional and would therefore be unenforced.

Thus, the constitution was the written artefact that functioned as a written user champion, surviving successive governments and social revolutions to protect the citizenship and keep the nation aligned with its ideals.

User Stories

In Agile software development, a user story is a tool used “to capture a description of a software feature from an end-user perspective. The user story describes the type of user, what they want and why”.

The rest of a feature’s requirements and subsequent implementation are subject to the fulfilment of the original user story’s expectations. No matter what is built, if it doesn’t meet the expectations of the user story’s hypothetical persona, the work must not pass QA.

Performance Budgets

The digital design and UX movements are slowly coming around to the idea that performant, responsive interfaces are a worthwhile UX endeavour[15]. Some even go so far to say performance is a feature. Some case studies show a financial benefit to increasing the speed of webpage load times[17].

Instituting a performance budget for a cloud product will force web designers and developers to consider the bandwidth, latency and operational performance of their product. This manifests itself in things like compressed assets, reducing download and parse times, minimising the use of font faces and ensuring the UI is never blocked by some expensive task.

All these things together ensure the user is delighted with their experience using the product, in addition to the features of the product itself.


There is a great case study to be found in SitePoint’s relapse of quality rot. If you notice a product, system or interface being slowly degraded by ads, dark patterns or other stepwise degradations, communicate your frustrations to the vendor. Ensure that products you or your colleagues are building may not fall victim to incremental evil, and always advocate for the customer — they’re the ones who matter the most.

For more information about what should go into a user-champion document, keep an eye out for Part 2 of this post; coming soon.