<story><title>Anti-patterns and Malpractices in Modern Software Development (2015)</title><url>https://medium.com/@bryanedds/living-in-the-age-of-software-fuckery-8859f81ca877#.aq7d22evm</url></story><parent_chain><item><author>snockerton</author><text>This is the same CYA attitude that I have been assuming the last 2 years because it&amp;#x27;s such a frequent occurrence.&lt;p&gt;The only issue is that I still get blamed.  I don&amp;#x27;t know how many times I&amp;#x27;ve repeated this scenario:&lt;p&gt;1. I highlight gap &amp;#x2F; issue in code.&lt;p&gt;2. Team says, &amp;quot;Need to ship; we&amp;#x27;ll accept the risk&amp;quot;&lt;p&gt;3. During go-live, fecal matter hits fan because of aforementioned gap in code.&lt;p&gt;4. Everyone acts surprised.&lt;p&gt;5. I point out that I mentioned it 2 months ago.&lt;p&gt;6. Everyone makes excuses &amp;#x2F; claims they don&amp;#x27;t remember it that way &amp;#x2F; moves on to burn down another project.&lt;p&gt;7. I&amp;#x27;m left to clean up a mess &amp;#x2F; have taken a hit to my reputation.&lt;p&gt;Not sure what I&amp;#x27;m doing wrong...</text></item><item><author>mi100hael</author><text>I generally agree with the author, but as a software developer, I try to stay much less emotionally attached to the end-result.  If I have concerns about the long-term stability and viability of a code base, I&amp;#x27;ll raise my concerns with the project manager or whomever&amp;#x27;s making the decisions on what to prioritize.  But if they don&amp;#x27;t want to, that&amp;#x27;s their prerogative.  They&amp;#x27;re higher on the chain of command than I am.  I&amp;#x27;m certainly not going to lose sleep over it.  When the house of cards does come crashing down and it takes two weeks to add a simple feature due to tech debt, or worse, some bug surfaces that takes down a production deployment and takes more than an hour to fix, my ass is covered.  I have an email trail raising concerns that went ignored.</text></item></parent_chain><comment><author>bpyne</author><text>Perhaps you&amp;#x27;re doing what I&amp;#x27;m about to recommend already, but I can&amp;#x27;t be sure based on what you wrote. It&amp;#x27;s in regard to &amp;quot;2. Team says, &amp;quot;Need to ship; we&amp;#x27;ll accept the risk&amp;quot;.&lt;p&gt;If the Business Unit, for whom the software is being written, has a representative on your team, then make sure you explain the risk in purely business terms, not technical ones. A BU rep&amp;#x27;s ears are going to perk up with statements like &amp;quot;invalid posts may get written to the general ledger&amp;quot; or &amp;quot;1 in every 20 orders may get dropped&amp;quot; rather than &amp;quot;universally scoped variables are being overwritten by invalid data in some cases&amp;quot; or &amp;quot;uncommitted nested transactions may cause a core dump.&amp;quot;&lt;p&gt;If your team doesn&amp;#x27;t include a BU rep, then you could always get friendly with one and explain the potential risks over coffee or lunch. Perhaps even suggest some questions the rep should ask the team before the mod goes live.&lt;p&gt;In my situation, a BU rep is always part of the team and I rarely have other developers on the team. The reps and I have lunch together regularly anyway, so they get my opinions and recommendations that way.</text></comment>
<story><title>Anti-patterns and Malpractices in Modern Software Development (2015)</title><url>https://medium.com/@bryanedds/living-in-the-age-of-software-fuckery-8859f81ca877#.aq7d22evm</url></story><parent_chain><item><author>snockerton</author><text>This is the same CYA attitude that I have been assuming the last 2 years because it&amp;#x27;s such a frequent occurrence.&lt;p&gt;The only issue is that I still get blamed.  I don&amp;#x27;t know how many times I&amp;#x27;ve repeated this scenario:&lt;p&gt;1. I highlight gap &amp;#x2F; issue in code.&lt;p&gt;2. Team says, &amp;quot;Need to ship; we&amp;#x27;ll accept the risk&amp;quot;&lt;p&gt;3. During go-live, fecal matter hits fan because of aforementioned gap in code.&lt;p&gt;4. Everyone acts surprised.&lt;p&gt;5. I point out that I mentioned it 2 months ago.&lt;p&gt;6. Everyone makes excuses &amp;#x2F; claims they don&amp;#x27;t remember it that way &amp;#x2F; moves on to burn down another project.&lt;p&gt;7. I&amp;#x27;m left to clean up a mess &amp;#x2F; have taken a hit to my reputation.&lt;p&gt;Not sure what I&amp;#x27;m doing wrong...</text></item><item><author>mi100hael</author><text>I generally agree with the author, but as a software developer, I try to stay much less emotionally attached to the end-result.  If I have concerns about the long-term stability and viability of a code base, I&amp;#x27;ll raise my concerns with the project manager or whomever&amp;#x27;s making the decisions on what to prioritize.  But if they don&amp;#x27;t want to, that&amp;#x27;s their prerogative.  They&amp;#x27;re higher on the chain of command than I am.  I&amp;#x27;m certainly not going to lose sleep over it.  When the house of cards does come crashing down and it takes two weeks to add a simple feature due to tech debt, or worse, some bug surfaces that takes down a production deployment and takes more than an hour to fix, my ass is covered.  I have an email trail raising concerns that went ignored.</text></item></parent_chain><comment><author>sopooneo</author><text>You have to win people over by making their lives easier or by making them look good. This does not necessarily have to be related to code or technology in any way.&lt;p&gt;Then, after people have a visceral positive feeling about you, make some tiny suggestion for improvement. Make the improvement, and whoever approved it, do something to make sure they associate your suggestion with a positive experience.&lt;p&gt;Slowly repeat. It is a slight selling of your soul. It is effective.</text></comment>