Jan 11, 2016
In the software development business, there is a debate that burns on and on. That debate is about framework tie-in vs building software piece-by-bespoke-piece. Both sides have strong opinions on which way is the “right” way, but often fail to articulate the context which necessitates their differing perspectives.
In the PHP world, there’s an eternal war being fought over using off-the-shelf frameworks vs rolling a special snowflake framework for each project. There are use-cases for both, but most probably fall into the first group, including most of the people defending the second.
In the end, average Joes just don’t have time for the discussion, and want a standard path to follow. For me, as a designer, developer and entrepreneur, while these discussions are enjoyable to read, participate, and learn from, my perspective has always served one purpose…to find whatever allows me to build the best software I can, in the shortest amount of time possible. My free time to build products is much more limited now that I’m older, as anyone who’s married, expecting, and has an 11-month old will vouch for. There is simply not enough time to futz around with idealism within the microscopic windows afforded most people. Leave that to the folks working in the 100 plus development departments. We builders just need some good tools.
I always have a couple of products in the works. My latest is an invoicing Saas called PushSilver. In the case of PushSilver, I knew I was going to use Laravel. Why? Here are a few reasons:
The choice was never centered around software patterns. It was centered around a fast-turnaround philosophy.
There are downsides, of course. Every time a new version of Laravel comes out, there are annoying backwards-incompatible changes that have to be made to my codebase. However for every pain in the ass, I get a lot more structure and convention for free. This is brainpower which can go to making something which can provide for my family…something that I can launch. And launching is the name of the game for the maker, not worrying about whether a certain coding pattern will sink a boat that’s never set sail.
When it came time to pick a CSS framework, I already had my tried-and-true Beard on tap. Beard provies an arsenal of easy-to-remember atomic classes, which makes it well-suited to designing in the browser. In this case, it also makes it decoupled from other CSS frameworks, which I find to be more important than following the strong conventions of something like Bootstrap or Foundation. My hat box is already full of founder, designer, front-end developer, and back-end development hats. It may not be the most conventional choice, but in this case, my choice of tool is serving my goals.
This is the essence of the old phrase “using the right tool for the job”. Every tool is worth considering, but be wary of those built for a different context. Pick the tools that make you the most productive, make you the happiest, and make you feel smart. You will always hate the code your wrote a few years back, so there’s no use worrying about what your future self will think.
In the end, I want to use (and build) tools designed to make being an entrepreneur easier. Perfect code is great, but only if it escapes the darkness of idealism and is thrust into the light of shipped utility. Builders who wish to be independent business owners have to assemble an all-star lineup that can consistently perform well and must tailor their toolsets to their goals. Not to the dogma of groupthink. Not to the whims of large organizations. Not even to the opinions of other builders. Only the goals.
Interested in more content like this? Follow me on Twitter to stay updated when I post new articles.
© 2017 David Hemphill