When not to move a "C style" code to "C++ or Object Oriented" code?

Question

Context

I am (part of team A) developing a piece of functionality which depends on new APIs provided by team B. Old APIs (also provided by Team B) are there and this is how they are being used in our code...

int someFunction() {
 //-- lots of code here
 oldAPI.func1();
 //-- lots of code again
 if (something)
     oldAPI.func2();
 else oldAPI.func3();
 //lots of code
 // ans so on
 }

We needed to complete it quickly,So I just modify the existing flow to use newAPI and tested it with some placeholder calls.

Soon after I completed... Team B informed us that they will take more time.

Now I have two options...

Option 1: Wait for Team B to complete; push your code along/after them

Option 2: Make your code support both old and new; based on a configuration.

if we choose option 2; there are two approaches...

Approach 1: Modularize your code; and use polymorphism in your code.

 class API_BASE {virtual funct1(),func2(),func3()};
 class API_OLD : API_BASE {funct1(),func2(),func3()};
 class API_NEW : API_BASE {funct1(),func2(),func3()};

Approach 2: use plain conditional logic

if (newAvailable)
    useNew();
else 
    useOld();

Questions

1. If possibilities of supporting multiple flow in future is very less(say 15%); but u need to support them for some time (say few months), would you modify a code written in procedural way to support OOPs? I see benefit of maintainability, readability and easy to extend code. But what is the smart way?
2. In legacy lode base... what is the ideal time to refactor code? You touch one file once in a year and move to other. Provide I have time... should I refactor an stable/running code, or should I do it when there is a real need to refactoring (how to define that I dont know)
3. In big software companies... team works in there own boundaries. If team A completes his job, it wants to push to production sooner and announce to world (mgmt, team b) etc that we are done. Until we have everything ready (i.e. A's part and B's Part), for end user (QA/Customer) there is no change is functionality. Is this a good way of thinking? should I concentrate more on my part, and let mgmt worry about bigger picture?

Answer 1

Option 1.

Team B advertised the API and their schedule estimate. You took them at their word, you designed to their interface design specification. You're done, you're now available to work other tasks in the backlog. It isn't your fault that their schedule estimate was not perfect.

Either of the approaches to Option 2 makes your code more verbose and less maintainable. That's the LAST thing you want to do.

If they pulled their estimate in because of political pressure (it happens, far too often), they need to man up and take their medicine - and so does the clown who applied the pressure.

To answer your questions:

1. Do it right the first time, and then LEAVE it. Heinlein put this as "Write, finish what you write, then LEAVE IT ALONE AND SEND IT OUT FOR PUBLICATION." He was right.

2. Refactor when you AREN'T in the middle of a push to finish something else, like you are right now, when the entire code base ISN'T in flux, like it is right now. In other words, NOT NOW.

3. The focus has to be on completing the parts, and then integrating the parts. If Part A is done, Team A can be assigned to help Team C on Part C. Once Part A is finished, Team A should not continue to monkey with it just because Team B is running late.

These are probably not the answers you wanted to hear, but they are the answers that hopefully maximize your odds of actually shipping working product.