How to handle R&D and retrocompatibility at the same time



  • I am a software developer in a company who has been active for more than 40 years in B2B product development and I would like to get some advice regarding the situation I'm facing on a day-to-day basis.

    The company I'm working for has actually two very active software development team: one of them is making R&D while the second one is managing production software. As new products are released, code from the R&D is transferred to production. Same when new features are required. Up to here, nothing strange.

    The problem comes from the https://en.wikipedia.org/wiki/CI/CD aspects. To speed up the development process, the production team pulls code from the R&D way before any maturity is achieved and then complains when changes are introduced as the project gains in maturity.

    This is emphasized even more by the fact that the R&D team has a lot of freedom and the production team applies an extremely rigid methodology. R&D side, new concepts and features are often added which result in libraries that are somewhat close to a "perpetual beta" way of doing with older concept being more stable/mature while newer concepts are often refactored with loss of retrocompatibility. Production side, they want full retrocompatibility with all products sold in the past and use a test-driven development approach. This ends up with code with literally hundreds of thousands of if-then-else statements because unit tests written 30 years ago on interfaces definitions are still enforced.

    While I'm clearly not a big fan of the production approach used, I understand that having software in perpetual development is not necessarily compatible with retrocompatibility considerations which are also important.

    My question is: how do you handle fast iterative development in a context where retrocompatibility is of uttermost priority ? Is maintaining white-box (code's internals) testing viable over time or should we focus only on maintaining black-box tests (i.e. only maintain input -> output tests but not details on how the code is actually implemented) ?



  • My gut feeling is that dividing the developers into R&D and production teams creates an impedance mismatch and might be the root cause of the problems you observe.

    I would try to alleviate some of that impedance mismatch by establishing product teams that cover both R&D and production, and guide the people working at those ends through cross-team culture and communication.

    The reasoning for this is that I believe that software development teams should be goal-oriented, not work area oriented. If you separate R&D from the actual business goals and constraints, you may potentially create interesting results (as happens in most pure R&D departments), but applying these results to business needs and existing products is hard work. I also believe that in software engineering, much of what is called R&D isn't actually independent research but evaluation of existing or emerging tools and trends, which is something every developer should do.




Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2