Your Code Is Your Standards

Question

Your Code Is Your Standards

Steve Jones - SSC Editor

SSC Guru

Points: 736430
More actions
March 25, 2021 at 12:00 am

#3859239

Comments posted to this topic are about the item Your Code Is Your Standards

Viewing 8 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic. Login to reply

skeleton567 SSCertifiable Points: 5873 More actions · Answer 1

From my perspective I think time is the largest factor affecting our code base. Time to design and develop code, time to maintain code, time to develop a higher level of skill, newer versions of tools, changing requirements.

What we must remember is that our code is not a finished product that we frame and hang on the wall. It is the set of tools that we use to meet needs that are themselves ever-changing. We derive satisfaction from producing code that accomplishes a task but must do this in an environment where we always are aware of this, trying to always do the best with available resource and be willing to adapt as appropriate and with available resources.

Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )

Steve Jones - SSC Editor SSC Guru Points: 736430 More actions · Answer 2

I completely agree, Rick, on both points. Time is valuable, and we ought to be thinking more than we code. Observe, learn, and think.

It's also not finished. Early DevOps view, as people tried to find better ways to explain this, was that your code needs to get into production before you as a developer, think it's done, and then you work on improving it constantly. The view from many people now is that you own, love, criticize, and continue to look at the code until it's actually retired from production.

Maybe replaced with your own code.

I think many developers want to take this view, but often management gets in the way.

frederico_fonseca SSCoach Points: 16165 More actions · Answer 3

ahhhh... and issue is that its not only SQL developers that introduce "issues" like this.

A EF extension (https://github.com/borisdj/EFCore.BulkExtensions) built to make it easier for C# developers to do high speed inserts/updates in a single statement was built using MERGE statement - and with defaults that made me had a go at a team implementing it without even looking at the options available to those calls.

default call

context.BulkInsertOrUpdate(entities1List);

without changing any of its configuration, will do the following

create table (temp####) on destination db - with a semi-guid on its name
sqlbulkcopy to table temp####
merge from temp#### into final table - without even checking if data has changed when doing updates
drop table temp####

and taking in consideration that a significant number of people only download the dll and not the source code of the solution they don't even see what is doing in the background - neither do they care - let the DBA's worry about it if it is not optimal.

skeleton567 SSCertifiable Points: 5873 More actions · Answer 4

Steve Jones - SSC Editor wrote:

It's also not finished. Early DevOps view, as people tried to find better ways to explain this, was that your code needs to get into production before you as a developer, think it's done, and then you work on improving it constantly. The view from many people now is that you own, love, criticize, and continue to look at the code until it's actually retired from production.
Maybe replaced with your own code.
I think many developers want to take this view, but often management gets in the way.

I think the largest problem with developing and maintaining code was the implementation of Project Managers in one company where I was a DBA for eleven years. The situation quickly morphed into an environment where these people did not manage 'projects' but instead essentially 'owned' specific systems and therefore the code of those systems.

Maintaining and improving code was nearly impossible do to timid managers fearing to release fixes and improvements, to the extent that many changes laid on the shelf and were never released.

Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )

Rod at work SSC-Dedicated Points: 34015 More actions · Answer 5

Oh, Steve, you've picked a topic that I'm passionate about. I'm going to do my best to keep my response as short as I can.

In my previous job, where I was at for many years, we started with an IT (both dev and operations - we had to wear multiple hats) of four people. We started defining standards. For the most part, we stuck with them. Like you said, as we moved along, we changed how we coded, the patterns we chose and so on. But for the most part, we stuck with what we defined at the beginning.

After being laid off that position and coming to my current job I was expecting lots of things, one of them was some standards. I also expected them to have libraries of components, or source code components. I remember spending several weeks looking for a repository of code modules, documentation as to how certain often repeated tasks should be performed, etc. There was none. Indeed, they were only just getting up to speed on using source control. For a large state government agency, I was shocked at the lack of cohesion in specifying how things should be done and everyone re-writing code to perform some task for God only knows how many times.

But maybe I'm was expecting too much. I wonder, maybe this is just the way it is everywhere? Maybe when you're just getting up to speed with source control, you're so unused to having a standard, or expecting every group to develop its own standard, or expecting everyone to make up their own standards, that that's just the way it is.

I'd like to know, those of you who are working for large organizations, is it that way in the beginning? Does it take several years for a large group to get around to defining standards and building a common code base, so people don't have to constantly re-invent the wheel?

Kindest Regards, Rod Connect with me on LinkedIn.

Chris Wooding SSCarpal Tunnel Points: 4558 More actions · Answer 6

It seems that standards tend not to be developed until there's already a large body of existing code. You then have a choice of following the standard or following the existing style. I was "lucky" enough to be part of the standards body at my current employer when it was first established. Most of them related to COBOL because that's what the main application was written in. Unfortunately there were several forceful personalities on the committee, so the standards ended up being "You can do it this way, or this way, or this way, but if you're amending existing code, keep to the style that is already there.", ie. do whatever you want.

Jeff Moden SSC Guru Points: 1004402 More actions · Answer 7

The typical reason why there are typically no standards, particularly when it concerns databases and the related code, is because of the "code first" mentality that I've seen at oh so many companies. It's only when they get into trouble that someone even suggests the ideas of standards. By then, it's usually too late, not only for the standards, but for the design of the database and, of course, no one wants to spend the time to "fix" something that seems to be working.

The other problems with standards are a lack of enforcement and "allowed deviations" because of some god-forsaken schedule. Unless you have someone that "brutally" enforces standards and is allowed to stop code from moving forward with the full support of management, standards become a joke. This also applies to the "tools" allowed.

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)