2020-06-14
Product code and utility code
Over time, I've noticed that I seem to have a relatively different experience of programming than many people do (or at least the people who write articles that show up in my Internet reading). I think that part of this difference can be attributed to me working on a different sort of code than most people. To explain that, let's talk about a split (that is really a continuum) between two sorts of code, product code and utility code.
Product code is what you use to deliver your business. Sometimes the product code is your business (either selling the software or directly providing an online service), and sometimes it directly supports your business activities. Product code almost always needs to keep changing and evolving because what you deliver in your business inevitably keeps changing and evolving itself. If you try to freeze product code in the face of a changing business, eventually you get a wider and wider gap between what the code does and what your people need. Your people will bridge this gap as best they can, through new code that connects to your code, awkward procedures, and eventually bypassing the old code and doing the business with spreadsheets and so on.
Utility code supports what you do, but it's not tied to business requirements (or at least not very tightly; it's connected in that you shouldn't be doing things unless the business needs them for some reason). This is the code that works quietly in the background keeping the wheels on and turning, supporting both the environment that product code exists in and the generally stable internal processes of the organization. Because it's not tied very strongly to the business, utility code doesn't necessarily need very many changes; the further from business operations it is generally the fewer changes it needs over time. Utility code for stable and well established internal processes like expense reports or onboarding new people into some aspects of the organization can be essentially static.
If you work on product code, your code is constantly changing anyway and you don't necessarily see the appeal of being able to stabilize it and walk away. Unchanging product code is almost always dead and abandoned; either it's out ot step with the business or the part of the business it's associated with has been frozen and is probably dying. If you work on utility code, you frequently stabilize it and walk away, because what it needs to do is often pretty fixed; if you can't stabilize the code despite fixed requirements, something is wrong and you're unhappy about it.
(A corollary of this is that you almost always have people who are familiar with how your product code works, because there's generally someone working on it, but you may not have anyone who remembers how some bit of utility code works.)
This makes a difference when code needs to change for reasons other than business requirements changing. Product code is always changing anyway, so you can often naturally roll in those other changes as part of your ongoing regular changes. Utility code is often frozen, so now you have to thaw it out, make changes, stabilize things, and freeze it again, all to stay in the same place as far as organizational needs and functionality go.
(As you might guess from all of this, I feel that I mostly work on utility code. We don't really have any product code we're responsible for, although it does exist within the department.)