Common Sense Coding


In the past ten years or so a lot has been made about software development paradigms such that we have gone from a credible N-Tiered development standard to such innovations as MVC for web applications and Microsoft’s MVVM for desktop WPF applications, along with variations of each for the specific languages that developers are interested in coding in.

Both paradigms have many advantages when implemented in a clean and efficient manner.  Much has been touted as to how using such paradigms will make development cleaner and more efficient, which is not true as standards and paradigms cannot perform such a miracle.  They are simply guidelines for development.

Developers can produce very sloppy implementations with these and other paradigms that are promoted in the development community making such implementations as inefficient as the older standards that have been derided as being “old” techniques.

The same can be true of the various new languages that are being offered and being taken up by new professionals (ie: Apple’s “Swift”, Google’s “Go” to name but two).  Debates abound as to the efficacy of one language over the other; a debate that still continues between C# and VB.Net developers as well as between C# and VB.NET developers and their enterprise rivals in the Java Community.

Most new languages today, in terms of their syntax, are simply variants on the C\C++ languages, languages that were always falsely advertised as easy to learn.  Some of these newer languages implement interesting innovations that developers may see as advantageous to their specific project requirements.

Yet again, the language used will not make the results of a development project any more efficient than any other language would.  Practically all languages do the same things.

In all cases it comes down to the expertise of the developers involved and their level of professionalism towards the quality of their designs and coding as to how any language works against any paradigm adopted.

Today the common-sense approach towards development appears to have been subordinated to the “newest” and “coolest” technologies being promoted by vendors and their supporters in the development community. Discussions on languages and paradigms abound in online forums, blogs, and technical advertisements as the way to do anything for the new “mobile computing” standard, let alone the original web and desktop standards.

And there is nothing wrong in adopting something new or following a popular development paradigm for the right reasons.  However, the incessant roar over such adoption is drowning out quality coding practices that years were ago were far simpler, more efficient and much more productive.

Common-sense coding merely stipulates a few primary constraints on any development project… including the use of common sense…

One; code is always written for the least experienced person that would be part of any particular development team.  This was a standard that hails back to the mainframe era, which today makes more sense than ever considering the inordinate amount of technologies and knowledge that any one professional must master efficiently.

Professionals come with all levels of capabilities.  The slower developer may actually produce higher quality code than the current “star” in a group.  And the less experienced person may actually have more to contribute if he or she were able to manage the project source code more easily than having to struggle with understanding new techniques and syntax simply because others thought it would be “cool” to use them.  And once a team member is struggling to catch up, the entire project suffers from an inherent inefficiency.

Many project leads and managers simply resort to the idea that such a lack of experience on a developer’s part is their problem, which in the end simply makes that problem their own.

Two; application projects of any type should be cleanly modularized so that if necessary, various parts of an application could actually be separated from its core to operate independently on remote servers.  This is the N-Tiered standard and in most instances there will be no need to decouple components in such a manner but the discipline of developing in such a way does add to the quality in which a project is broken down into accessible and manageable components.

The idea of component separation has morphed over time to the idea of “loose object coupling”, which under certain circumstances (ie: complex hierarchies involving polymorphism) is appropriate.  However, simplistic and well defined component separation is most often more than enough to break up an application into manageable parts.

Three; don’t try to code for performance.  One of the most idiotic standards that many technical managers have fostered on their teams is the idea that specific coding techniques will yield superior performance for critical areas of application processes.  To some degree this may in fact be true but what are we talking about here, a few milliseconds?  Humans cannot interpret time in milliseconds so why would one expect that saving a few of them would make any difference?

Of course, there are obvious things that can be done to boost any particular application’s performance such as using properly designed indices against database tables.  However, making a decision between using an indexed or object-based “For Loop” when only a small set of records may be interrogated during the process is a waste of time.

When source-code is compiled today it is done so against highly efficient compilers for which many years of research towards internal optimization refinement have been implemented.  It is highly unlikely that any single developer will be able to optimize his or her coding beyond such a level of efficiency in any single compiler.

If speed is what you need than use a language that produces native executables but even here, modern-day semi-interpretive languages such as C#, VB.NET, and Java are still quite fast comparably speaking.

Four; learn to do proper requirements gathering up front so that your design reflects exactly what is intended.  The idea that any development paradigm such as “Agile Development” can somehow allow for a constant barrage of changes to an ever expanding code base and have that code base remain coherent and workable is a pipe dream that many professionals are still pursuing today.

The “Agile” paradigm (which came from the original and failed “Extreme Programming” concept) is based upon the elusive idea that application development can be made completely flexible to the needs of the managers and users involved.  It can’t and the result of this belief in such a capability is that application development is nothing more than a form of silly-putty; pliable enough to accommodate whatever managers and users require without coherent planning up front.

You can slice it any way you want but in actual practice, such paradigms see good design practices eliminated for the sake of expediency.

Five; finally, develop a consistent, personal elegance and style when writing code.  You would be surprised at how sloppy many developers are today since code is now viewed as merely a commoditized tool we use to get an application up and running.  As a result, increasingly, the code base in the United States is becoming nothing more than a digital “Tower of Babel”.

When a new team member comes on board to a project and he or she has to struggle to understand what the original developer or developers were trying to do as result the door has been opened to increased defect production, which costs time and money.

It used to be that one of the hallmarks of a truly great developer was that his or her coding style was easily readable and understood by everyone who reviewed their code.  It doesn’t appear to be that way today and the results show it.


If you have reached the end of this piece and believe that the propositions here are “old school” and\or laughable than I would suggest a read of Peter Welch’s, “Programming Sucks”, ( to get a real overview at what our profession has become over the years…



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s