The State of The Blog

This blog is written in Gatsby, which is itself written on React, GraphQL, WebPack, and a whole host of other JS technologies that honestly, I do not know nearly well enough to trust my public face to. Don’t get me wrong, it’s not that Gatsby is bad — it is actually pretty awesome. The problem is one that I find incredibly common with all JS development, and that is that every time I need to upgrade something, or any time I try to move to a newer version of Node or NPM, everything in the entire application goes pear-shaped, and requires a whole hell of a lot more expertise than I possess to hammer it back into reasonable shape.

In short, this blog has fallen victim to exactly the same pattern of technical debt that I routinely warn my clients against. It started out with me pulling a really neat, fully-featured Gatsby template from the truly talented Greg Lobinsky, quickly adding in the features I wanted to see, adapting it so that I could serve it outside of Netlify, and in some cases ripping out stuff that I didn’t need. This worked fine to get something up and running, but then, when I tried to add a simple “Contact Me” page, things got very difficult very quickly.

In my job, I take it upon myself to evangelize Test Driven Development. I do this because I’m convinced that if you remove every other Agile practice except TDD, you still do a lot to improve code quality. And, conversely, if you embrace all other Agile practices except for TDD, very often you’ve done nothing more than find a more efficient way to dig yourself into a deep hole of technical debt. I speak from experience on this one.

So why don’t more companies use TDD? Well, frankly, because the people who hold the purse-strings in any company are usually the kinds of folks who pay the kid down the street to help install their home router. They probably still own VCRs for all I know. One thing I’m sure they don’t know is technology, because most of them make such uniformly bad decisions in this area.

Here is how most companies develop software: they start out with a small bit of code that they can get up and running quickly. Then they glom additional functionality onto this nugget until evenutally the system metastasizes out of control. The resulting system, more often than not, resembles what happens to Tetsuo at the end of the movie Akira.

As you can see in the above graph, the apparent up-front cheapness is an illusion. Over time, systems built without TDD become more expensive to maintain. And they eventually can even become unmaintainable.

Companies become addicted to cheap up-front delivery, because it gets stuff out the door quickly. There are often good reasons to accrue technical debt, just like there are often good reasons to take on personal debt. Like, you may want to buy a house without having to wait twenty years. But that debt needs to be managed, and all too often our technical managers ignore debt and allow it to grow out of control.

With Test-Driven Development, you are making an initial investment in code quality. You are taking step-by-step measures to make sure that design choices are well understood, and that any refactoring doesn’t break existing functionality. The results of such a process make your initial deliverables feel underwhelming at best, but the long-term results are that you can deliver a much better product that has few, if any, issues in production.

The curve above shows how TDD starts far more expensive, but then actually gets cheaper over time.

The important thing here is that, at some point, TDD pays for itself. James Shore suggests that the break-even point happens somewhere between four to eight weeks. I believe for most teams, who may be very immature in Agile practices, this is probably a bit on the optimistic side. But even if it takes a full six months (a pessimistic extreme), the cross-over point between the two graphs will happen, and every economic decision after that point favors the teams that have been disciplined in their use of TDD.

So to return to the blog, I have nothing against Gatsby, or React, or GraphQL. They are fine in and of themselves. The problem, really, is that at the moment, I spend far more of my time talking to teams about coding than I spend coding myself. Because of this, I feel like I have two choices for my blog: 1) I can move over to a reliable, turnkey blogging solution like WordPress, or 2) I can back away from my JS framework hell and embrace a simple, provably-correct blogging solution that I build myself.

Honestly, I may do both. Sorry Gatsby, but you are much more complicated than what I need right now.

So if you tune in one day and this blog feels like it has taken an enormous step backward in terms of look and feel, this is why. I love the way the current blog is styled, and eventually I hope to recapture most of what I have here, but the first order of business has to be getting rid of all the cruft that Gatsby brings and getting back to a simple, maintainable design.

Wish me luck!