From my experience as a human being, people don’t always understand the real reasons behind the way they tackle their daily tasks. They also don’t recognize the reasons behind the decisions they make accordingly. This is true for both personal and work life. They handle their daily routines a certain way, which is not always the most productive one. It’s just the way they are used to do things.
However, there are signs or warning flags that shine a light on these so-called ‘misses’ in productivity. If, for the sake of argument, we would to ask ourselves why we’re doing something a certain way (or not doing something at all), and the answer is: “because that’s the way it’s always been done” or “we don’t have a way to do it differently [or at all]” or “if it ain’t broke, don’t fix it” or my favorite one: “yes, it’s a lot of effort, but that’s the way it is” – then maybe it’s a sign that there’s a better, more productive way to get these tasks done.
Working at a company that offers a solution to reduce build and other development task times, I see those signs all the time. And the slower the task is, like with the case of C++ builds, the more signs I see.
So if you’re running C++ builds, and one or more of these following signs rings a bell, it might mean your build times (or more specifically your visual studio build times) are too slow and it’s time to optimize. Some of the great inventions out there originate from the effort to optimize tasks and to help us make better decisions, whether it be a dishwasher or a search engine. Why not use them?
But first thing first. Do any of the below signs hit home?
Sign #1: “Who broke the build?”
If you find yourself in a never-ending race to locate a build breaker on the loose, it means that the collision between commits is too much for you to handle and you obviously don’t build per commit. If you were, locating the one responsible for a broken/red build on that information radiator was a non-issue. You would have known exactly who broke the build: the commit owner. Building per commit is something we all aspire to, of course. So why don’t we? Well… It requires frequent building. If your build times are too slow, you just can’t build that way. It’s a simple equation. Otherwise, you’ll find yourself spending a lot of time doing nothing.
Another issue is automation. The blessed automation that is usually involved in building per commit will shoot a notification once the build is broken and send the build breaker on a race to fix and re-commit (I’m sure you’re even aware of automation tools and platforms that integrate with slack).
Let’s also not forget about gated commits and gated check ins. By definition, build per commit required gated check ins. These allow us to maintain a clean build.
Sign #2: A new anxiety in your arsenal: “Will the nightly build pass?”
If you ‘commit and pray’ or if you dread that moment where you find out that, yet again, the nightly build failed (and you don’t have a clean build for today’s release), it’s a sign. If it reaches a point where this becomes an annoying itch in your anxieties (don’t you just hate those?), then seek professional help. And I don’t mean those pills out there that are meant to relieve the symptom. Don’t get me wrong, I’m all for western medicine. But why not fix the problem instead of relieving the symptoms? You can.
When your build is fast (lightning fast), you can run builds all the time. Let me repeat that: ALL THE TIME. A build failed (with only one commit, hopefully)? No worries. Another one will soon follow. Have you heard about the ‘Joel Test’? Joel recommends daily builds for the exact reason. So… yep. No nightly anything, except for sleep. No anxiety (well… build-related anxiety). Life is beautiful.
Sign #3: “Let’s cut on tests”
Agile and fast delivery require some of us to compromise on tests. You know how it goes. Tests prolong the already very long build time, so you think to yourself: “Let’s cut here. Let’s snip there.” Another scenario is ignoring failed flaky tests just to get things going. Big mistake. HUGE. Tests are your safety net, and you can never be too safe. Integration tests, regression tests (full ones), unit tests – the works. They are there for a reason. They are important. They make sure your product will be worth your users’ precious (oh so precious) attention. You just can’t afford to disrespect it…
Running more tests is especially important in the case of C++ as the scenario of an error in one component resulting in an error on another component is quite common. If you have the option to run not only your unit tests on every build/commit but also your integration tests, you can save yourself hours of cross-team frustration and pointless blaming. The Q.A team will also be grateful for the ability to focus their efforts on your product’s new feature instead of making sure nothing is broken.
So yep, test like there’s no tomorrow. Test as if your life depends on it (your product’s life actually does). There’s no such thing as too many tests. You should make decisions based on what’s good for your product and users, not for your build times. Your thinking process should be more along the lines of: “Full regression tests? SURE. Integration tests? Why not?”.
Sign #4: “Static Code Analy-what?”
So you’re racking your head trying to remember what static code analysis is. That’s a bad sign. It means you’re not doing it, and if I had to take a wild guess, I’d say you never have. True, it’s a real headache. All those lines of code thoroughly examined could be quite a bit of a hassle to maintain and the build time – well… let’s just say that the burden on build time is very noticeable. However, the benefits could be enormous. After all, if code quality is of the essence (as I’m sure it is), static code analysis identifies problematic patterns very effectively. It also detects security vulnerabilities in your code (which is a hot topic these days). But then again, what about the build time? That’s a question I wish you wouldn’t have had to raise.
*Related: Top 9 C++ Static Code Analysis Tools
Sign #5: “I’m not adding this – it will slow up my build!”
Today’s so-called luxuries are tomorrow’s necessities. Having the ability to add tools and functionalities to your development process, such as open-source tools or commercial 3rd party libraries, as well as expanding your current infrastructure (test coverage, for one), could provide you with a competitive advantage. When you’re skimping on these ‘luxuries’ and the reason is not budget, but rather the negative effect it will have on your build times, that’s a bad sign. You should be able to grow and expand regardless of your build times, adding all sorts of cool tools and expanding your testing coverage (heck, I’ll even throw in pre-commit tests without the help of build units).
What do I do with all these signs, besides freaking out?
First off, You can, by all means, freak out. Venting is good. Not doing something about it is bad. After you’ve exhausted your enjoyable (or less enjoyable) freakout, smile: you have lots of options. It’s up to you which option to choose from (YAY, control restored!). You can choose to rearrange your code (this guide will help you with that), stock up your hardware inventory, or you can utilize Incredibuild (download for free) and keep your code (as well as your infrastructure and hardware) intact. Are you smiling now?
The road not thought of
Yep, this is another ‘road not taken’ cliche. But before I lose your patience, I would like to suggest a different interpretation. Finding ways to reduce your build times is more ‘The road not thought of’ than ‘The road not taken’. Once you really see these signs, thinking of the best approach to go head-on with your build times is an eye-opener! Hopefully, I managed to open your eyes just a tiny bit. The rest is on you.
