One of the ideas that intrigue me is the “ship it or die” mentality. Regarding what it’s called, there are variations thereof, but the idea behind the phrase is simple:
If you have an idea, get it from concept to product as quickly as possible.
Sure, the idea of getting to concept to a product may also be called “concept to cash” but there’s never a guarantee that you’re going to generate cash, right? There is a guarantee that you can get it into a tangible product, though.
And in software development circles, there’s always a lot that a person can argue for or against the idea. Off the top of my head, the two pros and cons that come immediately to mind are:
- Pro. Getting something done quickly that works and that generates revenue.
- Con. Weak architecture, maintenance, scalability, testability, and so on.
In short, there may be a tradeoff between how fast you can get ship something for a market and the architecture behind the project. Sometimes there is, sometimes there isn’t. Generally speaking, though, I think it’s safe to assume the former.
Furthermore, some may see the former as the easy way out, some may see the latter as an exercise in YAGNI or, even more simply, that the problem can be addressed whenever it comes up.
But what does this have to do with anything at the moment?
Ship It Or Die?
The whole reason that I’m spending time on writing about this is that it’s something that I, and I suspect others in our field, think about at least a little bit. All of this is well and good when talking about it in the abstract sense, but let me try to tie it to something a little more realistic.
Once Upon a Time…
A few years ago, front-end development consisted of wrapping content in inline or block level elements and styling them with basic CSS?
We had advanced tools to work with our backend code, but the front-end was relatively simple aside from perhaps the coding standards enforced by the company or team with which we worked.
Our devices advanced (which, for the record, I consider a good and even natural thing in technology). Along with said advancement, we now have build tools specifically for front-end development that are just as advanced in some regards to those that we use for backend software.
Sure, we have some who are “full stack developers” but I’m happy to admit that I’m far more comfortable working on the server-side than the front-end. If I do work on the front-end, I tend to stick with the tools with which I’m familiar and try to stay within the guardrails defined by the lane in which I operate.
It helps to keep development focused, fast, and consistent across projects.
Okay, So What’s The Point?
In and of itself, this section could be a long post, but I’m not interested in going that far. Instead, I’ll take a single slice of how front-end development works right now and see if I can’t use it to make my point clear.
Take for example, what CSS has become. We have languages on top of languages (like Sass that sits on top of, or adds to, basic CSS).
And we have processors that compile, minify, lint, and prevent us from seeing our work before certain errors and warnings are fixed for the sake of quality. (I don’t consider this a bad thing, but it shows the growing level of complexity – or perhaps maturity – of our front-end tooling).
Front-end development is way too easy, let’s make it more complex so we can feel smarter amongst those of our peers who are apparently dealing with more “critical” aspects of the business. Remember this is a competition.
This article has a humorous take on the whole thing.
A Reasonable Degree of Quality
To be clear, I’m not saying this is a bad thing, but I am saying that things that were once relegated to the server-side or to compiled languages are now extending through the entire development stack of a web application.
To be as crystal clear as possible: I’m all for quality. Shipping things without any degree of it can be seen as an exercise in irresponsibility.
But I also believe there’s a balance to be struck between writing the most optimal, functional, and performant code possible under the constraints of time and budget.
I do not believe, no matter how hard we try to force it upon ourselves, that we live in a developer utopia where we can optimize, architect, and implement pristine systems in every single project.
It does seem, though, we have tried our hardest to create it, haven’t we?
But at some point, isn’t it worth asking if all of the tools that we’re creating and all of the things that we’re adding to our projects removing the very thing that got us into the industry in the first place? Granted, for some of us, this is likely different. Is it fair to ask that having an idea, writing code to bring it to life, and seeing it solve a problem is what brought us into the fold?
At this point, though, we’ve introduced so many tools that getting a development environment up and running for a web application running from the database up to the browser is an intimidating task.
So many things have to happen before we’re actually ready to start writing code that it can become tedious and even a bit exhausting just taking the initial steps in doing so.
A Personal, Final Opinion
I gravitate towards enforcing strong object-oriented practices and tooling in many of the projects I work on with my team and that I ship for others because I know, from experience, the time, dollars, and data than can be lost of something isn’t addressed from all sides.
This isn’t to say that shipping something quickly negates any of that. But the process and organization of the code behind a project is something that I have a very difficult time ignoring so much so that it feels near paralyzing to ship something that’s not been tested and vetted to the highest degree possible (and even then, there are problems).
On the flipside, though, there is part of me that wants to experiment with an idea or two behind the “ship it or die” mentality just see how fast something can be built, shipped, and generating any type of revenue regardless of how pristine the code base is.
And maybe I’ll try that with some upcoming projects.