Keeping Codes as Codes
-
A lesson that I learned, long ago, was that codes need to remain codes and not experience a form of feature creep in which humans desire to read more into codes than the codes really contain. It requires some examples to make this make sense, but this is a general problem and not unique to a specific instance.
The most common scenario in which I see this happen is with IP addresses. Businesses often try to not treat IP addresses as the "under the hood" addressing that it is but attempt to implement some strong "order" to the addresses such as keeping servers in a special address range, or subnetting departments by address blocks not for management or security, but simply through some misguided form of housekeeping. This all sounds great at first but as networks grow and change over time these address schemes fail and become the bases for a quagmire of addressing problems ranging from issues in growth to confusing address order fragmentation to human error and slowing of changes as humans have to put more and more time into figuring out what to do. Instead, abstract human interaction away with DNS and don't worry about maintaining order "under the hood." Don't try to read into the IP addresses, that is not their purpose.
Where I first experienced this issue of "reading into" codes what with barcodes on the WasteWatcher project in the late 1990s. When converted to ASCII text the barcodes were human readable. This was so that they could be entered into a system via a keyboard wedge. The end users would get to know what the barcodes were and would start to read into the letters and numbers and started creating new barcodes with human intentions built into the ASCII translation of the codes. At first no one noticed but over time it created all kinds of problems as these were nothing but codes and were not designed to hold the kind of data that people expected. We had all kinds of confusion, unavailability of desired codes, mistakes made and just general problems because people wanted to treat the codes as something more than they were - database ID fields.
Another place I have seen this, far less frequently, is in PBX extension numbers. It is tempting to want to assign a block of numbers to departments, floors, teams or sites. But, like IP addresses, this becomes slowly problematic over time. As one department grows too big and overlaps the block for another department or as people move between departments either complicated number changes take place confusing everyone or number block fragmentation takes place making the system worse than having done nothing because everyone knows that the blocks mean something but they are inconsistent.
All of these cases really come down to the codes in question being a form of identifier in a database at the end of the day. Any database ID field must be treated as an ID, not as something to be altered and managed. Any relational database student will stress how important it is that ID fields be treated carefully and kept away from end users.
The takeaway is... codes are codes. They are not more than that. They cannot be. There is no need or value to trying to make "under the hood" codes mean something that they do not. Treat them as they are and you will have an easier time managing them and mistakes will be reduced because the codes are used correctly and consistently.
-
Makes sense. Unless there is a security reason for keeping IPs separate, in which case you probably would need to implement VLANs and have separate logical networks, in an SMB world, either .2-.50 or .2-.99 is what I stick to for servers, networking equipment, printers, etc, and then I allocate out the rest to DHCP. Honestly, for main offices, even if a company is starting out small, I believe a /23 network is a great idea. It gives you room to grow in the future, even if you don't need nearly that many addresses now. Obviously, the bigger you get, the more addresses you'll need, and if a company experiences amazing growth, chances are a network re-design will be necessary. But don't make it happen any sooner than it has to.
-
It's a bugbear of mine. The biggest problem I see it is with ERP systems. Particularly meaningful part numbers. It's much better to get the ERP system to create a random part number and add meaning via the part description, part product group etc etc. You end up with crazy part numbers like 3443-WER-X32-AA-345. Sometimes these are historic and no-one can even remember what they mean. Why not just have a part number like 43456 and get the ERP system to automatically generate it?
Our accounts department insist on putting the first letter of the customer in the customer account number. So Dilbert & Co become D1234, Bob's Hardware becomes B1234. Then Dilbert & Co change their name to Smith & Co and all hell breaks loose.
There were good reasons for doing this in the past, before fast relational databases that can easily sort by customer or part name, but there is simply no reason for doing it now and it drives me nuts. I've been fighting this battle with users for 20 years!
-
Same reason that large companies create employee IDs that are unique and don't mean anything. Just no way to have the users' names be the ID no matter how to mash it up. There just has to be an ID field that is unique and separate from other data.
