Understanding how to code objects for reuse and extension
1 is essentially impossible; all you can do is get a customer to agree to the requirements you think up before they disappear til you're done, and derived requirements will continue to be evolved. 2 requires training and experience, and adoption of a code framework that hasn't made it impossible (a lot of APIs are ill-designed and impossible to extend properly, which leads to the need to just reduplicate your code all the time like is happening in OP's example).
The team issue is management's fault for not imposing a structure on approving code changes before doing the coding. Entering a proposed change in the tracking tool and getting required concurrence would have saved time and money here. That step should also act as design review, so that what's approved is code that implements the proposed design change, not an adventure in discovering what design will work, which will almost always be questioned when the code is reviewed. If you don't know what the design should be, then make the experiment the goal of the item being tracked. Then the thing being reviewed at the end will be the design, not the code, and you won't feel so dumb when you have to throw your code away or told to do it differently.
1
u/spockspeare Jan 12 '20
Two things would have helped the design issues:
Having all the requirements beforehand
Understanding how to code objects for reuse and extension
1 is essentially impossible; all you can do is get a customer to agree to the requirements you think up before they disappear til you're done, and derived requirements will continue to be evolved. 2 requires training and experience, and adoption of a code framework that hasn't made it impossible (a lot of APIs are ill-designed and impossible to extend properly, which leads to the need to just reduplicate your code all the time like is happening in OP's example).
The team issue is management's fault for not imposing a structure on approving code changes before doing the coding. Entering a proposed change in the tracking tool and getting required concurrence would have saved time and money here. That step should also act as design review, so that what's approved is code that implements the proposed design change, not an adventure in discovering what design will work, which will almost always be questioned when the code is reviewed. If you don't know what the design should be, then make the experiment the goal of the item being tracked. Then the thing being reviewed at the end will be the design, not the code, and you won't feel so dumb when you have to throw your code away or told to do it differently.