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 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) ?

2 Answers 2


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.


I don't have a good answer, but I wonder if there is a way for the R&D team to communicate the maturity of dependencies.

I'm assuming (!) that R&D marks their modules in some ways as mature/immature; I would hope that production isn't pulling a module that a dev spun up to test a theory.... So there is some notion of

  • alpha code - useful only for testing and exploration; not guaranteed to work; fails some internal unit tests, may not even have complete unit tests)

  • beta code - Quality testing - passes all internal unit tests, does what it is supposed to do, but we need to verify that all external dependencies are reliable. May rely on some "custom" external libraries or functions, and those dependencies need to be examined before production pulls this code.

  • pre-production code - This should be safe to pull. Verifying test suite, documenting, etc. All external dependencies are to either production code or to similarly mature pre-production code.

Would that work?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.