The whole system where all of these projects generally go towards some form of advertising where we convince people to buy things they don't really need is a far worse form of heat loss than this. Buying the latest shiny smartphone every year isn't just the heat loss of thousands of engineers making it slightly thinner, it's the actual loss of all the resources that went into last year's batch of smartphones that end up in a landfill somewhere.<p>And yet, none of this is really a loss as people need something that feels important to do with their time, and building that new smartphone that is the world's thinnest definitely feels like you're making accomplishments. And people are pretty happy when they open the box and see their new smartphone.<p>Moving corporate resources around is just one more step in a world we don't truly need, but which we create for ourselves anyway. In this case, it's part of the game of proving that our company has the biggest numbers so that our share holders get a smile on their faces when they open their retirement portfolios.
This happens at the company I recently retired from. At intervals of between five and ten years someone decides that R&D should either be centralised or that the development engineers should be closer to the factories. The people are the same people, the work they do is the same, but the location is different. The justification for centralisation is usually that there will be better communication between the development engineers and the justification for putting them in the factories is that they will be able to communicate better with the management and workers of the factories. The reorganization is always intended to have a valuable side effect. I could never understand why they don't go directly for the side effect.
I work in a corporate environment in business intelligence and this rings true. This year we are tasked with retiring an arbitrary number of reports (mostly old Crystal reports) since they take too much of our time to maintain them. This will mean telling business partners that we are shutting down their reports, which in turn will cause them to create more Excel spreadsheets and Access databases. And in the process there will be the "<i>heat loss</i>" described in the article.
I completely agree with this. Something I would add here is the great danger of wanting to recreate products from scratch. You have the "heat loss" effect as stated here but you also have a massive amount of expectation from the users of the existing product. It can quickly become "the product which will fix all our issues" over time and the goalposts are being moved so much that the release day is just pushed forward forever.
This is a lovely account and, though it may not seem when you first read it -- in my experience, it is somewhat optimistic. For instance:<p>> The process of changing the system to have a new balancing point took work. It involved investments of engineer time, design work, tech writers and documentation changes, and all kinds of other "meta" stuff.<p>In most places I've worked, this involves investments of two interns' time and a few design meetings which result in a design document, half of which will never make it into the actual implementation. If it's a customer-facing thing, it will result in documentation changes -- otherwise, it won't. There will be no time to adjust the documentation and internal knowledge about how we do it now is going to float around as oral wisdom. <i>Why</i> we do it like that is going to be folklore two years down the road.
I think many businesses are implementing productivity improvement work which consists of a) an investment in engineering time and b) moving things around. I think to most people moving things around is the only really visible part. I think this leads to others simply copying the 'moving around' part in order to attempt to gain productivity improvements. The most common example of this nowadays is people moving their infrastructure into a cloud provider. If this is not done right and the investment made in the engineering time to deliver a more productive result, it's going to be worse than not moving around.
Another analogy that comes to mind would be 'going to gym'. Short-term, working out is exactly a heat loss (doing hard work with no useful results). But long-term, it makes you healthier and able to do more things.<p>Back to corporate IT, it's not that hard to stabilize a decent big ol' legacy revenue generating system, while avoiding making changes. But if the company has to compete against smaller and leaner startups, avoiding changes might become a major risk, as the cost of all changes tends to go up.<p>So, it would be reasonable to keep the system is a constant state of flux, so that it has no choice but to become fitter and learn to change quickly without breaking: stuff like reproducible builds, reproducible deployment, CI/CD don't matter a lot for monthly stable releases, but one would have a hard time doing nightly stable releases without them.
> But, it kept them busy, and let them show off, and they can take that all the way to the bank by way of a performance review system that optimizes for Shiny New Things.<p>Yup. At least some of the generated heat can be captured in the form of bullet points on resumes, which can be used as leverage for promotions or new jobs.<p>Perhaps from a whole-system or whole-company perspective the result may be a net loss, but the endeavour may be quite postive for many of the people involved who are making or executing the decisions.
Isn't this just switching costs?<p>The author assumes that a change in a process never amortize. However, some changes cost time and money yes, but they amortize after a few months ans are worth it.<p>Yes, some changes might lead to worse processes than others, but most changes aren't.<p>It all comes down to a good CEO, if you make too many changes that make it worse, the business becomes bankrupt after a few years. If your changes amortize, even only slightly, your business stays afloat or improves.
What if the 'heat loss' is just the required 'activation energy' to get from State A to State B, where B is far superior for the customer.
Common tropes in software for this:<p>* Switching from polling to push or vice versa<p>* Merging two overlapping systems into one<p>* Splitting one system into two<p>* Rewriting from language X to Y<p>* Moving from centralized to decentralized or vice versa<p>* Moving logic from one layer to another (eg smart client vs thin client)
In my current project we get moved around teams on a monthly (!) basis. The heat loss generated is so enormous you start to feel like you are in a powerplant.
as a chemist, love the analogy, resonates a ton with me. a little bit nit-picky, but:<p>"That is in addition to the actual cost of pumping the water from one tank to the other."<p>should be something like "that is in addition to the actual cost of lifting net 25 units of water higher".<p>The cost of moving from one tank to the other is, also heat loss, but the lifting part is recoverable.
Has anyone blogged about a software refactoring project being "heat loss"?<p>Same thing really -- it comes out better, the same or worse but the underlying principles are identical. You could avoid the "heat loss" by just hacking on the old crufty code or redesign it into a fancy-smancy state of the art system.<p>I would also bring up The Economic Calculation Problem and how it applies to large monolithic corporations equally as well but that's a discussion for another day.