I think this is a good example of what has become standard thinking for much of general programming. That the way to write a complex application is an "agile" a

I think this is a good example of what has become standard thinking for much of general programming. That the way to write a complex application is an "agile" approach of hack it 'till it works. The result too often is that slowly over time, the result increasingly approaches being a big ball of mud as seen here. I find in interviews that nearly all programmers only have an approach for two types of applications. The first being a run-to-completion program that produces an output based on inputs. The second being a program where concepts are modeled as data entities, manipulated by behavior (typically just add/edit/delete) in an application/service/controller layer organized using functional decomposition. For problems that don't fit these two, all that is left is that agile hack-it approach. My hope is that some additional lessons were learned about how to apply appropriate program design to produce a result that won't just result in a different mess next time.