3 ms·

I think the problem is that the outcomes of technical work is not equivalent to a product with a more static value. Simply put, software is not the same as a bu

I think the problem is that the outcomes of technical work is not equivalent to a product with a more static value. Simply put, software is not the same as a burger. Software development to me is a financial investment strategy. Some risky investments, some safe bonds, some good debt to invest, some bad credit card debt that will be cleared later. To me, these are the same as a risky overhaul of a critical system adding some automated tests, skipping some type annotations, or launching what was supposed to be a demo/MVP to be first to market. a piece of software that took months to build could be worthless tomorrow if a competitor comes out with a better solution. There's a time value and strategy to it. speeding up development with CD lowers the investment cost & time to market of an individual strategy. Automated tests lowers risk. Feature flag & AB testing diversifies the portfolio. One line of code be the most valuable piece of a product, like Doom's Fast Inverse square root. and millions of lines of code could be worthless. the value of a software engineer's work is extremely contextual. Two automation can be structurally the same, developed by the same person, written in the same language, take the same amount of time and resources; and still be COMPLETELY different in value. until IT/software strategies are treated like an investment strategy, companies & leadership will continue to flounder when managing technical teams.

JackMorgan 3y ago
I agree whole-heartedly! I am sometimes called upon to audit codebases for acquisitions. I've spent enough time in the strategic accounting world to realize that we almost have no concrete units of measurement to talk about software. Lines of code is as meaningful as the count of boards in a house. In a house, we can at least get total square feet, number of legally defined bedrooms and bathrooms, lot size, etc. In software, we've got almost nothing. I've seen tiny codebases that can CRUD hundreds of different records, and I've seen multi-million line codebases that can barely handle saving a dozen different records. Consider all the ways data flows in and out of a system: asynchronous processes, batch processing, auditing, third party integrations, permissioning, reporting, and legacy system integrations. Each of these change the value and technical debt of a system. I suspect we will have an increasing need to perform an accurate audit of a codebase. And provide the value, depreciation, and debt of a system in dollars. I would love to see a standardized metric for accounting for assets and liabilities.
- skydhash 3y ago
  A recent post was talking about software as an expression of an idea. If you take something simple like a text editor, which purpose is to edit text, you can go and express this simple idea however you like. The final result will be different according to the person/people who shaped it. And that is why you have things ranging from nano, vim,... to sublime and vs code. To go from an idea to a product, there are just too many variables in play, and most of them depends on people. > I would love to see a standardized metric for accounting for assets and liabilities. I'd say that is easy. Just compare what the business wants/needs to what is inside the codebase. The diff percentage is a nice basis for the above. But that would require a very detailed study of both the company processes and the codebase itself. I think that's why most of us feel the need to build our own tool. Because the ideas represented by the software we are using are not what we would have come with. And thus, we're building extensions and plugins.

JackMorgan 3y ago

I agree whole-heartedly! I am sometimes called upon to audit codebases for acquisitions. I've spent enough time in the strategic accounting world to realize that we almost have no concrete units of measurement to talk about software. Lines of code is as meaningful as the count of boards in a house. In a house, we can at least get total square feet, number of legally defined bedrooms and bathrooms, lot size, etc. In software, we've got almost nothing. I've seen tiny codebases that can CRUD hundreds of different records, and I've seen multi-million line codebases that can barely handle saving a dozen different records. Consider all the ways data flows in and out of a system: asynchronous processes, batch processing, auditing, third party integrations, permissioning, reporting, and legacy system integrations. Each of these change the value and technical debt of a system. I suspect we will have an increasing need to perform an accurate audit of a codebase. And provide the value, depreciation, and debt of a system in dollars. I would love to see a standardized metric for accounting for assets and liabilities.

skydhash 3y ago
A recent post was talking about software as an expression of an idea. If you take something simple like a text editor, which purpose is to edit text, you can go and express this simple idea however you like. The final result will be different according to the person/people who shaped it. And that is why you have things ranging from nano, vim,... to sublime and vs code. To go from an idea to a product, there are just too many variables in play, and most of them depends on people. > I would love to see a standardized metric for accounting for assets and liabilities. I'd say that is easy. Just compare what the business wants/needs to what is inside the codebase. The diff percentage is a nice basis for the above. But that would require a very detailed study of both the company processes and the codebase itself. I think that's why most of us feel the need to build our own tool. Because the ideas represented by the software we are using are not what we would have come with. And thus, we're building extensions and plugins.