The difficult definition of professional software development

Here are some of the contradictory phrases (and a few paraphrases) I’ve overheard used to define what is “good” and “bad” code.


The part that is most difficult about that list for me is while I agree with half of it strongly and respect the people who said those things, the other half that list I do not agree with, has all come from people I respect and who overall do some pretty impressive things. They’ve certainly created things by all measures more impressive than anything I’ve ever produced

This leads me to question how much do software principles matter when taking them out of the context of yourself but viewing it in a bigger picture. Thinking about it, 95% of the software that I actually like probably wasn’t using any TDD at any point in time and certainly violates a number of things that I would consider required for “professional software”. I keep reinforcing this fact every time I checkout the source of a major software project I’ve used for years and gasp in horror at the spaghetti code I find.

Worse still the different schools of thought are not compatible in the slightest, and one side views the other side as wholly unprofessional (granted for different reasons) to the point that I’ve realized I myself was perceived as the one being “amateur” by those with a different definition of what makes good and bad software. I of course unfortunately often thought the same of them, regardless of how I felt about them personally.

Anyway, this is all food for thought and I have not yet come to any conclusion what it all means. It’s just easily the most frustrating thing about our profession and has on more than a few occasions had me long to return to being a sysadmin (too bad I really love making things). I know I’ve tried coding under other schools of thought and while through practice I was able to deliver well enough, I’m far slower and more error prone with no TDD, big mega classes, and avoiding dependency injection