My 20-Year Experience of Software Development Methodologies
Nice article! I&#x27;d like to a software methodology more supportive of what I&#x27;d call &quot;Continuous refactoring&quot; or a more &quot;kaizen&quot;-like mindset. &quot;Agile&quot; isn&#x27;t always as agile as I&#x27;d like, but becomes rigid in peoples interpretation of the rules.<p>It&#x27;s a constant fight to keep down the number of lines of code and complexity, in large projects. Once a code-base passes beyond a certain point it becomes difficult to see redundancies and patterns. Bloated code breeds bloated code.<p>If you on the other hand keep trimming and keep refactoring deep and wide as the code and requirements change you can often keep things manageable and understandable. &quot;bad code&quot; get&#x27;s easier to spot, it&#x27;s a little bit like the broken windows theory.<p>Scrum IMO and a lot of the agile methodologies, at least in their implementation, in my experience, tends to treat projects like brick-building and lacks a way to support and enforce constant re-architecturing and removal of code smells.<p>If code quality and refactoring is not supported by the actual methodology it can become an bureaucratic problem where product owners doesn&#x27;t see the value and doesn&#x27;t prioritize it (even though it leads to quicker development time and less bugs in the long run)<p>Unit testing is supposed to make refactoring easier, but can become an impediment to refactoring as well, as the cost of rewriting tests can be seen as too high.<p>We&#x27;re currently experimenting with having one hour meeting each week where you can discuss things like that, and then dedicating some time to refactor,  we&#x27;ll see how it works out :)