Ugly Code?

http://www.gamedev.net/blog/355/entry-2250790-there-are-many-kinds-of-ugly/

(This is the bakery reference in the above linked article http://www.joelonsoftware.com/articles/Wrong.html )


This article makes a valid point about "the eye of the beholder" issue with code uglyness.  I would make two extension points.

The first is that ugly code may also be a result of code reflecting an ugly problem domain (code in a swamp).  The second would be that it may reflect the limitations of the tools or the staff using the tools (Blunt instruments). 


Coding in a Swamp

Very few problem domains are neat.  Its fairly easy to build an elegant solution in an elegant environment ( such as within the Unix context) however, once you get out into user land with the safety off and profit motives on... mostly people only have half a clue about what they are trying to do, how they want it done, what the consequences of doing it might be and how much they think it will be worth if they have to do it again.  Now multiply the number of users by whatever factor you like and the complexity of the problem domain scales exponentially in so many dimensions it makes your eyes bulge just trying to bound the problem space.  I pity the poor fool who imagines that they can find one neat architecture that will elegantly describe this order of complexity. 

My point being, ugly code in this context is really a reflection of the programmer(s) evolving understanding of the context... its unpredictable, uncertain and often moves in weird cycles and feedback loops involving users learning the tools, which allow them to gain a better understanding of their own environment, which leads them to criticize the tools as being inadequate to describe their requirements... this feeds back to the programmer in "user speak" who then needs to re-imaging a solution in light of their often contradictory, partial or just plain weird information.  The worst part being that the "user speak" is inevitably phrased in terms of "variations" on the semantics of the tool that exists in front of them at the time they made that comment... along with their memory of any variations of the tool that have gone before.  This leads the programmer to see the users request as a variation on what already exists rather than a new framing of the original problem.  Thus we get patches and tweaks on the semantics of what already exists which wanders further and further from the original anchor point of a clean design.

This process never ends.  There is no point at which you get to stop and re-start the project... production code does not die... but some things "harden". Some ideas crystalise and everyone stops finding tweaks and fiddles that they want.  This is the opportunity to factor that "Idea/semantic/feature" out of the mud and clean it up.  While around it the rest of the primordial soup continues to evolve in ugly fits and starts with lots of culling of the weak designs.



Blunt Instruments

The other cause of ugly code is code produced by an ugly process.  This can be poor tools, poor processes, poor staff, poor managment, lack of resources etc etc etc. In summary, code that does not have a low cost to change.  This means code that is expensive for whatever reason, to make better. 

Unfortunately, we exist in an environment that is for all intents and purposes... ugly.  It has rough edges, obstacles and failures. We exist in an imperfect world and thus our code reflects this context. Either accept or face frustration and insanity.  You can argue as much as you wish, make excuses, spend the future or take to drink... whatever helps you cope. 

Evolution is at work on you... and chances are you are not going to win....