Common sense tells us that creating one unique item is easier than creating 5 unique items. Mapping how unique items interact with each other is also more complicated than how an individual item interacts with itself because it is itself. Interactions of duplicate items can get fairly complex, but we understand that humans are individuals and our interactions are more complex than that of billiard balls. This final part will explore the “quick and dirty” way to estimate project complexity, and how to put everything together.
Catch up and read Part 1 and Part 2!
Optimism Bias
Optimism bias tells inexperienced users that creating a system of 3 unique components is (or is close to) 3 times as complex as creating 1 component. It is extremely important that we establish now, that this preconception is wrong.
This very human bias exists for a reason. It takes a lot of work to understand systems and we are also inclined to use heuristics to understand the world. To properly estimate these interactions, we should settle in and remember that the complexity is governed by logarithmic function, rather than simple addition.
Let’s take a step back and observe power-law in the relatively simple form of log base number of employees:
- When two employees complete two unique tasks that take 3 hours each to complete, the total so far is 6 hours.
- If those two work units must be integrated together into a single end-product you must factor in an additional 3 hours for integration and testing.
- This is simple power-law has 3 hours of work raised to the second power is 9 (3 hours raised by 2 employees as power)
- When three employees complete three unique tasks that take 3 hours each to complete, the total for each task is 9 hours
- To integrate the interaction of those 3 unique products requires exponentially more integration and testing effort; we should estimate this to take 18 hours
- This simple power-law states that 3 hours of work raised to the third power is 27 (3 hours raised by 3 employees as power)
- 4 unique and uncoordinated tasks from 4 separate estimated at 3 hours each are likely to take 81 hours… and now you begin to understand project complexity
Power law dominates the universe as we can observe it (along with fractals). Keep in mind, though, that this model is illustrative rather than representative of practice.
Here is a diagram of 4 individuals communicating which is illustrative of real-world power law in action. 4 people in conversation have 12 communication pathways:
This graphical representation is much closer to a Natural Log function and is more common in practice than the “hours worked” example given above
This principle is one of the reasons why Agile Methodologies work well with small teams of people. Once you add more than 6 or 7 people to a room, communication either breaks down or people break out into smaller groups. Communication gets too complex for the human mind to process for any length of time once you hit a critical mass of integration. For a brush-up on Agile, visit this blog-post for a quick review Click Here.
Now that we have established the complexity of the world, I think that we all understand that parts 1 and 2 of this series were the easy part. Putting things together is where things get messy. We can finally move into the brief overview of how the components work together as functional software.
Challenge #3 - Interaction of Classes (Putting it All Together)
Systems concepts need a diagram aid. Here is an image tying together our classes from parts 1 and 2, for final discussion:
Here are the components of the chart:
- Yellow Arrow - Initial direction as determined by the start point (green circle), and destination (black ring)
- Red Star - Waypoint which includes a coordinate
- Dark Blue Arrow - Path that connects two waypoints, and ultimately the starting point to the destination
- Light Blue Boxes - Barrier objects which could be buildings, fences, or alligator pits
Interactions
All of the above classes must interact to determine a usable path. Starting in order of introduction, the Yellow line determines a direction which can serve to help the pathing class to select the next way-point (it functions mostly as a compass). The way-point classes interact with each-other to calculate distances between points so that the navigation app can tell you how far you need to go before your next turn. Barrier classes interact with the Pathing class to constrain usable way-points along the path so that each subpath and turn are navigable.
The start and end points are really just waypoints that the user provides the app. Preferably this information should be provided unconsciously or automatically for better UX. Most normal waypoint rules apply to these two points.
For our sanity’s sake, we will only speak briefly about optimization in this blog series... which leads us to:
Why the Yellow Line?
The yellow line in this drawing is a graphical oddball in the diagram. Theoretically, you could create a GPS navigation app only with classes from Part 2 of this series but a computer may give unusual pathing options. A human with a map and GPS can easily give near-ideal routes. Computers need additional logic to help make these decisions.
The simple solution to the problem is to add a logical constraint that the computer prioritizes nearby waypoints AND shortest overall path length. This idea seems great at first glance but can actually run counter to human preference. Ask yourself this question: If the dotted pathing line was equidistant to the solid line, would you prefer the path with 5 turns or the path with 13 turns?
My guess is that you would prefer 5 turns even if the overall path is a little longer. This is true for a few reasons:
- Fewer turns makes it easier for people to understand and learn to navigate without a computer
- Winding roads usually slow down the flow of traffic; even if the turns shorten the overall distance, they often increase travel time
- The dotted line forces GPS users to move away from the destination more frequently. Persistence (AKA stubbornness) is a fairly common human quality and we prefer a reality where barriers stay out of our way
Humans can find destinations with minimal instructions because we come with preinstalled software. We are already set up to navigate a spatial world. It is helpful for GPS services to have additional logic to make decisions that seem more human. People enjoy the company of other people that share similar behaviors; we also like computers that make human-seeming decisions.
Assuming that we want people to use our GPS Navigation software, we should design a program that people actually enjoy using!
Closing Thoughts
Assuming that you made it this far, you should understand some of the basic concepts behind GPS, or at least enough to get yourself into trouble. More importantly, you should have a better grasp on how complex software development can be.
We can see by this third and final post that developing a simple GPS Navigation app can snowflake into unique specialty domains. Please take away that we only covered this topic in 2 dimensions and ignored many of the software optimizations that Google and Waze implement on a frequent basis. To go any any deeper we would need to review:
- Project Management Fundamentals
- Class Definitions (preferably in a common programming language)
- User Experience (UX) optimization
In other words, this is a good place to end for now!
Thank you for coming on this thought experiment journey. Hopefully, you found it coherent and engaging. Now liberated from the experiment, I will research the topic and check my work… if I made an egregious error, I plan to add correction links in the near future.