Framework Tradeoffs For Beginners: Product Creation vs Program Maintenance
Phil Sturgeon at his blog, writing about product creators who neither know nor care much about programming as a discipline:
One of my close friends … is also a businessman, with a startup that is about to launch. …
He does however have literally no interest in becoming a world-class programmer. He barely even wants to code, but he can thanks to frameworks like Laravel.
… He’s written an awful lot of extremely good applications - that work - and that has made him some money. Ship ship ship.
… Does he know what separation of concerns means? Ha.
Is his code SOLID? Nope.
Is the Laravel application he made unit-testable? … no.
Is it going to function well enough to get him to his next round of funding? Absolutely. Is he going to have to throw the whole thing away? Not at all.
Frameworks are great for beginners, who literally could not possibly smash together a series of random components if they wanted to.
Phil’s post focuses on the joyful, proud moments of creation that lead to business success, whether in terms of venture funding or continued sales. In this essay, I want to focus on what happens after that, when that initial creation passes into other hands to be maintained.
The Great And Awful Thing About PHP
The great thing about PHP is that almost anyone can use it. The language and some of the frameworks based on it, such as CodeIgniter and its most-recent ideological descendant Laravel, make amateur and early-career(*) programmers productive in ways they could not be otherwise.
But the great thing about PHP is also the awful thing about PHP, and that is that anyone can use it. The beginner programmer who has been made productive by his framework-of-choice feels great pride and elation at coding an application that “works.” Soon, though, the poor practices embdedded in his work due to his inexperience will find their way through to the product presentation and affect the business. The code “works,” but not so well as first thought. The codebase now has to be maintained in order to remedy the flaws and shortcomings displayed by the product.
If the beginner programmer is the one who has to do this maintenance, and is the one to feel the pain of maintaining his own applications, then he will learn to improve his development practices. If he instead goes on to other responsibilities, he will leave behind what is most likely a mess for others to inherit. Going on to other responsibilities is almost always what happens when the business gets its “next round of funding.”
What Happens After Funding
Phil asks if the business is “going to have to throw the whole thing away” at that point and responds in the negative. Well, of course the business owners won’t discard the codebase. It doesn’t matter how bad the code happens to be, because the entire business is now dependent on it as developed by that original inexperienced programmer. Throwing it out and starting again would likely kill the business. No, what will happen is that the funding will be used to hire a team of more experienced developers to fix, add features to, and scale the code developed by the beginner programmer.
Because they enable amateurs to operate beyond their existing capabilities, frameworks like CodeIgniter and its cousins tend to make product creation easier at the expense of making program maintenance harder. (Note the difference between the concerns of the product and those of the program.) Some folks will argue this does not matter. Once the product owner gets funding, he can pay professionals to deal with the problems he created on the way to his successful round of funding.
If You’re So Smart …
From a financial standpoint, and perhaps even from an economic standpoint, it’s easy to see enabling-via-framework as a positive. Indeed, the product creator may justify his failures of good programming practice by substituting the product popularity and continued rounds of funding as a marker of success. Complaints from the development team about the codebase quality are met with variations of “If you’re so smart, how come you’re working for me?”. But from a programming practices standpoint, enabling-by-framework too often leads to pain and frustration on the part of the maintenance programmers, who are now saddled with the baggage of an amateur.
“Well, that’s their job!” comes the reply. True enough, but that does not change the fact that the codebase is terrible and tough to work with. Think what a team of developers could do with a codebase built with better practices at the time of its creation.
Footnote
(*) If one considers a professional programming career to span 20 years or more, I think it’s fair to say a developer can be considered “early-career” even with as many as 6-7 full-time years of experience in the field.
Afterword
In my 30-odd years of programming (half of that in PHP), I have been the developer in charge of improving a maintenance mess so often that I am now writing a book about how to modernize legacy applications in PHP. In it, I give step-by-step instructions on what to do and in what order. I hope it can reduce the pain that others have to suffer with their own similar codebases. Sign up below for a free chapter, updates related to publication, and more.
Read the Reddit discussion about this post here.