Software Development Standards

I have been involved in the development of software solutions for almost 35 years. While a lot has changed in the technology being used, one thing that has remained constant is the value of Development Standards. When I hear about issues and challenges with other software development teams, it is often the result of poor (or completely missing) development standards. Poorly defined standards can result in quality issues, support issues, non-value-added debates, and many other challenges that reduce productivity.

The term "development standards" could mean a variety of things. When I use that term, I am referring to standards/rules that cover all aspects of the SDLC, including (but not limited to):

• How requirements are written (e.g., the structure of the sentences)
• The structure of design documents (e.g., the names of each section, the order of those sections, the expected content of each section, etc.)
• The official list of terms that can and should be used
• The official/approved list of acronyms and abbreviations
• The naming convention for documents, code objects, projects, code variables, etc.
• SQL standards that cover table, column, index, procedure, etc. naming; structure of SQL queries, etc.
• The approved coding style (e.g., where the "{ }" are placed, indentation/spacing, comments)
• and much, much more

The value of good development standards can not be overstated. As harsh as this may sound -- you don't want your development team to think. What I mean by that is -- the team shouldn't have to think about the "HOW". They should be focused on the "WHAT" -- what are the requirements? what is the business logic? what code objects must be developed? what are the test cases? The "how" should be so well documented and communicated that it occurs automatically.

When development standards are thorough and followed, there are other benefits:

• It's much easier to scan the code base to find instances of things. For example, if the naming standard for variables is well-defined, then finding all code that does something with a customer identifier (e.g., "customerId") is a simple search. A poorly defined standard may require looking for many permutations and even then you will miss some because you couldn't guess at all the ways a developer may have named the variable.
• Future technology upgrades or pattern changes can likely be performed much easier and be automated. For example, in a solution I worked on we had over 100 WCF services exposing over 1500 operations. When it came time to upgrade to .NET 5, which didn't include native support for WCF, we decide to switch to gRPC. Because the codebase followed strict naming and structure standards, we were able to create a custom tool that parsed the existing code and generated new code for gRPC. A task that would have taken multiple people many months was completed by one person in about two weeks.
• The learning curve is significantly reduced for new team members because everything is consistent. A new developer can look at any of the code and understand it and support it. It will be easier for people to find there way around the database and "self discover" what they need.

There is so much value in having solid development standards that I firmly believe you need a dedicated resource on the team that owns those standards. They create the standards, review with the appropriate leads, refine the standards, communicate and educate, monitor and enforce the usage, and constantly look for opportunities to enhance the standards.

How to Elevate your Software Development Standards?

Here are some tips based on my experiences:

• Be Specific - leave nothing to chance. Don't assume the reader will interpret the standard they way you want, instead assume they will misinterpret. For example, consider this naming standard for a script:

S<Action><Noun><Team>

If that was the extent of the naming standard, you will have a wide range of names: ScreatebillBI, sCreate_Bill_Billing, SCreateBillBillingTeam, etc. The standard needs more details like the following:

S<Action><Noun><Team>

1. Must start with capital "S"
2. <Action> - start with capital letter and be one of the following: Create, Delete, Update, Retrieve
3. <Noun> - start with capital letter, no abbreviations, single word
4. <Team> - all uppercase and one of the following: BI (billing), CR (credit), FO (front office)
5. Do not use any hyphens or underscores in the name

Given this more detailed standard, there is only one valid name for our example: SCreateBillBI

• Provide and maintain a list of valid values. In the previous example, the revised standard included the specific list of allowed values for the Action and Team components. Ideally it would also include a list of the valid values for the Noun component. In cases where the list of values is long, it may be better to maintain the list in a separate document (e.g., spreadsheet) and define the process for having values added to the list (e.g., send a request to the Development Standards Manager).
• Start by defining and documenting your SDLC to include the process and all artifacts (e.g., documents, code objects, database objects, etc.). Each type of artifact must have standards defined for it. Those standards should address names, structure, where to store, etc. Then consider the processes and think about the standards to define that would help with the ability to automate and industrialize those processes. When all instances of a given type of artifact looks the same, it becomes easier to automate processes and add other steps to enhance the process.
• Accept the reality that not everyone will agree, but you must achieve acceptance. I find it is best to have a Standards Review Committee that consists of 3-5 people. The committee should at least consist of an architect, a design lead, and the standards lead. This will provide a good variety of perspective. Having a committee will eliminate the feeling that one person is dictating and only doing things the way they want. Developers tend to have their own "style" and believe the way they code is the best way. It is extremely unlikely all developers on the team will have the same experience and preference for coding style. This means some will be forced to code in a style they aren't used to (and in some cases may actually hate). Whatever you do, do NOT tell them their preferred style is wrong! It is not a debate of right or wrong, it is all about the value of having a single standard that everyone follows.
• Utilize tools (purchased or custom) to help enforce the standards. On a large project there will be many standards defined. The team consist of humans, and none of us are perfect. Mistakes will be made and having tools that scan code, documents, data, etc. to identify items that don't conform to the standards is both necessary and extremely beneficial.

I hope this article provided at least one nugget of information that will benefit you and your project. While it is certainly best to start your project with development standards defined, It's never too late to get them defined and start using going-forward.