The Demise of Patterns and Good Software Practices - Coding is NOT Developing

I've been writing software for a very long time and to my surprise, I still very much enjoy it!

I was lucky to have a father in the industry who first exposed me to the developing trends in the hardware markets back in the mid 1970's (mini computers and mainframes) where I first learned to code on a Data General Eclipse system that took up our entire garage - YES, THE .. ENTIRE .. GARAGE!

My summer jobs were writing micro controller drivers for MUXES that connected through bus expansion bays in these beasts, and they were part of the original NASDAQ platform that launched in 1971 - wow, that was back in the day!

In the summer of 1974, I remember being the only kid in elementary school who brought a CRT and an acoustic coupler to the school fair where I collected one ticket per play for a Tic-Tac-Toe game that I developed.  They could also play a version of "Telephone" which I hadn't yet completed.  It was a huge hit, and most of the kids, including teachers, had never even used a computer before.  I was hooked from that moment on!

My father was always insistent that I go into the software field with a deep understanding of hardware because it would make me a better engineer.  He always felt that IC and board design would become too narrow a discipline and only remain for those who chose to specialize in certain applications.  He saw a ton of opportunity in software - and he was right!

Over the years, mostly the last 20, I've seen a huge decline in what I view as software quality.  However, "quality" is a subjective measure, so it's important that I articulate what I mean by this.  But let me first draw a distinction between "coding" and "developing".

In my view, "coding" is the process of keying language specific keywords into an editor while "developing" is the act of applying sound design patterns and overall industry best practices to your "coding" activities.  It's a design for your code, which is implementing a designed solution for the business - something too many developers have seemingly tossed out the window or rely too heavily on frameworks to provide.

There's tremendous opportunity to incorporate craftsmanship into source code, yet so many engineers either don't know how to do it, or they're content with the idea their code does what's asked of it, so they're done.

I liken this to a person who can swing a hammer and nail two boards together.  While this is definitely a "building" activity, and yes, you could build a Dog House that way, but it doesn't mean you have the skills to build a home, a commercial building, or follow any construction standards whatsoever.  To me, the difference between "coding" and "developing" is analogous to "building" and "construction".  The deliverable from coding may fit the bill, but they're generally short lived solutions that require loads of contact and expensive refactoring over time.  They generally struggle to evolve with change and often end up in the recycle bin for something a bit more elegant.

An even more frightening realization for me came when my adult age son attended a VERY reputable Computer Science School in the Southern California area.  I realized he wasn't being taught proper development practices, and the full scope of what he needed to be learning was being completely overlooked!

As I dug deeper into my discovery, I became more concerned and eventually pulled him from the school and sought a full refund of every penny I put into it.  Since then, I've made it a point to inquire with fresh CS ("Computer Science") grads about their experience, and to my surprise - it would seem the bulk of CS grads hitting the market today are mere coders and not developers.  Instead of the "Learn Java in 21 Days" era, we now have "Learn Java in 540 Days".  It's still mostly about syntax and coding activities - no mention of developer practices, patterns, or individualized personal software processes.  I'm sure some are doing better, because I still meet great engineers, it just seems they're fewer of them to go around these days.

Ask a fresh college grad if they can explain the simple difference between a QUAD WORD and DWORD, or LONG versus an UNSIGNED LONG, and they'll often gift you with that longing deer in the headlights stare that says ... we didn't learn that.  Byte alignment, ENDIANNess - what's that.  Some might argue that with the increasing capabilities of 4GL languages like .NET, Java, and frameworks, there's no need to know this level of detail, but I would argue the simple fact of NOT knowing means you can never make purposeful decisions about when to use each of these constructs - because they're still there and very critical to good development standards.  If that doesn't work, ask them if they know what refactoring even is, or singleton's, factories, delegates, ... , observer patterns, these are all relevant to the "art" coding which is what delineates a "coder" from a "developer".

I worry for the future of software.  If the mobile app marketplace is any indication of what's to come, we can all expect there'll be huge opportunity for engineers who took the time to invest in their careers and learned the "craft" of "developing" good software.

Stay open minded, stay humble, learn at every possible opportunity, and be flexible.  If you can't do these things, you're likely not going to enjoy "developing"  software.  However, you'll be a very capable "coder".