3 ms·

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 th

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.

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.