Solving the wrong problem

I've blogged about Problem-driven design, then followed up with Problem-driven vs Domain-driven.

Let's take a look at a more concrete example.

We'll use this blog as an example of a technically correct solution that solved the wrong problem and actually sabotaged my writing efforts. Then we'll check out another project that has achieved a different outcome by focusing on a different problem.

The story is split into two blog posts.

Good solution

This blog has a long history. It started somewhere on Livejournal, Blogger, and WordPress. After getting tired of WordPress maintenance, I moved to Squarespace. Sometime later - to Hugo, then to a static website generator written in node.js, then in Python. The story is captured in Blog Migrated to Python.

From the operational perspective, the current setup is perfect. Content and the code are versioned in git. Python code runs a few hundred content files through the templates to generate a static website. Files are uploaded to S3 and served via Cloudflare CDN with edge servers across all major countries. Amazon handles the DNS, domain, and certificate renewal.

I'm a software engineer, so I optimized the solution to some degree of perfection. The maintenance overhead and the costs are negligible, the scalability - unlimited. It never goes down.

Wrong problem

This "perfect" solution has an issue - it solves the wrong problem.

While chasing the surface problem "Make it scalable, cheap, and low-maintenance", I forgot about the original purpose of the blog: to publish stuff and learn through that process.

When in doubt, consult the metrics: there were just 3 blog posts published in 2021 and 5 blog posts in 2020.

Clearly, this setup doesn't help me to publish blog posts more frequently.

This is an example of what happens when you solve the wrong problem: the solution is valid from the engineering perspective, but the overall product is useless.

Ugly outcome

Let's dig into the writing workflow for the potential clues.

I have an idea for a blog post, something to share. I go to the work folder, navigate to content/ and notice that the git state is dirty from the last time.

Ok, time to commit previous changes. This will require reviewing the changes and writing an appropriate commit message. Meanwhile, the original idea faints away.

Blog posts are stored as markdown files with YAML front-matter. So I need to create a new file. How should it be called? What should be the title?

When the editing time comes, I'll need to keep in mind the original idea, the Markdown syntax. Where should I put that image attachment? What was that markdown syntax for the images?

Why did I pick the markdown syntax? Because it is popular and makes it easy to edit existing text. The truth is - I rarely edit something that was published.

I published something, but the changes don't show up. Ah, I need to invalidate Cloudflare CDN caches to see the changes online and share the URL. Let me log into the AWS console and find my way around.

Ouch, there is an embarrassing typo. I probably need to edit the file, publish and then invalidate caches again. Also, don't forget to commit changes to the git with a meaningful name.

Little by little, these tiny distractions nibble away at the original blog post idea and inspiration. Until I throw up my hands in exasperation and switch to something else. This also leaves the git repository in a dirty state.

As such, I have published just one blog post every 4 months (on average) in the last six years. There are quite a few unfinished posts as well.

How could we solve the underlying problem?

Let's recap. We want to encourage writing and publishing more frequently. To optimize the entire flow for my specific constraints: limited brain capacity, little time, plenty of distractions, and interruptions.

Not a problem: ultra-low maintenance, high scalability, and low-effort editing of the existing blog posts. From this perspective, the software stack is less relevant than the user experience.

Follow-ups

• I'm getting rid of Google analytics on this website: Lean web analytics
• We take a look at another writing project of mine that focused on different problems and achieved better results: Solving the right problem.

Published: January 06, 2022.

Next post in Opinionated Tech story: Solving the right problem

🤗 Check out my newsletter! It is about building products with ChatGPT and LLMs: latest news, technical insights and my journey. Check out it out