While refactoring an application recently I was thinking about its build pipelines and the tools available to modern app dev teams. Docker was heralded as the world savor (like every new tech is, but that is a different conversation); however the reality is multi GB images, version sprawl, and a lack luster meta-data system, and a security model that has been the bane of security teams for the past 5 years. It leaves a person longer for the simpler times.
It got me thinking, is containerizing the applications run time worth it? If we applying the software concept of single responsibility to the build process; each step would have a tool best suited for one domain of responsibility. The counter argument being "yet another tools to learn". But, honestly, everything is YAML configuration these days so how hard would it really be.
So the question: Do you prefer small, separate, specific tooling or one tool that does it all to an acceptable level? What is the justification for you choice?
Cover image by https://unsplash.com/@soymeraki
Top comments (9)
So I adopted a mentality from bash of "do one thing well" I would rather use single tools that are really good at what they are trying to do than use one tool that does a lot of things but not very well, another aspect is that tools should have good integration layers so it's easy to connect them together, just my 2 cents though. All the best, Scott
Totally agree, we share a similar mindset; I use Vim with some plugins and do compiling and debugging manually. Never been a fan of all-in-one solutions like IDEs.
This is how I work these days:
I have generally gravitated towards do it all tools. DEV is built on Rails which I felt made the roadmap from point A to B to C to D to E very clear, and can be mapped directly to other big successful app stories like Basecamp, GitHub, Shopify, etc. Other webdev tools had me going from A to B and then it's all on you from there.
I liked to think I was working on some kind of loose consensus on how the whole thing might look in the end, rather than disparate tools forcing me to have my own opinions at every single step.
Multipurpose tools have their own version of the 80/20 rule. For 80% of scenarios, they are great (or at least usable), but for that other 20% of workloads, you get nothing unless you are willing to write an intricate plugin or modify the editor (assuming it is open source).
It depends on the specific situation, but that's partly because of the fact that how 'one thing done very well' a tool is depends on where you define domain boundaries.
pandoc is a good example of this. When viewed through the lens of markup conversion as your domain, it's trying to do everything, but when you look at data transformation tools as a whole, it's a tool that's just for markup conversion and does it very well. Similar arguments can be made for FFMPEG or almost any 'swiss-army knife' type tool.
Personally, I tend to look less at this aspect of a tool, and more at how well it actually does what I need it to do without being excessive. This tends to lead me more towards 'does one thing well' tools than 'does it all' tools, but this does lead to odd choices sometimes (for example, I carry a multi-tool designed for bomb-squads on a daily basis, because it just so happens that the exact mix of tools it has covers what I need with regularity perfectly and I rather prefer the pliers to not be spring loaded)
I think it heavily depends on the specific tool, and there's not a single type I prefer. I use express for the flexibility, but I choose Create React App for it's simplicity and how it abstracts nasty stuff like webpack and Babel configuration (and the general working-out-of-the-box experience).
A multipurpose tool should just be a pluggable architecture of single tools. Bash as mentioned bellow is a shell (tool) to run many focused tools, so you could instead think of this question a different way, should a programmer write a tool to house tools or just a tool. You can quickly saturate the market with the former.
I prefer all-in-one for my frameworks because it let you focus more on the "what" than on the "how". I feel you get more things done, even if it is not the most fast or efficient way.
Plus, using "all included" help keep consistency, and keep us away from the organizational part, again, to be closer to our business and the value we bring.
I prefer everything in kind of software like when I'm developing API I will use postman over openapi editor. Then again I use single used tools from time to time to make it easy.