0

Currently I am working on a health related application which was being developed for 5 years and lot of developers have contributed in it.

The application is quite complex and highly used by lot of users. During code review, I have found that lots of its code and implementation patterns have been deprecated and they can be replaced with new methods and practices.

But my senior developers have told me not to change existing implementation and implement new functionality in "isolation". They have valid reason for it.

But I think if the development goes in this way, the application will become too complex or outdated to understand/change.

Can anyone provide suggestion on how I should handle this situation or how they have handled this situation?

Rohit Gupta
  • 109
  • 2
  • 1
    Possible duplicate of [How can I convince management to deal with technical debt?](http://softwareengineering.stackexchange.com/questions/43948/how-can-i-convince-management-to-deal-with-technical-debt) – gnat Apr 08 '17 at 06:57
  • `I have found that lots of its code and implementation patterns have been deprecated and they can be replaced with new methods and practices.`. Where's the technicsl debt here? – Laiv Apr 08 '17 at 08:56
  • 1
    I find this question similar to http://softwareengineering.stackexchange.com/q/345593/222996 . – Laiv Apr 08 '17 at 09:16
  • 1
    Possible duplicate of [Should I refactor the code that is marked as "don't change"?](http://softwareengineering.stackexchange.com/questions/345593/should-i-refactor-the-code-that-is-marked-as-dont-change) – Doc Brown Apr 08 '17 at 14:14

1 Answers1

3

How should you handle the situation ?

You have identified potential for improvement. But patterns are just means to design software better and faster. So when the software is already designed and implemented, there is no obligation to adopt the latest patterns.

If your system has a modular design, and allows for new components to be developed without significant dependency to existing constructs, just do as your boss said :-)

How does your boss think ?

Engineering arguments:

  • "Never change a running system" : Change of patterns would require extensive redesign, which might quickly propagate through dependencies and end-up in a complete overhaul of the system
  • If such change is required, how to handle the risk of instability during the reimplementation ?
  • How can the new version be tested ? If TDD was used, just reuse all the test cases and the risk is managed. But if not, are all the tests proving the reliability still known ?

Business arguments:

  • What benefit would the change of patterns bring to the customer ?
  • What's the cost of reimplementing, and what economic benefits (cost saving, revenue) could it bring ? And how does this picture compare to cost incurred by keeping the existing patterns ?
  • Is someone ready to pay for the change ?

How do the user think ?

They think:

  • I've plenty of work to do, and the system should help me
  • A major redesign was undertaken, but nothing changes for my daily work, except that there could be a lot of new bugs to handle.
  • I have no time to invest on a huge acceptance test, just for obscur technical matters.

Conclusion

I don't have the answers to all these questions. Your boss has certainly done this kind of analysis. That's what bosses are paid to do. So work as he told you :-) ...

...unless you think that the old patterns have major drawbacks that are not fully understood by your boss. For example if the old patterns make the system difficult to operate and maintain ("technical debt"). In this case you should go back to your boss and make sure he understand the hidden costs of the legacy in his cost/benefit analysis.

Christophe
  • 74,672
  • 10
  • 115
  • 187