How do you add feature to a class that was originally designed wrong in the first place?

Question

I have a Surgeon class that is constantly changing

class Surgeon
{
   string name, discipline;
 public:
    Surgeon(string _name, string _discp) : name{_name}, discipline{_discp}{}
    void writeDir(string _dir);
    void readDir(string _dir);
}

Now I need to add recording settings to Surgeon. Keeping in mind SOLID principles this forces me to go back in Surgeon class add a recording settings and modify everything in surgeon class. Now, I'm also aware that the current implementation of software already adds value to the company. And refactor is not necessary, but in order to do this task right I need to refactor the whole class. If I just add the feature that works with the current design then I'm simply perpetuating bad design.

Where does the software engineer provide the most value? Should I produce code that shows results quickly but is prone to errors in the future or should I delay quick results to produce good code that is more robust? What would be the happy medium if there is any?

The original design had an original requirements. New requirements could force you to change the design. That's right and legit. We don't change the design because the current one is worng. We do because the actual one doesn't meet our needs. Refactoring and re-design are different things. — Laiv, Jan 03 '18 at 21:12

score 15 · Answer 1 · answered Jan 03 '18 at 21:35

And refactor is not necessary, but in order to do this task right I need to refactor the whole class.

This is contradictory. You cannot claim that refactoring is not necessary while specifying that the class should be refactored. You're in a situation where, in order to follow SOLID principles, you need to refactor existent code. The fact that “the current implementation of software already adds value to the company” is irrelevant: you don't refactor existent code because it doesn't have value; you refactor it because it doesn't match the new design.

Should I produce code that shows results quickly but is prone to errors in the future or should I delay quick results to produce good code that is more robust?

There is no general answer to that.

If it is essential to have visible results fast in order to show it to the business analyst and iterate quickly based on his feedback, you may do it. If you do it, make sure the business analyst (and possibly the project manager) understands the implications, i.e. that you're doing a prototype, that is code which will be thrown away in order for the production code to be written instead.

If it is not necessary to have visible results fast or if you know that people you're working with do not understand what prototypes mean and that as soon as they see any result, they'll consider that your job is finished, give an estimate based on how long would it take to write production code from the beginning. Writing production code includes refactoring and testing: you're not paid to type code, but to design working, reliable software.

How do you add feature to a class that was originally designed wrong in the first place?

1 Answers1