As the holidays have crept upon us and the school year has begun slowing to a temporary halt, I found myself yesterday with very little to do.

The inevitable thing that happens to me during such a period is that somehow, in someway, I am inspired through my boredom to begin a new project (or revive an old one). In the next few weeks, I usually end up writing more code than I have in the last quarter.

But yesterday I found myself in a rather unique situation. I was inspired to revive a project I had begun nearly a year ago in an effort to quickly produce something that I could enjoy with my brother. At the time, I felt that the methods by which the code and assets were procured were not important, and (without thinking) sat down to work. It was 9:30 PM.

Now even when I had started it a year ago, said project (which, in its original lifetime, never came to be anything more than a prototype) depended heavily upon hard-coded definitions, linear logic, and absolutely no modularity. For example, despite the fact that I had had variable hotseat multiplayer in mind as a feature since the beginning, I had decided somewhat counter-intuitively that I was going to use static variables, global pointers, and prewritten definitions to control every player, as well as his supporting subsystems, in the game.

Of course, having improved as a programmer considerably over the past year, I decided right away that this was not the right thing to do. So, I quickly began tearing the code apart, abstracting everything to pointers, setting up new data structures for things even as simple as input maps, and redeclaring global, static variables as simple entity skill definitions. It felt almost like an excavation of sorts, as I blew off old functions, commented like crazy, and setup what could eventually be called a project written "the right way."

But by this time it was getting late, I was tired, and I hardly even thought about what I was writing while I was writing it. Consequently, every time I even began establishing what might be an I/O module, I would deem it flawed, delete it, and start over again. Finally at about 11:00 PM I realized that I had completely forgotten the point behind the project: to quickly write some bad scripts to control a silly, forgettable game.

So this is my question: at what point exactly would you call "the right way to do things" no longer the right way? As software engineers, we are (or at least, we should be) notoriously objective and meticulous. If given an infinite amount of resources, we might over-abstract our projects to the point that they hardly even fulfill their original goals anymore, or in otherwords, we might overcomplicate our projects to the point that they become bloated. But at the same time, we understand that we are writing dynamic systems which, through a pool of limited resources, must be able to fulfill each new and possibly unique objective as they appear. But how and when do simpler, yet less robust, solutions become adequate or even necessary to implement?