Is This The Best (Practices) We Can Do?

 

I've seen a rather disturbing trend over the last 20 years, and no where is it more personified, symbolized and epitomized than in the plethora of developer Q&A and code sample websites that now dominate the software engineer landscape. They seem to fall into two camps if you will:

• A true to form reputation system commanded by experts utilizing a reputation system that rewards users for contributing high-quality content to the site such as Stack Overflow.
  
  
• A more "big tent" community-driven website that focuses on providing resources and tools for software developers, which includes a vast library of articles, tutorials, and code samples that cover a wide range of programming languages and platforms.

The former tends to focus less on complete samples, but holds both the authors of the questions, and the answers feet to the fire as it were for quality and being on target. The downside of such a system is that you need both talent and a rather thick skin to play, though all spectators are welcome. 

The latter is where trouble brews, and where I see the most danger. I often see promise of solutions that either don't pan out, are dangerous or are just plain wrong. I then see the sycophants in the comments sections all blather and vote up '5's (the highest value) on some of the shittiest code I've laid eyes on.

Here is where I must make something clear. This is not opinion of style like where to put curly braces (hence the name of this blog) or where/when to comment code. That's a battle for another day. This is for clearly defined rules:

• Reference counting
• Dispose patterns
• Exception handling
• Object lifetime
• Security and data integrity issues
• Threading and process violations

The list goes on...

It gets worse... the point here isn't about CodeProject or its users, but rather what it portends as to the state of the industry writ large. I cannot begin to expound on the amount sloppily written, poorly crafted unmanageable unmaintainable decrepit rotting reams of code that is supported, defended, protected, championed, endorsed and celebrated by engineers and managers alike.

To be fair, at least on CodeProject when I've interacted with various authors who's attributes claim decades of development experience about the most basic tenets of best practices, it has been well received. Still, I have to ask myself, why was this necessary in the first place?

I also want to be clear about something... this is again not a rail against CodeProject. I do not wish to see that site disappear by any means. Just the same, this problem is not limited to any range of experience, gender, nationality, education, culture, or any other label or marker one might want to drag to the table. All human beings, when they wish to be, can be shining beacons of brilliance, or dumb-ass knuckle draggers. It's an equal opportunity choice.

I alluded to the danger aspect earlier in this missive. The problem with sample code sites and Q&A forums that stray far from best practices is that they are sinkholes of ticking time bombs of code snippets pilfered by lazy engineers who look for the fast cut-and-paste fix without trying to understand the supposed solution they have grabbed with nary a thought. These pieces of detritus now find their way into production code which might be your heart defibrillator, your traffic light control system or your Boeing Max-8 flight control software which took hundreds of lives, God rest their souls.

The food chain begins with a poor education. When I went to school, there essentially no CS department. Software engineering was part of the math department, and beyond some rudimentary courses, what was offered provided little to prepare young guppies for proper software design and architecture. What I learned came from books and technical magazine, which were plentiful back in the 70s and 80s. I also interacted with the hacker community, which allowed to further sharpen my skills.

During the first 20-25 years of my career, the clients I worked for did not care about "shareholder value" and did not get caught up in the development religions such as agile. They wanted two things: get it done on time and under budget, and gave us control. That allowed me to build my network of peers, and provided a rich space to interact, enhance our knowledge and sharpen our skill sets.

Then came the change... during the last decade and a half, the religion wars set in. Focus shifted from quality to cost, from specialists to ridiculous notions of "every can do everything". It became the same idea of the competition where every wins a prize so no one feels hurt. It quickly becomes evident that those with mediocre skills or little passion can burrow into organizations for years at a time, and can not corrode a team and its moral, but the code base as well.

So here we are, present day. When developers and engineers no longer answer to skill and craftsmanship and simply become commodities to be bought and sold to create mediocre dreck that answers to share holder value, we are one screen shot away from another tragedy.

Cleanup on aisle 9.