Rediscovering Flux: Lessons for generative design software

One of the recent occurrences that have puzzled me is the number of visitors to parametricmonkey.com looking at Flux tutorials. I’ve even had requests to buy the software. So why is this puzzling? Well firstly, Flux closed down over two years ago. And secondly, I’ve been debating what to do with out-of-date tutorials; delete or keep for prosperity? This dilemma got me thinking a little deeper than my superficial WordPress issues. Despite Flux no longer being in existence, it was more relevant than ever. But to understand why let’s start at the beginning.

The more things change, the more they stay the same.

– Jean-Baptiste Alphonse Karr

Flux Metro

Flux was started in late-2010 by Jen Carlile and Nicholas Chim while at Google[x], Google’s research lab. Flux’s first product was called ‘Flux Metro’ and was launched in October 2014. As their blog describes:

Flux Metro aggregates geographic data from public and private sources to build a three-dimensional visualization, starting with downtown Austin. Alongside a rendering of the existing landscape, Metro shows what can be built on a lot or parcel under the zoning code. It considers more than 10,000 code sections for land use guidelines, height limits, floor area limits, setbacks, and view access rights as well as the locations of protected trees and daylight shadows to project what can be built and how it fits into the existing environment.¹

The app was premised on two key observations of urban real estate development: “that the real estate entitlement process is laborious and expensive, and that site context is the primary driver in building design. We noticed that real estate developers, land-use specialists, and architects were spending considerable time gathering and consolidating data from a multitude of sources to understand development potential and constraints. Furthermore, this process is repeated for every candidate site by every interested developer.” ²

Scalability

However, what seemed like a great idea soon became a complicated technical problem to solve at scale. Flux quickly realised that planning and building regulations were not machine-readable and needed to be manually coded, which was not scalable. Moreover, the regulations were often contradictory, which caused difficulty in developing algorithms that could negotiate these contradictions. For those in the AEC industry, these two limitations didn’t come as a surprise and further reinforced their self-worth in the design process. But the final straw that ended Flux Metro was the poor return of investment. Flux invested US$1 million in developing Flux Metro only to receive several hundred dollars in revenue. They quickly pivoted and focused on solving different problems.

Flux apps

In 2015, Flux began focusing on free, cloud-based collaboration tools to exchange data and streamline workflows. Their apps, which are still available via their GitHub page, focused on solving smaller discrete tasks such as extracting site data, creating public dashboards, and calculating the shortest path. But history hasn’t been kind to interoperability plug-ins. Over the past six years via parametricmonkey, I’ve documented workflows for Chameleon, Hummingbird, Grevit, Rhynamo, and Flux. Many have either seen very little development or others, such as Flux, stopped altogether. Of course, there are the outliers, and companies such as Konstru, Speckle, GeometryGym and Rhino.Inside, all seem to be still going strong.

At the time, Flux had approximately 27 employees and has just secured US$29M in funding. They were the talk of the town and many, including myself, bought into their vision of integrated workflows. But venture capital is not free, and in November 2016 Flux was monetised. Big companies borked at the $60/month subscription fee, which says something about the AEC industry. Either Flux didn’t offer or demonstrate enough value, or AEC professionals had no budget to spend beyond Autodesk Revit. Flux subsequently shut down on 31 March 2018. After a significant restructuring and another pivot, HelixRE was launched six months later, this time focusing on data capture and digital twins.

Same same but different

If all of this sounds familiar, it probably is. Looking at the many software companies entering the cloud-based, generative design arena, I can’t help but wonder how many may be headed down the same path. We know that many of the tasks we do today will be automated in the future – and that generative design may play a part in this automation. But on the other hand, as artificial intelligence author Daniel Susskind argues:

Even at the century’s end, tasks are likely to remain that are either hard to automate, unprofitable to automate, or possible and profitable to automate but which we still prefer people to do.³

The discussion around technical unemployment we can save for another day. What is of interest here is why did such a great product fail? It had the vision – to improve inefficient workflows in the construction sector, which is one of the largest sectors in the world, worth approximately $10 trillion per year. Flux also had the funding – US$29M, which significantly dwarfs the investments being made today in other generative design tools. It was affordable – less than $720 per year, about a quarter of the cost for a license of Autodesk Revit. So where did it all go wrong? And more importantly, what can we learn so that other software companies don’t suffer the same fate?

Postmortem

There are many theories as to why Flux wasn’t more successful than it was. The most obvious is that the industry wasn’t ready for such a product. When discussing why new technologies cause great firms to fail, Clayton Christensen suggests that product performance can overshoot what mainstream customers demand or can absorb.⁴ This perspective is the most reassuring for generative design enthusiasts, as we are now six years down the track from Flux Metro and one would hope attitudes have changed.

Too early to market

The other way to look at Flux’s demise is that the market was ready for the product, but they were too early to market. In the case of Flux Metro, for example, after digitalising the building and planning code for a single city, Austin, they realised they wouldn’t be able to replicate this process at scale. Why? Because while it was technically possible to digitalise regulations, it just didn’t make financial sense. Had Flux Metro launched only a few years later, they would have been able to capitalise on many of the newly released datasets made available via President Obama’s open-data initiative. 

Platform ecosystem

Another explanation as to why Flux failed is their over-estimation of the industry’s willingness to engage in platform-based software. By pivoting and focusing on app development, Flux attempted to create a platform. This idea in and of itself is solid. Five of the ten most valuable companies in the world today – Apple, Alphabet, Amazon, Facebook and Microsoft – derive much of their worth from their multisided platforms, which facilitate interactions or transaction between parties.⁵ But Flux’s platform never really took off. Why? One possible explanation is that an established platform already existed.

Flux apps, in general, targeted computational designers. But computational designers were already using and familiar with food4Rhino. Food4rhino, which is the app platform for Rhino and Grasshopper, is incredibly successful. This success can be attributed to the co-ownership that McNeel & Associates fostered with its users over many, many years. By giving users ownership, they feel a sense of personal relevance. They become invested in it and find it difficult to let it go. This process of seeking consistency between an action and the associated thoughts and feelings, is what psychologists call cognitive dissonance.⁶ This trait might explain why third-parties developed so few apps for the Flux platform and why it never really took off..

Conclusion

Flux is a fascinating story, and there is so much that can be learnt from their success and failures. On a personal level, I am interested to see if or how other software companies focused on generative design navigate the same trodden path of scalability, cost and uptake. What piece of the puzzle will they change, so that they succeed where Flux failed?

One thing that is certain is that something must change. As Albert Einstein is widely credited with saying, ‘the definition of insanity is doing the same thing over and over again, but expecting different results.’ The optimistic can take solace in the possibility that the change may have already occurred, as markets shift and perceptions change. Only time will tell if history will repeat and these software companies suffer a similar fate, or if Flux was a trailblazer who cleared the path for real change to occur.

References

¹ Flux. (Oct 15, 2014). Designing Better Cities with Data Analytics: Flux Metro Austin Preview starts at the beginning.

² Watkins, K. (Nov 21, 2014).  A+U Interviews Co-Founders of Google[x] Startup, Flux.

³ Susskind, D. (2020). A world without work: Technology, automation, and how we should respond. Penguin Books, London, p.4.

⁴ Christensen, C. (2016). The innovator’s dilemma: When new technologies cause great firms to fail. Harvard Business Review Press, Boston.

⁵ Hagiu, A. & Altman, J. (2019). Finding the platform in your product. In HBR 10 must reads: On business model innovation. Harvard Business Review Press, Boston, pp.101-111.

⁶ Ferrier, A. (2014). The advertising effect: How to change behaviour. Oxford University Press, Melbourne, pp.116-117.