> I work at a wholesale insurance company (middleman); we have over a hundred individual systems, some simple, some quite complex. Some of those systems can be maintained by any programmer that comes in. Others really shouldn't be maintained by someone who doesn't have good experience in writing maintainable code.
It sounds like you have far too few developers to cover those systems. My company is similar, although with much fewer individual systems. The biggest problem we have is that we expect developers to be familiar with all of them and it's simply too much ground to cover, especially when you add in decades of technical debt. I've been there over a year now and picked up almost no domain-specific knowledge because the cognitive load of all the projects and their intricacies and the constantly switching between them is just to high to learn anything in detail.
The second you aren't working on something your knowledge begins to fade. If I have to pick up something I haven't touched in three months then it's pretty close to being a new product to me.
> It sounds like you have far too few developers to cover those systems. My company is similar, although with much fewer individual systems. The biggest problem we have is that we expect developers to be familiar with all of them and it's simply too much ground to cover, especially when you add in decades of technical debt.
We definitely do. Unfortunately, it's difficult to hire in our area.
We've settled into our specialties, but that gives a terrible bus factor---the more senior the employee, the more the company suffers if they get hit by a bus. And goes back to the concept of theory building. We do what we can to try to mitigate certain aspects.
> The second you aren't working on something your knowledge begins to fade. If I have to pick up something I haven't touched in three months then it's pretty close to being a new product to me.
Yes---it's very useful to have people who have been there long enough to jog eachothers' memory. There are some core projects that are touched frequently enough to stay mostly fresh in our mind. It's always fun to look back 5--10 years and think about the history of the projects, or joke about the hardships. That's where the real knowledge lies.
It sounds like you have far too few developers to cover those systems. My company is similar, although with much fewer individual systems. The biggest problem we have is that we expect developers to be familiar with all of them and it's simply too much ground to cover, especially when you add in decades of technical debt. I've been there over a year now and picked up almost no domain-specific knowledge because the cognitive load of all the projects and their intricacies and the constantly switching between them is just to high to learn anything in detail.
The second you aren't working on something your knowledge begins to fade. If I have to pick up something I haven't touched in three months then it's pretty close to being a new product to me.