Disorganization

“A place for everything and everything in its place”

The best way to understand ‘organization’ is kitchens. Almost everyone is familiar with them. A kitchen is a common room where there are a lot of different activities. People cook, sometimes eat food, and prepare all sorts of other things. It holds all the equipment to prepare food and to consume it. It’s a rather multi-purposed room.

Most kitchens are well-organized. There is a cabinet for storing glasses. There are usually the same major appliances, stove, fridge, sometimes a dishwasher. There are often a lot of minor appliances, like microwaves, toaster ovens, and blenders. There are working areas and sinks and places for the wet dishes to dry. There are a lot of cabinets everywhere, and in most kitchens, the items place in each cabinet, on each shelf are predefined, consistent, and part of the organization.

If you’ve seen a lot of kitchens, you know that the placement of things can vary somewhat. Some kitchens are really neat and everything is where you expected it. Some are messier, but there still is some overall rationale to where stuff is placed.

Being a working room, when people are cooking they want to get quick access to the equipment they need, so pots and pans, utensils, etc. are more frequently found closer to the stove and the preparation areas. Glasses, plates, mugs, etc are usually found nearer to the edge since most often people need them and then leave the kitchen. So, there is a sort of ‘logic’ to the layout, and when it is arranged better, the use of the kitchen is more efficient, which really matters since most people use their kitchens multiple times per day. That’s a lot of usages.

We can extrapolate that out to software development projects or even companies as a whole. They are well organized when an employee needs something and there is an obvious place to find it, and when they go there it is available.

If in the middle of stir-frying, you suddenly realize that you need a bigger spatula, then spending 5 mins searching everywhere until you find it, it’s somewhat likely that the food has burned during this distraction. If you need something, you just want to reach over to a nearby drawer and grab the next utensil without expending much effort or wasting time. So we know that a consequence of disorganization is that it is a lot slower to do most things, if not all things. When emptying the dish strainer or the dishwasher, it is not an expensive task to put all of the spatulas back into the utensil drawer. They have to go somewhere, and it is actually easier if that somewhere is well-defined. So keeping a kitchen organized is not a particularly onerous task. It comes rather naturally.

One really interesting thing about kitchens is ‘terminology’. For the most part, there are a lot of words in our language to describe the stuff in a kitchen, and most of the stuff in a kitchen has a specific name. So, it was not hard to write the above paragraphs, giving things a descriptive name, and it also is more than likely that most readers are familiar with all of the terms used, and what they mean. That says a lot about the importance of kitchens to our lives, but it also shows how ‘organization’ is tied to terminology. If there are no words to describe something or no words to identify its place, then it’s not easy to communicate with other people where that item should be placed to keep things in order.

All of this helps us understand disorganization. If you are looking for something and it can be ‘anywhere’ then it is disorganized. If you don’t even have a name for what you are looking for or some other attributes, then it is disorganized. If most things are neatly stored in a place, but there are places where stuff is just ‘dumped’ in a big pile, then it is disorganized. If it is disorganized, then trying to do any task will take way longer, since it is harder to find the parts that you need. If it is organized, and that is communicated, then keeping it organized should not be a significant amount of extra work. It is a lot of work going from disorganized to organized, but that will help save a lot of time and aggravation later.

Kitchens are fairly easy to organize since they’ve had pretty much thousands of years to built up their knowledge base and pretty much most people in our world are aware of how they are usually laid out. It is pervasive in our cultures. Software on the other hand, is an incredibly young sport, so a lot of things don’t have consistent names or stable definitions and there is rampant disagreement in our industry on how to lay them out and where the various parts belong. Companies, in general, have a much longer history, and there are pretty standard ways of arranging them that work quite well.

So it is fairly easy to ‘see’ disorganization. For a domain like a kitchen or a company, it is not that hard to go out and get enough knowledge about the necessary contents that we can start to assign places for everything, then do the bigger work of getting everything into its assigned place. Software is essentially the same, but it is somewhat less precise, one might have to do some digging and research in order to find the correct terminology or to understand the different layout options. What’s important about software though, is that while it is some work to change from one organizational scheme to another, it is way more effort to go from disorganized to any scheme. That means that picking a scheme, even if it is a wrong scheme, is far better in the long run, then just trying to ignore the problem and hope it magically goes away on its own. Further, it also says that if people have not explicitly decided on an ‘organization’, then pretty much by definition it is disorganized and gradually getting slower every day to do stuff. Disorganization is like a very slow quicksand, you’re always sinking a little tiny bit, but it is not too obvious that its a significant problem until it is too late.

Basic Expectations

When interacting with any software, there is a fundamental set of overall ‘properties’ that the users expect. If these are not met by the system or product, they should be considered as software bugs, even if it isn’t explicit misbehavior in the sequence of instructions. It may be very hard for the programmers to fix some of these issues, depending on the state and organization of their code.

Availability

• The system is available when the system is needed.
• If part of the system is currently unavailable then the user will be notified before they start doing any work in that part of the system.
• If part of the system was unavailable, there is somewhere the user can go to see that that had occurred.

Correctness

• If the system provides a calculation or computation, then the results of that work are either correct or it produces a specific error.
• If the system provides a calculation or computation, then if the user redoes the work with the same context, it will produce the same results (repeatability).
• If data is displayed on the screen with a label or attributes, then that labeling is correct (trustworthy).

Completeness

• If someone can add some data, they should be able to modify and delete that data.
• If someone can perform an action in a given context, then they can perform the same action in any similar context.
• If a system has data, at least one interface exists to display that data.

Context

• If there are a series of context-based operations that are reversible, then when reversing, all of the in-between context states are reachable.
• For example, if you scroll through a list of links, then jump to one, hitting back will return you to the last position of the scroll, not the top of the list (very common bug).

Composable

• If you can do an operation in bulk by building up the context, it should work correctly to apply that bulk operation to everything (stability and performance).
• If the composition gets too large, then the system will warn about a limitation, but not undo the current composition.

Visibility

• If a user enters data, the default scope (visibility) is to just to that user.
• If the scope is widened, either the user-initiated this or is aware of this (transparency).
• For any data, there is a way to see it’s current scope (transparency).

Searchability

• If the system allows for searching, there is some composable way to narrow down the search to any specific item.
• If the system allows for searching by a category of items, then the results only contain that category.
• If an item exists in the data, then it can be found in the search.

Performance

• Any computations done will be bounded (finish).
• Any resources used will be bounded (estimatable).
• The worst-case time for the largest amount of work is still reasonable (usable).
• If the computation will take longer than expected, the user will be notified (progress bar).
• If the work takes a sufficient enough time, it can be stopped (cancelable).