| I take it that by design you mean code quality and that you include error handling in edge cases. Yes bad things do happen in the real world: connections fail, files are missing, input are invalid, programs have bugs,... Yes you do have to handle it: validate data, check status code, add guard conditions, report errors, document input, returned codes and thrown exceptions. Here is a nice article on error handling in programs if you are interested (for node.js but most is universal): https://www.joyent.com/developers/node/design/errors. Yes it makes program larger. That cute 10 liners that throw an exception to the user's face if anything goes wrong will end up larger. But does it make the code bad? No it does not. It makes the code correct. In business software, edge cases and error handling routinely take more effort than the standard case where everything goes right. It's not a wart, it's a fact of life. A piece of code is not finished when it appear to work. It is finished when it is written, robust, clean, documented and tested. Cutting corner means that when the bug report inevitably arrives a lot of time and energy will need to be spent. Way more than doing the right thing the first time. "that's exactly what the really productive, fast paced coders in my company do.". They appear productive and fast paced but they are not. They only appear to be so because they twist the definition of done. By moving the goalpost they throw a bunch of garbage over the wall wishing good luck for some sucker later on. But, hey, it sures look good for management. That's not even adding technical debt, technical dept implies you make a deliberate trade-off. This is just burning money. |