Does the software industry have a practice of using a standard classification or work-product coding system like construction uses CSI codes? [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 3 years ago.

Improve this question

Overview

This question really becomes can I ask a software developer in Argentina or a software developer in Zimbabwe for a component in a standard way?

Background

Something that acts like I am thinking is how in the construction industry there are industry-specific classification codes, the Construction Specifications Institute's Master Format (CSI). This standard classification of work product codes allows me to ask both construction firms in Argentina and Zimbabwe for Fire Protection Piping according to the 16 divisions of the construction industry coding system. The code for this piping category is 15300.

Question

Can I do that in software? Is there some listing of abstractions and implementations or a mix of the two that we can use to communicate at a higher level? One thing that comes to mind is that I can ask for and HTTP server. A common abstraction that we use frequently to get things done yet is also not implementation specific. Is there a universal address or catalogue in which an HTTP server has a name and a reference number?

Sure, all software is different and needs to be customized to the needs of the user. However, I can ask for a login screen and everyone knows what I am talking about. Has there been any successful or unsuccessful attempts in our industry to take the common components, like the login screen, server hardware, CPUs, network devices, electrical wiring, communication protocols, even different types of programming libraries, and to assign categories and numbers to these things? And, is there a system in wide enough use to enable people from across the world to ask for things in a standard way?

EDIT 1

After CandiedOrange and mmathis commented on this question I realized I need to further qualify my inquiry. It looks as though any system I would find would have items on a sliding scale of abstraction and implementation. The categories would likely be more abstract and the individual line items in each category would approach greater and greater implementation specificity and less abstraction. If the line items get too specific then as CandiedOrange pointed out it would end up being code.

So it seems as though this classification index would necessarily be more abstract than the code it classifies, so it would never be exact. It would always be a rough categorization. Just like saying something is an HTTP server does not completely describe Apache Tomcat yet Tomcat could legitimately be listed as an HTTP server.

As such what I am looking for is not like the IDC Software Taxonomy suggested by Christophe because that is a listing of software markets, not software component abstractions. The IDC Software taxonomy is a description layer that could be further qualified by describing the component abstractions used in each market, yet it is not a listing of software component abstractions.

I imagine that the listing of software component abstractions would likely be somewhat market specific but would largely be market agnostic since a component can be used in multiple markets for many different reasons.

Example

Is there a classification system from which I can ask for a particular login screen by saying "Give me a 29305-compliant login screen system, and by the way, here is my color scheme. Make it look good and make sure it works," where the number 29305 refers to a specific kind of authentication system, for example, the password grant flow of an OAuth2 system using JSON Web Tokens?

Motivation

The reason I look for such a system is to have a less lossy communication protocol between those asking for software and those creating software. It seems that if we had an IT industry component classification system we could communicate much faster and reduce cost of communication as well as the error rate while increasing quality.

Existing Product

The closest I have come is the WAND IT Taxonomy. The downside with the WAND taxonomy is it has no addressing scheme and is not public; you have to pay to even see it. Here is a high-level view from their site:

Analysis Criteria

I consider the WAND taxonomy a partial answer to my question.

1. Encodes category names with numerical or alphanumerical sequences or in a consistent, context-specific manner. Though CSI uses strictly numbers in the 16-divisions I have no problem with alphanumeric codes. The category encoding ends up being a character data type anyway because of leading zeroes, dots, and dashes, like the Dewey Decimal System.
2. Comprehensive or at least makes an acceptable effort at being comprehensive in our industry.
3. Recognized by a generally accepted standards body as appropriately descriptive or authoritative for the subjects covered in the classification system.
4. In use by many businesses today.

When I find a satisfactory answer I will update this question.

Update

Response to mmathis's answer and comments

Overall response

The things you said represent where I started from when first thinking about this question. I am still looking for an answer because I haven't yet found a useful solution to the knowledge management question I have.

It seems as though we can conclude that a taxonomy of implementation-specific items would be nearly useless because it would (1) become obsolete on first writing and (2) be nearly impossible to make without specifying the resulting code.

I believe I should have better qualified my question and motivation. It looks like I led you to believe that I am looking for a way to ask for a specific kind of button or a specific kind of login screen. Rather than the specifics I am looking for a system, a taxonomy of sorts, of expert communication that facilitates communicating with abstractions, not specific implementations.

For example, when you say,

So, while it's good to know that your application will at some point authenticate users, trying to say that it will be done via a code-29356 login screen is meaningless

I am not thinking the taxonomy would say a code-29356 login screen and then have the meaning of that screen be implementation specific such as a box this many pixels wide or with a red color. I am thinking the code-29356 login screen would be a definition of an abstraction which contains two inner abstractions of a username control and a password control.

There are some generally understood components, like a login screen or settings page, but they are not useful beyond a high-level description of the application - not nearly detailed enough to start building or ensure compliance upon delivery to the customer.

One of the ways I am thinking such a component taxonomy would be useful would be in knowledge management even at one company. If I as the first engineer at a consulting company develop an authentication system I should somehow file that authentication system in some reference manual somewhere so I can get back to it and train the next guy. Ideally I would have documentation at least on the research I did and sources I used to help me make the auth system. Sure things change, though I make the claim that not everything starts from scratch.

It seems like it would be much faster for a new programmer or a programmer new to a project to learn what is built in the system if there was some sort of mind map of commonly components that described the system. This would apply to networking and hardware

We don't classify login screens or buttons based on codes, but we do classify Oracle databases, and SQL databases, and third-party libraries, and encryption algorithms, and more.

Yes, we classify these things. We have version numbers yet we are missing the high-level, easy to browse list of abstractions under which to categorize these things.

Answer 1

No, nothing like that exists in the software industry, at least in the sense that you are thinking. There are some generally understood components, like a login screen or settings page, but they are not useful beyond a high-level description of the application - not nearly detailed enough to start building or ensure compliance upon delivery to the customer.

As @whatsisname mentioned in the comments, different business entities will have different requirements for their login screens. Banks, social media, email, military, a fitness tracker, etc will all have different requirements, and there may be no real commonality except the need to authenticate a user somehow. Even the manner in which the authentication is done may be different - fingerprints, retinal scans, username/password, smartphone proximity. So, while it's good to know that your application will at some point authenticate users, trying to say that it will be done via a code-29356 login screen is meaningless, as that code will have been invented to convey your specific set of specifications for how the login screen should look and behave.

When you get into actually designing or building the UI, for example, a lot of the individual components have generally agreed-upon names - button, checkbox, etc. There is no numbering or classification scheme to them, however, since the names function perfectly fine. I can tell a developer in Argentina or Bangladesh that I need an app with a textbox and a button and he or she will know exactly what I'm talking about*. It would be superfluous to say I need a code-2923 textbox followed by a code-45231 button. What I might specify is the size and/or (relative) location, but again that is likely a specific requirement for my particular application and would not be meaningful to developers outside my company.

One other complication is that software changes extremely fast, especially as compared to the construction industry. While various types of building codes may be updated once a year, if that, there may be two or three or four releases of a particular software application in one year. Even the idea of a login screen has morphed from a simple set of textboxes for username and password to complicated screen full of password rules, social media integration, biometrics, mobile compatibility, and a whole host of other considerations. New design paradigms are ushered in to distinguish one application from another in the huge marketplace, components grow and wane in popularity as technology improves, and all of that happens faster than any book of codes could be updated in a meaningful way. Buildings and structures are designed to stay standing for decades, if not centuries; software is ancient if it's older than 5 years or so.

And that brings me to the real crux of the matter:

Most anything in the software engineering industry that needs that level of specification already has it, in the form of a version number. We don't classify login screens or buttons based on codes, but we do classify Oracle databases, and SQL databases, and third-party libraries, and encryption algorithms, and more. Those version numbers allow customers, software engineers, product managers, etc to all communicate with each other to ensure compatibility among applications, compliance with regulations and best practices, and various other criteria.

I'm not sure your motivation is properly motivated, either. If you want a login system which uses the "password grant flow of an OAuth2 system using JSON Web Tokens", just ask for a login system which uses the password grant flow of an OAuth2 system using JSON Web Tokens. That system will probably be replaced by something else in a year before any book could be updated with a definition for code 29305.

---

*But even that belies the complication of software development, as that developer may have a whole host of other questions based on what kind of development he or she does. Front-end developers may be more concerned with UX and specific location, sizing, color vs back-end developers that look for something that's just functional, so may want some additional clarifications from me. Developers who write in C# will approach it different than those who write in python or angular or java or c++. They all know what a textbox and button are, but the way they approach the implementation will be different.