I've reviewed a book about SBT recently. As this name doesn't ring a bell for everyone, some peeps who follow my reviews have followed with a question:
"What's this SBT thing?"
Majority of them seemed very surprised with the response I gave them ("It's a build system for JVM world, used mainly by Scala peeps.")
"Build system? Why do you care about build system?"
"Don't you really have anything else to read about? Build systems are bo-o-ring!"
"Who learns build systems' internals these days? Why don't you leave dealing with them to you IDE's wizards, etc."
Should I tell them I've tried & learned make, ant, Maven, Gradle, mix, msbuild & (very, very briefly though) Leiningen before? ;P
Build systems are meh
This just confirms my belief that 'knowing your build system' has joined the other, forgotten and neglected developer skills: like troubleshooting & debugging (I am dead serious about that). Devs tend to appreciate more the most "creative" aspects of their work - activities that:
- produce something visible / substantial
- are easily mapped to easily verifiable functional requirements / user stories, etc.
Build system is usually much harder to grasp. As it's intended for being used by tekkies, it's usually much less ergonomic, lacks any kind of visual representation & what is more - it may be a true bitch to test / troubleshoot. On the top of that, it may be tedious & boring indeed.
What is more, people don't feel any pain due to ignoring the build system until they get to at least medium level of solution complexity - in basic projects with very few dependencies pretty much everything runs perfectly smoothly on defaults (unless you break some things - that's another reason to avoid fiddling with that ;P).
Don't be a shallow dev ...
Sadly, ignoring your build systems can have many painful, yet "silent" (background) consequences:
- if you don't utilize your build system properly (for instance, manage dependencies/ordering between builds) - you may end up with non-deterministic build system (rebuilding the same "state" can create different binary output)
- if you don't put things in order (by making build incremental & splitting projects into tiers, etc.), your builds' times may skyrocket - crushing developers' agility in your team/project/company
These won't stop your project / kill your product in a strict, visible, oneshot manner. But they can very seriously impact the overall productivity - in a way that's not that obvious for inexperienced eye.
New devs who learn they craft are rarely forced to start learning build systems, so they end up treating them as something additional, external to their core work (& out of their responsibility) - but if you think about that for a minute, it's ridiculous:
- source code is just source code - it does nothing by itself
- executables (& configuration, & data, & infrastructure, ...) is what truly matters - ability to craft them from source code (it's not just 1:1 compilation, but also packaging, dependency mgmt, versioning, etc.) is as important as writing good code
- wrong, improper, flawed, etc. build configuration can cause problems as painful & severe as any other kinds of bugs (in code, configuration, etc.)
Do you know your build system?
I mean - really know your build system? Obviously I'm not asking whether you've memorized all msbuild option flags by heart, try to respond (honestly!) the questions listed beneath:
- Do you know what's exactly being rebuilt with your basic build command (whether it's F5 or something typed manually)? In other words - for particular, point change somewhere in your code base - do you exactly know the minimum range of what should be built? And the minimum range of artifacts to be re-deployed?
- Are you sure that there's nothing compiled unnecessarily in the scenario described above?
- Imagine that you have the same state of source code checked out in two separate directory trees - can you confirm it's not possible (with your current state of build system configuration) to end up with different outputs because of running builds in different order?
If you've answer 'no' to any of those questions, didn't it concern you at all? It should have been.
Pic: © Mikael Lever - Fotolia.com
