I have heard this comment in almost every company where I have worked. Without fail, this response occurs when someone on the technical staff suggests adding a practice accepted in other parts of the industry. Some variations are
- “It might work for others, but the problems we work on are harder.”
- “We have really good people, we don’t need that.”
- “That may be fine for academics, but we have a business to run.”
- “We don’t have time to change.”
Early in my career, it was used to justify not using version control (yeah, I’ve been at this for a while). I’ve personally experienced this mindset with regards to
- version control
- unit tests
- any form of automated testing
- coding standards
- agile practices (not necessarily the consultant-driven capital A, Agile)
- training
In every case, no amount of technical proof or information from other sources makes any difference.
Counterpoint
This is not to suggest that every new best practice should be adopted by every company as soon as it comes out. Some practices won’t work well in some environments. Every new practice will take some adjustment time while it negatively impacts productivity. Many will eventually make productivity gains later.
The important point is that “Our business is different/harder than others” is almost always a fallacy when deciding on adoption of a technical practice. Lack of time or expertise with the practice is a good reason to hold off. Worry about destabilizing an important system is legitimate.
If a practice seems to be a good idea, a pilot project and/or research is a valid way to determine if it might help. But rejection because “we solve harder problems than everyone else” is probably not the right approach.
The funny part about this is that everyone’s systems have parts that are different, and more complicated than others might expect. On the other hand, people don’t realize how much of their systems and practices are not really different than what others do.