The longer you work in the business of software the more you will begin to see themes in the way the people working on the software and systems see their work. I have most often noticed this when attempting to push for practices that help development. To some extent, skepticism about new practices is reasonable, but not always. What I find most interesting is the fact that I have heard the same set of excuses when trying to introduce version control, Test Driven Development, pairing, code reviews, and other practices that eventually became common.
Everyone is Too Busy
“We’re too busy solving real problems to do that.” If you examine these more closely, you will often note inefficiencies that could make the developers less busy, and more effective.
Back when I was trying to get companies to adopt version control (not as far back as you might be thinking), the company didn’t have time to get everyone trained on version control. We were spending too much time fixing bugs (some caused by people accidentally breaking the code by making conflicting changes). Or, recovering from accidentally deleting code. Or, in one really memorable case, trying to understand the code, because every bug was commented out in the code with an explanation of why it was wrong and what we did to fix it.
I remember one case where I was told that unit tests were too much work, because you had to keep the tests working too. The person telling me this did admit that they had found a bug pretty quickly because the unit tests pointed right to a function whose behavior was changed. And then he went on to rant about how maintaining the tests was too much trouble for no gain.
Finding Good Developers is Hard
“Finding good developers is hard.” Sometimes this is presented as “Finding senior developers is hard.” There a lot of potential developers in the job market. Some are good and some are not. The biggest problems I see boil down to wanting to hire someone with exactly the skills you need, but no more (cause that would make them more expensive). They want a senior developer that somehow walks in as an absolute expert in their system on day one.
Only Senior Developers Problem
Some companies have trouble finding good developers because they only want senior developers. There are a finite number of (actual) senior developers on the market at any time. Because many companies only want senior developers, there are likely fewer available seniors than jobs. That will also result in some job seekers inflating their resume to try to look senior, because otherwise there is no way to get a job.
What many companies miss is that having all senior developers is a really bad thing. This mean that you have really senior people doing work that doesn’t challenge them. (Because every company has work like that.) If they aren’t challenged, they will look elsewhere, or they will invent problems to keep them challenged. One very effective way to challenge your senior developers is to give them junior developers to train. (They won’t always appreciate that, but it is a good challenge.)
One thing these companies don’t realize is that junior developers don’t remain junior for long. Depending on who they can learn from, my experience is that entry-level developers become mid-level in somewhere between 6 months and 2 years. At that point, you not only don’t have a junior developer any more, but you have a developer that understands your business and systems. If you hired a mid-level developer from outside the company, they would still need 6-12 months to learn your systems to the point where they are doing more good than harm.
By training junior developers, they are not starting with assumptions from another environment. (Not unusual for mid-level developers changing jobs.) They didn’t start off set in their ways (or convinced that the last place they worked was the One, True way to develop software).
The Fred Problem
The extreme case of this is the company that has lost a very experienced member of their team, let’s call him Fred. Over time, Fred has become an expert in several programs (internal and external) that the company depends on. Fred also understands the reasoning behind several design decisions in the core databases. Fred has seen a number of changes in the company’s industry and knows many of the partners that the company works with. Over time, he has taken on some sysadmin tasks that no one else wanted to do and is the go-to person for information on the TLS certificate process.
Now, Fred is gone and the hiring manager writes up a description of the job Fred has been doing. No one on the planet has exactly that skill set. It’s impossible to hire a replacement for Fred. Replacing Fred might take 3 or more people. Or, you need to begin training people to do part of what Fred was doing in the past.
This is normally obvious in any job description that covers what looks like multiple, unrelated jobs.
The Next New Thing Disrupts Everything
“Ignore what others are doing, {new thing} disrupts everything and will solve all our problems.”
In my experience, most companies change when someone in authority hears about a silver bullet that will make all of your problems go away, or the new thing that you have to adopt or your company (or career) will be left behind. Over a large time scale, you will begin to notice that an extremely small number of these ideas have any major effect on the long-term. Mostly, the best will have a few percent effect on productivity, or profitability. Most of these ideas will be replaced when a new fad comes down the pike.
Unfortunately, the new thing does often result in disruption. While the company experiments with that thing, critical work gets pushed off or cancelled. People will end up spending extra time trying to keep the critical systems working despite the new thing.
Real Hard Problems
I find this one hysterical. Every single company that I’ve worked in has at some point argued that some process might work for other companies/people, but “we are solving really hard problems”. Apparently, each of these companies are the only ones in the whole world solving hard problems.
This is not to say that these companies are not solving hard problems. But, they are not the only ones. Also, their hard problems are probably not significantly different than the hard problems at other companies.