When reading xp books and general programming practice books, there is ambiguity and conflicting points on the subject of writing the “simplest” code to get something running.  “Write the simplest code to get the test to pass”. 

Generally the worst code I have seen or written has been with a simplistic mindset.  In other avenues of life the fastest path in getting something done is also the easiest, and the easiest solution is not the usually best.   It is the same with programming.  Most of the time in life the right thing to do is also the hardest thing to do.

It is easiest in a CRUD application, using .net in visual studio, to drag and drop and data bind.  If your objective is to view a table or view in a database, then you are fine.  As long as the application is to be simple, doing a simple thing is no problem. 

There are a few things that turn this simple application into a spaghetti mess.   Business rules for one.   Business rules come in all forms.  It’s these rules your employer hopes that you will capture in requirements and in the software. 

These rules also have a tendency to change.  In education it may be how and what data is to be reported to the State.  In financial applications it could be the algorithm to calculate certain loans.  Where is your business logic?  Did you follow the simple approach and hide the logic among your data binding code?  If a new loan is added or a new required statistic needs to be monitored, how quickly will you be able to implement it?

I worked on a project that was approached simply, with no thought of the future.   We were developing a “functioning prototype” as quickly as we could.  A constant phrase I would hear when suggesting other avenues was, “we don’t have time for that”.  There was no time to sit and think about the fact that the overall project was to last for a year and that the prototype was the first iteration.  We were focused only on getting the proto done. 

For the first two months we were very “productive” adding functionality every day.  However this was an illusion, for most of the features were 85-95% to spec.   It was that last 15-5% that was going to require fine tuning of the business logic.   Something that was a lot harder to do now that we were committed to a poor design.  The logic ended up scattered throughout the application, duplicated in many areas.  Sometimes in stored procedures and at worst horribly written string concatenated dynamic queries embedded in a button click event in a form.  Sometimes it could be found in the code behind of an aspx page others in the html markup itself.  Objects were merely property bags passed from one form to another.  It was obvious that the business rules were an afterthought.

The cliché is “Painting yourself into a corner”.  There is only so much you hack at the same un thought out mess before it becomes too much to understand, too long to change and dangerous to refactor.

Many times I see this line, “Write the simplest code to …”, used to explain why something is “Over Engineered” or as a justification for writing simplistic code. 

The actual statement “Write the simplest code to get the test to pass”, expects you wrote tests.   In turn, this presupposes you thought though your problem and your architecture to make it testable.  Having architecture is not “Over Engineering”, its Engineering.  It’s unfortunate because I want to have a good architecture.  I want well factored code.  However with no guidance on the job, what is a junior to do?  How do you learn when to use pattern x and when not, when your seniors don’t?  Not to mention groan when you ask.

 I’ve been told many times that I complicate issues or that I complicate problems.  I have dug deep to see if that is the case.  While I obsess about my code being good enough, my problem isn’t that I over anything.  What I’ve been taught in school, what I’ve read in books and blogs, and what I hear from experts in person and podcasts all jive.  They all point to patterns and practices which I want to master. 

 My problem is I’ve worked with people who don’t care and take simplistic approaches to every day coding.    They say things like “Well if I had time I would have ‘done it right’” or “Maybe one day I’ll make that [bit of code] more object oriented”.  And in these environments it isn’t long that I find myself doing the same.  Then I have to make a choice: leave,  fight an uphill battle, or live with teh suk.

Not making a decision IS making a decision, a bad one.  OOP may be an unattainable Ideal, that’s fine.

Excellence (Areté) is constantly driving toward the Ideal. [Plato]