tag:blogger.com,1999:blog-2370750636520999922.post4413643065972701424..comments2021-09-25T15:37:39.704-07:00Comments on TheHackerCIO [TheH4ck3rC10]: Creating Tomorrow's Legacy Code TodayAnonymoushttp://www.blogger.com/profile/04501836762237480464noreply@blogger.comBlogger1125tag:blogger.com,1999:blog-2370750636520999922.post-43767649966887969652013-09-19T12:26:10.575-07:002013-09-19T12:26:10.575-07:00With code as with everything else in life, we make...With code as with everything else in life, we make decisions in the face of uncertainty. There are lots of decisions to be made and each has lots of tradeoffs whose merits can not be fully appreciated until Other Things happen. <br />Things like <br /> - doing the hack enabled you to ship, hit your quarterly numbers and prevent a wave of layoffs<br /> - doing the hack resulted in a maintenance headache for the guy who needed to extend a feature that didn't exist when you did the hack<br /> - doing the hack resulted in no problems over the entire life of the project.<br /><br />Any of these is a possible outcome. When you need decide to do the hack or opt for a more fully engineered solution, you are guessing which one is most likely. That, much more than our abilty to point out "not good enough" is what we get paid to do.<br /><br />You mention crutial code in assembly that no one understood. When I found out that we had a similar situation on a new product we shipped 10 years ago, I was similarly concerned. In the next 5 years of maintenance, we did lots of enhancements, lots of fixes and the product seemed well recieved. The assembly routine never needed touching. It could easily have been different.<br />msrhttps://www.blogger.com/profile/06222000037855057058noreply@blogger.com