Hi James, thanks a lot for your feedback. It looks like that you have experienced hard times, and you probably feel frustrated for some of the situations that you had. Also, it looks like that you really care about your job.

About your comment, I might have a few ideas that I hope to be helpful:

• “But what do you say to the programmer who joined the project 5 years into it?”: I have lived that a couple of times, the first iterations are hard because the code is all new, if there is no testing you have to be very careful, and one gets afraid of touching almost anything. But once a few months pass, developers start getting confidence, and knowledge.
• “Agile environment requires they add a feature/ fix bug within the sprint”: I am sorry, but I do not agree whit this at all. Ok, that in the firsts months it is difficult because just finding the line to touch can take days, but if the sprints/iterations feel short, it is not because they are short, it is because the stories are too big. That is a common problem with poorly trained business people, they plan a lot, they create big backlogs, and they end up doing waterfall instead of agile, but disguised as agile. In a right agile environment, features should be as small as possible, delivered as soon as possible, and reviewed and build upon that point. About bugs, they take the time that they need, often bugs are used to hide features not well completed, so, it is not strange that they end taking more time than features itself. The problem, is that any quick fix can be done with enough conditionals, and that creates even more spaghetti code. It is essential to look for the root cause.
• “Those in the business don’t care what it looks like under the covers and don’t accommodate slowing things down for proper redesign”: sadly, most business people do not understand what their business is about: developing software, but that one is for developers. It is the obligation of developers to take the right decisions about the code. Think about it, are business people requesting to implement a feature with a for loop instead of a while loop? No, right? So that’s it, when it is about code, it is the developers’ responsibility, business do not care, and should not care. For example, in the story “How I Fixed 1,000 Bugs In Six Months Without Stopping Delivery” I explain how I disobeyed explicit orders from business and instructed my team to do an undercover refactor. Of course, when they discovered it, they congratulated me because I solved their problems. Business is not qualified to take decisions about the code, those decisions should come from the developers.
• “So here I am, making perhaps a straight line solution but mindful to make it in as small scope as possible as to not break a lot of the spaghetti floating around”, the problem is that every time that this happens the spaghetti code grows. Well, sometimes the straight line is the right solution, but often some things need to be changed and refactored to accommodate it. But, wait, I am not saying to refactor everything, just a minimum piece that can help to the next feature. You can make the design of how you want it to look in one year for now, and make sure that each step goes in the right direction. I know that this kind of thinking is not taught, but there is nothing worse than working in a code that the most minimal change can break anything.
• “The approach described in this article assumes buy in from top to bottom of organization”, I disagree, you have already read how I hide some things from business because they shouldn’t care about it, and we shouldn’t bother them. But it goes beyond that. The main tool for Agile is the retrospective, and the retrospective is the ideal moment to propose and start with new ideas. They are not only about organizational stuff, complaints, etc, they are also for discussing about the mess that is the code, looking for solutions, but also to propose new practices like Mob Programming, and because it is agile, try it, and discuss in the next retrospective. You can find more details here: “Agile Retrospectives for Rigid People”

As you can see, there are a lot of previous assumed concepts in that article, and your reluctance is reasonable. Sadly, software development has been commodified and sold without all the nuances that it requires. Probably I have a lot of stupid ideas, or I have been extremely lucky during my career. Yet, sometimes, I have to confess that using your feet is the best that can happen.

PS After all, bad code is the main reason for developers resignation.