Big ball of mud...

Big ball of mud...  What's the most common, most successful software architecture in the world?  Why, it's the big ball of mud (also known by many other less polite names)!  Every experienced software engineer knows the truth of this.  It is the de facto standard of software architecture.  Every single commercially successful software product I've ever had the privilege to look closely at is, under the covers, one gigantic ball of mud.  It's as if you looked under a bridge and found that it was held up by enormous piles of twigs tied together with shoelaces, duct tape, and used chewing gum.  Every such software product has dark corners in its code where people fear to change anything, because nobody knows how it works.  Or areas where the complexity is so high that it would take days to acquire an understanding deep enough to successfully extend or repair it.  Every one contains layers and layers of software that works around problems in other layers, or covers up the problems of a lower layer while making new problems of its own. 

The one thing I have never seen is a commercially successful software product whose code is pristine and beautiful.

Why is this?  Why are all these software products such a disaster under the covers, in their code?  This fascinating and entertaining paper (at least, if you're a programmer) by Brian Foote and Joseph Yoder delves into exactly that question.  It jibes nicely with my own experiences, where the big ball of mud emerges from the tension between the business need to make the software do something useful as quickly as possible, and the engineering need to make something beautiful, fast, and reliable.  This tension leads to innumerable small decisions in favor of expediency and against the engineer's better judgment.

One of the reasons I'm enjoying the programming I'm doing now, in my retirement, is that this tension is completely removed.  I am free to make the best code I know how to make, no matter how long it takes me.  In my current project, for example, I've already spent a month on a problem that I don't imagine any company I've ever worked for would have allowed me more than a day or two – and I'm not nearly done!  But I'm also not making a big ball of mud.  I'm making something much more beautiful than that.  At least to me :)