1:Limit and validate input before attempting to process any further logic. 2:Handle any out of bounds input and/or dependency failures with effective error handling and comprehensive logging to allow forensics to show how and why the error was thrown and the inputs or dependency that caused it. 3:make sure the functionality of the new logic is well documented for allowable inputs, desired outputs, snf dependencies, with stakeholders responsible for the requirements well documented so there is no ambiguity about who wanted what, why, and when. If for whatever reason you can't do all of those in your work, something is very wrong with the overall approach and you are in deep doo-doo. I had to code "add-on" features and funcitonality to 3rd party business critical enterprise apps many times. 1,2, and 3 made it possible to do so with minimal stress because the proposed logic could be matched to what stakeholders agreed it was supposed to do (except for defects I created in the logic of course which is my own fault).

Including broad statements about broad statements I presume?

"It's nearly done" has been the mantra of most programming teams since I have been in the business (1994). What happens is that teams always do the easy stuff first. Naturally and with management's glowing approval and encouragement. So of course the "almost done" parts are the parts that noone has yet figured out how to do. This scenario will not change until programming managers wise up, and insist that teams COMPLETE THE HARD PARTS FIRST. And LOL, good luck with that...