Legacy Code Debt

Development
1

This is a good article on the topic of old code and legacy code debt when trying to keep a good project moving forward.

2

This is the best Quote: “To be competitive, like every other word processor of the mid-1980s, it included every imaginable feature, whether it made sense at all.”

1 Like
3

http://www.docksidereports.com/fundamentals_of_restoration_proj.htm

I have ran more total design re-thinks and renovations than anyone should ever have to face. It is the same argument every time, and depending on the decision made from the arguments, the results never change one bit.

Project plan that works:

  1. Decide what you are trying to do with the product, and what it looks like when finished.
  2. Determine what base components meet the MINIMAL use of the product.
  3. Find a product compatible with the desired use, Evaluate it’s function as-is. Purchase/obtain same.
  4. Gut. Every. Damn. Thing. Possible. Empty. Interior.
  5. Save only the highest quality components that satisfy needs to meet the desired use.
  6. Throw. Every. Thing. Else. Away.
  7. Paint bilges of empty hull. Ensure everything is clean and all legacy fittings are OUT.
  8. Restore, fabricate or purchase full set of Main and Auxiliary components.
  9. Perform unit bench testing on all components.
  10. Install new and restored components into optimal locations, taking into account connectivity (hoses, wiring, etc) angles routing and capacities.
  11. Install all non-removable joinery and interior structure.
  12. Install all cabling, hoses, valves etc… in a way that precludes inconvenience to occupants and maintainers, as well as avoids death.
  13. Sea trials. Take it out and drive it like you stole it.
  14. Refer back to number 1, and start decorating. Ergonomics should be easy since you satisfied numbers 10 ~ 12.
  15. Tiger Cruise. Show the new owner that a minimalist blue-water vessel is more fun, comfy, and capable than a whiz-bang gadget box…and that his MP3 player headphones make better noise than an installed Hi-Fi with a generator running.

The project plans that don’t work:

  1. Don’t want to talk about them.
4

I feel that is likely the difference between a word processor and an EHR system. Imagined need is probably among the most harmful things that are put into EHR systems because when nurses/clinicians do workarounds, they often use these unintended features and cause patient safety issues… or sometimes get fed up with the usability of the systems

1 Like
5

You said it. Helmet fire (too much data, too many options) is bad. People having lots of options that are poorly documented (means contextual instructions, 'cause a wiki will rarely get looked at) lend itself to exactly the kind of hacks you are talking about. In OpenEMR, the first one (of many) that always pops up is to create a fake user that is a “provider” just to get a non-provider calendar schedule up. The next one is to make two accounts for a person due to a name change or the like. It gets worse fast. EMR == Electronic Marriage Ruiner

LibreOffice does have one thing going for it. There is, at least, some tendency to have features turned OFF by default. It would be better if the had modules, but that is a far goal for their code base. Legacy features: Remove, Evaluate, Componentize, add handle, place by the curb and see if anyone wants it.

6

Since I used OpenOffice and LibreOffice as an example here’s a followup on those projects…

1 Like