Software projects today are getting more and more complex. Code accumulates over the years as organization growth increases the volume of daily commits. Projects that used to take minutes to complete a full build now start with fetching from the repository and may require an hour or more to build. Communications of the ACM, January 2019, Using Remote Cache Service for Bazel. Image: medium.com

Ouch. An hour or more to build. That reminded me of how things come and go as technology changes the world. We, of course, had to keypunch in our code, and we got one build per day. The upside to this was that we spent a lot of time “desk checking” our code. Some people attacked their code with colored markers and showed all the relationships between data, modules, logic, etc. in color lines running through multi-inch thick code listings. We knew our code and language syntax intimately because that was the only way to be productive.

Now, once again, we may need to develop strategies to make use of that “down time” when our build (and follow-on testing) is running. Living with my code (or my code changes) was always a useful activity. In some cases, as the programming lead, I’d recommend (told sometimes) a programmer to stop making changes and just spend time really understanding the code by reading and tracing the logic. Too often, the rush of punching the “build” icon while trying to figure out why the code wasn’t working as expected became a substitute for actually understanding the problem.

I asked on many occasions for an explanation of what had been going wrong with the code before it got fixed. When the answer was “I made these changes” with no apparent insight into why the change fixed the problem, I knew that the likelihood of having found a rock-solid fix was much less than when someone explained in glorious detail the silly thing their code was doing and the insight that supplied a simple or even elegant fix.

See also code that works the first time

Are you helping your programming team grow and understand their code as opposed to trial-and-error programming that chews up quality and precious time?