It’s a passion project that someone or a team spend a lot of time and energy on, likely thinking that the advantages of implementation will be so obvious that it’ll just be out into production based on its self-evident merits or improvement on existing practices.
Then it hits the concrete wall of reality, where there’s actually lots of friction and barriers in the process of trying to get the project into production and implemented. Management just doesn’t want to go ahead with it for whatever reason, and people don’t seem to be as enthusiastic about it and clamoring for it as the dev/team thought they would be, despite it solving a number of common issues they have with a product/service.
So the dev/team can either go home and forget about it, starting a new project, or write a manifesto remembering and defending the project they’ve spent many hours on.
It almost reads like a PhD thesis defence. At least that PhD then gets recorded, filled and archived, and despite it potentially having no immediate real-world impact, possibly someone down the line might access the extensive work and research already done here, and use it to further their own project, and fingers crossed that project has more success in making a real-world change than this one.
TL;DR: I imagine his management don’t want to go ahead with implementation for whatever reason, but because the research and any coding was done during his time at Google, he can’t just go and create his own app or implementation, or approach another more willing company for implementation. But by providing the research and element summaries, and points for how a better system might work, he not only memorialized his hours of work on a “dead end” project, but allows others in a less captive situation the advantage of taking his summary and using it to actually try to get change happening elsewhere.
Not really that weird.
It’s a common occurrence.
It’s a passion project that someone or a team spend a lot of time and energy on, likely thinking that the advantages of implementation will be so obvious that it’ll just be out into production based on its self-evident merits or improvement on existing practices.
Then it hits the concrete wall of reality, where there’s actually lots of friction and barriers in the process of trying to get the project into production and implemented. Management just doesn’t want to go ahead with it for whatever reason, and people don’t seem to be as enthusiastic about it and clamoring for it as the dev/team thought they would be, despite it solving a number of common issues they have with a product/service.
So the dev/team can either go home and forget about it, starting a new project, or write a manifesto remembering and defending the project they’ve spent many hours on.
It almost reads like a PhD thesis defence. At least that PhD then gets recorded, filled and archived, and despite it potentially having no immediate real-world impact, possibly someone down the line might access the extensive work and research already done here, and use it to further their own project, and fingers crossed that project has more success in making a real-world change than this one.
TL;DR: I imagine his management don’t want to go ahead with implementation for whatever reason, but because the research and any coding was done during his time at Google, he can’t just go and create his own app or implementation, or approach another more willing company for implementation. But by providing the research and element summaries, and points for how a better system might work, he not only memorialized his hours of work on a “dead end” project, but allows others in a less captive situation the advantage of taking his summary and using it to actually try to get change happening elsewhere.