Are There Poison Pills in Your Tech Stack?
As the industry embraces the position of Construction Technologists, they are becoming the people most responsible for building the technology infrastructure. This infrastructure, often called a technology stack, is the foundation that enables many of our most valuable processes. Selecting the right tech can be critical to our companies’ performance and ability to grow. This growth means that when we evaluate tech we need to determine not only what a technology’s capabilities are today, but what they are likely to be tomorrow. Will this product be able to grow with my company? What is the likelihood that this product will become obsolete quickly? Will this technology limit my hardware and software selection down the road? Is this product able to perform and support the unconventional things I have planned for it?
There are a huge number of ways to make these determinations, but one of the things that I have found most helpful is to make a list of what I call the ‘poison pills.’ Poison pills are a limiting factor or factors that are extremely unlikely to be overcome. This is often something that is foundational to the product. A good example is the Oculus Go. It can support 50,000–100,000 triangles. The Oculus Rift can support 1–2 million triangles. So, anything I purchased on the Oculus Go will be limited by that poison pill. If I plan to do anything that involves a higher level of complexity, the hardware will poison the process.
Another example might be augmented reality programs based around iPhones and iPads. The cameras available on these pieces of hardware have limited ability to map surroundings, while the Hololens has plenty of input cameras and is optimized for AR. Both the Oculus Go and AR on the iPad represent hardware pills.
Software can have a significant number of poison pills too, and they can be less obvious. For example, any software that cannot do parallel processing would have a hard limit on processing speed and could require special hardware configurations. Software built on a single operating system or only available on iPad or Android would limit and even dictate the future selection of hardware and software your company could use. Even programing language is occasionally a poison pill. Software written on proprietary or specialized programing languages may have fewer available programmers fluent in that language, and therefore be far less likely to grow as fast as those that are built around a more common platform or language. Similar pills can exist with software not offering open APIs, or that is not able to communicate with other programs. Also, some software has complex licensing structures which become a pill, particularly where the software needs to be shared across remote locations. To this day, I have software that has hardware keys associated with it or that needs to be live connected to the Internet to validate. With the mobile nature of construction, these represent pills that are at best hard for me to swallow if not actually poison pills.
While some poison pills can stand alone, most are relative to the other technologies used to make up a specific stack and are very dependent on the goals of the technology. For instance, if your process goal with the Oculus Go would not exceed the triangle limit or not be impacted by it, then that limit does not represent a poison pill within your stack. On the other hand, if a good piece of software is built on a platform you are not using, it may be a poison pill to you even if it’s not a problem with the software itself.
This is not to say that poison pills are the final word on a piece of tech. Often some form of workaround can be established. For example, InsiteVR provides model coordination using the Oculus GO and is overcoming the triangle limitation by separating complex objects into several small objects that can be viewed one at a time but are woven together to present a single model. Mobieive is overcoming similar limitations with AR and iPads by building better reference points. Artful use and hacking can also be an antidote to a great number of poison pills. However, it is important to understand that the pill still exists and has an impact even if it does not directly affect your current stack or goals.
Poison pills can be a great way to determine whether you should even look seriously at a product. Products that have several pills associated with them are not likely to achieve much within your organization and are very likely to end up temporary solutions. Program developers target those types of limitations as they plan new product launches. So, many times products containing too many pills are short-lived. This can mean that product may be obsolete even before you finish rolling it out.
I am often overwhelmed when I look across technology’s ever-changing landscape and need to lean on a great many tools to help me navigate. Among all of them, I find myself coming back to the idea of identifying poison pills as a foundational step. It helps me to make decisions about what to experiment with vs. roll out, and even what to avoid altogether. As each of us builds our tech stack, I think it’s important that we also build systematic understandings to help us feed that stack. Being intentional in identifying as many of the poison pills as we can and doing it in a way that can be communicated both with developers and those supporting our efforts inside our companies, needs to be a part of that process. Doing this before we make our decision to purchase a product or pursue a technology can bolster the success and support for tech within our teams and help us secure good technologies for both today and tomorrow.
