As we review the tools and processes we use to manage the large build and test system for our Java products, one observation stands out.  We want things to be simple, but over the course of a decade, more and more custom tooling was written to make the builds more flexible.  A gnarly tangle of scripts sits taunting us…  “just try and fix us”.

Captain’s log:

As we embark on the journey to simplify, heading into uncharted territory, full of trepidation, a solemn quiet settles over us…  if we can’t make it simple to test our products, we will perish.

Most definitely an over dramatization of our 2016 goals, but a fun way to think about the work…  do or die.  Instead of “fixing” the gnarly scripts, opt to throw them away altogether.  Throw out some popular convenience features and tools in the process, because to keep them as they are means continued high maintenance costs in the future.  We will come at the problem by stripping away everything and then adding in necessities.  The claim is that it is far better to have simplicity (builds that anyone can run, tests that everyone can triage and re-run, etc), than have flexibility that only benefits a small portion of the team.