[subwayclub]

I don't think there is a "technical profit" to be had, though.

The output of the effort put into technology is a new process or workflow, rather than raw "tech stuff". It's a multiplier to a different input, some other task or application, and so the creators of the technology are frequently disconnected from feedback about its actual use.

For tech to be useful it has to succeed at creating enough leverage that you would use it over what was there previously, and plenty of technical projects get stuck on that point: they show an immense engineering effort but are solving the wrong problem because they don't optimize the desired workflow, or they expect everything to change around the product's workflow.

In that light, in a universe where most of these designs are bad and misguided and deserve to be put out to pasture, the cost-center mentality makes total sense because it asks the design to prove itself as early as possible. And the outcome of that in turn is the familiar rushed, unmaintainable prototype-in-production scenario.

New technology efforts always have this element of being a judo match: if you can find just the right time and place to strike and take the problem off-balance you can get an instant win, but the same strategy at a different moment doesn't work at all, no matter how hard you flex your coding muscles, and would leave you better off not attempting any new tech.

The balance-sheet model doesn't explain when and where to strike, though. It just says whether or not you're trying to do so this quarter, and any benefit will most likely show up on a different business unit's balance sheet.

[snoman]

> I don't think there is a "technical profit" to be had, though.

Ostensibly, every net-new feature increases the pool of people for whom the software, as a whole, solves a problem. The performance and usability of that feature further adds to that.* I'd argue that is technical profit, and is realized into real profit when it converts to purchases/subscriptions/whatnot.

[1] For the sake of argument I'm assuming a scenario where the feature and its performance/usability is positively received.

[prewett]

I never thought about the idea of "technical profit," but I think it is insightful. There is, indeed technical profit. When you have a quality design that fits the system's space really well, then you can maintain and add features really quickly and safely. This is technical profit.

When Paul Graham talks about how writing Lisp enabled his startup implement features quicker than the competition, that's technical profit. Google's internal systems that allow them to maintain thousands of machines; create large, distributed filesystems; and who know what else are technical profit.

There was an article recently about Boeing retiring the 747, and it commented how pilots would take a picture of the plane after flying it. (Passengers, too) In aerodynamics form is function, and I suspect that the outward beauty reflected excellence of design. The design served them so well they just now retired it after 40 years, despite all the advances since it was originally designed. If I'm right, this is technical profit.

Perhaps the idea of technical profit would be an easier sell to management, especially as management types see debt as useful, but programmers see it as a liability.

[aeorgnoieang]

> The output of the effort put into technology is a new process or workflow, rather than raw "tech stuff". It's a multiplier to a different input, some other task or application, and so the creators of the technology are frequently disconnected from feedback about its actual use.

Technical profit is a feature or capability really that's possible because of some technical thing (e.g. code). But the 'revenue' of the capability has to exceed the cost of designing, developing – and maintaining – the tech for a profit to be realized.