On a recent project, a feature request came in that was very similar to an existing feature, but the client assured me “only one company will probably ever use this”.
That planted the seed in my mind that it was “overkill” to follow the existing pattern and build out all the same features.
I tried rationalizing in my mind that creating a new table, and wiring up data for every company, when just “one company” was going to use it was unnecessary.
Even more, I started to convince myself that building it out as a one-off would actually be quicker. And we could always refactor later if more people ended up using it. On and on, the rationalization went.
I walked Aaron through my thought process, and he ultimately convinced me to just build it out the same way as the existing feature.
His primary reason was to maintain consistency. Why have two different ways of doing the same basic thing in a single app, when we could just re-use the same pattern?
And as a team that joins a number of projects each year, we’re always thinking about the developer that comes in after us. Why make learning the code base harder than it needs to be?
In the end, building it out as the fully-baked feature actually went much faster than I expected. Because it was a well-trod path, I could copy and use big chunks of application and test code with a handful of mechanical changes.
Building it out the right way wasn’t over-engineering or a waste of time. It ended up being more efficient and resulted in a cleaner, more consistent code base.
Here to help,
Joel
P.S. Wish you had your own Aaron to talk sense into you? Check out the Mastering Laravel community.
Comments are closed