The article is confused and self-contradictory. It advises:

1. Punt on complexity
2. Plan for changing requirements

Planning for changing requirements often introduces more complexity than not planning. That's the essence of the much-loved YAGNI and WET principles.

The article seems to imply that using a frontend web framework, SQLite, and an ORM both introduce complexity and fail to accommodate changing requirements, and that this was the result of the programmer's inability to complete their project both within deadline and up to high standard.

I'm not aware of any world in which this is true. Web frameworks, SQLite, and ORMs are flexible tools that encapsulate a lot of complexity. Their entire purpose is to make apps less complicated, by allowing you to reuse existing functionality, abstractions, and interfaces that the app dev does not need to develop, test, and maintain.

> You start typing faster, but you also start skipping clean coding patterns. Your functions become more coupled, you directly call external libraries all over, and you skip writing any unit tests. Along the way you also cut and modify scope all over the place, hacking your initial spec to pieces.

The article author then says:

> I firmly believe writing clean code is just as fast as writing messy code - though it may take more experience and wisdom. Quality software is soft - easy to remold. Let’s take another look at our to-do list from earlier, but implement it a little more cleanly this time, and make it more malleable.

But that's clearly not the case. Otherwise the developer in the story wouldn't have felt the need to cut corners on clean code in order to get a working product delivered on time!

> initially implement the entire datastore as a JSON blob written to disk.

That's clean? That's punting on complexity? Is that really the reason that the developer didn't meet their deadline? Have fun with all the DIY tooling and testing around that system.

Yay, we anticipated one particular direction of growth. Now just as you're finishing migrating the entire storage backend to the JSON blob thing, the same PM shows up and tells you that the UX team is pissed off at how slow sorting and filtering got in the new version. Can you make it as fast as the old one? Oops, you blew it.

Meanwhile if you had just stuck with the ORM, you could have migrated your storage backend from SQLite to MySQL and kept the rest of the app more or less identical.

> You’ve just saved yourself a day of fiddling with a database and reading docs on an ORM someone else built.

That's just nonsense. Don't pick new-to-you tools for short-turnaround projects. If you must do so, then you have either have unrealistic deadlines or are unqualified for your particular job.

You could of course forego the ORM and write raw SQL strings. Does that solve anything here? No. Does it somehow make your code cleaner? No. Does it make the process of writing clean code faster? No. Does it make the author happy? Apparently, but that's not relevant at my job.

The reason that writing clean code is (sometimes) slower is that writing clean code requires planning. People have this weird idea that planning is not agile and agile is not planning, so people don't plan out their code. A similar topic came up in a thread the other day about Dijkstra, but it bears repeating here. Your design process does not end once you've chosen your tools and drawn a couple of arrows on a cocktail napkin. Do you have at least a rough idea of what interface boundaries will be needed? What is your testing strategy? Do you even know what the important invariants of your system are, or which pieces of functionality might need to be tested? Do you need to implement any "algorithms" that can be implemented as pure functions? How do you intend to represent the data? Does that representation work well with your chosen storage backend, or will you need to do some kind of transformation between the database and the app? Etc.

All that stuff is a whole lot more important than fussing over whether you've spent too much time reading library documentation. You can write just as much of a spaghetti platter mess with or without 3rd-party libraries.

The article is not providing any useful advice for avoiding the spaghetti platter. It only asserts that a tangled linguine platter is better than a tangled spaghetti platter.