What Is Value?
dwyer.co.za
dwyer.co.za
- Creating schematics for manufacturing[2], and
- Capturing reusable knowledge.
What's interesting is that these two may be thought of as in opposition. Time spend creating reusable knowledge does not directly benefit the customer -- and time spent obsessing over the customer may easily come at the expense of reusable knowledge.
Any methodology used by developers must take this tension into account. Ward suggests a non-authority project leader (like Toyota's chief engineers) whose job it is to deliver the best products in the world. To help them, functional departments do the actual job. But the functional departments are responsible for creating reusable knowledge, not delivering products.
So there will be a constant creative tension between functional department (who want to further their reusable knowledge) and the project leader (who wants the blueprints now, but cannot order anyone to draw them) and from this creative tension and conflicts great products are woven.
[1]: Actually, he mentions a third in passing: building tools for manufacturing. (I guess the software equivalent is tools for ops, or something.)
[2]: In the software world, read this as creating code that the build system can turn into a useful product.
This is not civil engineering, most of the stuff me or you used 10 years ago has been rewritten and rebuilt, sometimes from scratch, sometimes several times.
Of course, exceptions exist, but remember that exceptions are exceptional - rare.
By that I mean you entirely discount the value of long term value creation, dismissing it as "very hard to compute".
Your analysis could yield significantly more value by pointing to ways that long term value propositions can be evaluated, sold, and balanced for risk.
It's an easier sell than you might assume. Point to examples where it paid off - e.g.
Roslyn Franklin's X-ray Crystallography --> Watson and Crick's DNA --> Genomic sequencing --> mRNA vaccines
Microsoft's Windows development for 3 versions before conditions were right for the GUI to prevail on desktop computers.
Brin and Page captured long term value from Page Rank by waiting to monetise their search business until it had established clear technical leadership by virtue of its reputation for satisfying users.
In a business economics sense, to create value is to create something that “other people” care about. Engineers create value by meeting customer requirements and doing so at the lowest cost and of sufficient quality. This value is shared between the customer and the business. The customer is satisfied, and the business makes a profit.
Things that are valuable to the engineer such as personal gain, entertainment, skill-building, job satisfaction, resume building, learning new programming languages, work-life balance, etc. are not necessarily part of the economic value equation. These are rather part of the business employment relationship and the way that the job is done. The engineer may be able to share in the economic value in the form of a higher wage or a bonus; but this will only happen if the customer is satisfied first.
tl;dr creating value is an business economics matter, doing something valuable is an personal and/or employment matter.
This isn't exactly "immeasuable." Balance sheets quite commonly have an entry for "goodwill" and brand/IP valuation is an art in itself. It's clearly difficult to measure, but it can be measured.
On the other hand, while, depending on how liquid the market is for ownership and debt shares in your company, it may be fairly straightforward to place a value on the entire company, with estimates of how to divvy that up getting less clear between individual line items on a balance sheet, attributing that value to specific individuals, roles, and actions is nearly impossible for all but direct salespeople.
This is where the notion of creating value for your customers gets a lot more nebulous. It is entirely possible to actually measure the monetary impact your product and even specific features of that product can make for a customer, and extrapolate that history to estimate the impact of similar products and features, but there is an actual measurement and statistical science to doing this, and almost no one involved in technical project management and certainly not engineers actually have any of the toolsets of accounting and economics to do this, so we mostly just wing it and make guesses based purely on intuition, so we can get back to our real jobs and do what we're actually good at, which is not measuring and estimating value.
And, of course, this gets a lot stupider when you get into government work and nonsense like EVMS, because your customer isn't a profit-making entity that has any monetary value in its operations at all, yet all of our tooling and thinking is based on the premise that value can be quantified via a common medium of exchange and ranked.
That is a very generous take. It can be estimated or guessed at via proxies, but something like that is not really measurable. It's like measuring the loss of a key employee leaving.
Some things have more uncertainty than others (compared to what the number would be used for) but we have created techniques to deal with that in practise too (hedging, optionality.)
Maybe you have a personal threshold for a level of uncertainty below which things count as measurable and above which they don't, but you're imbuing the word "measure" with subjective characteristics at that part -- not to be confused with its objective meaning.
Estimation is on the other hand uses measurements as input and has no clear cut path forward. (you must assume some model)
"Chemistry is just applied physics" ("measurement is just estimating via proxy") might be technically correct, but distinction is still very real and usefull.
I'd argue probability is subjective and estimation is mostly unambiguous, therefore the estimation uncertainty is mostly known, thus estimation is a form of measurement.
I can absolutely see how, if you think probability is frequentist/objective or you think there's generally non-uncertain ambiguity in the estimation task, you would disagree.
The book value of a company isn’t supposed to match its intrinsic value. It only includes assets that have a clear price.
This is perhaps HN-flavored although I consider it obsolete. https://asemic-horizon.com/2019/03/13/the-wave/
This is maybe a better example of my more contemporary approach. https://asemic-horizon.com/2021/02/10/we-have-never-been-ase...
— edit: those are more about ethics, this may be closer to OP: https://asemic-horizon.com/2021/07/31/zero-chroma-infinity/
A bit weird and philosophical, rather than useful.
Is that actually true, in other people's experience? I would have thought that most people involved in tech hiring would prefer the first version — at least it tells me what technologies you're familiar with. The second one just tells me what somebody else did with your code. Sure, they sold a lot of widgets, but I'd guess that has a lot more to with the quality of the widget than with the quality of your software
* It suggests the person understands the bigger picture behind what they're doing (rather than just "punching tickets")
* If your code sits in a 'financial critical path', this usually implies stricter requirements in your engineering in some respects -- you'll probably have had to think harder about reliability, cover more edge cases & co-ordinate with others more around requirements
If you are a perfect fit tech skills-wise and can’t think/talk about the business side, you can make progress on our ticket backlog (and so we can still hire you), but if you’re moderately skilled at software in general but can connect that to the business problems, we can definitely use in a variety of spots.
One may say "who says Y is preferred over X?". And it's a legit question. The question is, have you created value or not?
I have no reasoning. It’s just clear to me that it is true (though I don’t expect or need anyone to agree)
People will tolerate surprising levels of discomfort, even financial loss, to be physically close with other people.
I'd say this basic need goes even further than humans. Certainly at least mammals, with their complex endocrinological and social systems; but possibly any organism that procreates via sex.
but value and worth are not the same thing ?
I imagine that if you could do the same for a "boyfriend hand-holder" product that partially fulfils the feeling of having your hand held, it would also sell well.
If this happened, no-one would say that the product had no value. Yet the product is only capturing part of the value of actually having a boyfriend hold your hand.
Therefore I would say that you definitely have created value by holding your girlfriend's hand.
[0] https://www.reviewed.com/lifestyle/features/boyfriend-pillow...
I'm told some people pay prostitutes to just hang out with them to feel some sense of intimacy, without even having sex. Ie, people are basically being paid to hold hands.
An established relationship is value, where instead of just sunk costs, you have solved a lot of the problems that most relationships need to solve, and you can focus on just making it beneficial to all involved. At a large enterprise scale, an established process is value because it is stable and can become the foundation for other processes.
When I identify something as value, I mean that it either creates or resolves tension in a dynamic or conflict of some kind, which creates opportunity in the form of new potential. When I say "super valuable," I mean it appears to have opportunity with nonlinear upside.
Price is one of the most interesting qualities of things to think about, as in a way, it's the resolution of separately held beliefs suspended in an super position. There is a "true" price that is the unity of these ideas, and then there is the settling price that it clears at, where all those other factors collapse into it. Negotiation is the art of discovering how close you can get the clearing price to the abstract true price as possible. It's weird, but approaching negotiations as empirical price discovery is an immensely powerful bargaining position.
Software engineers are engineers.
In a discussion specifically about positioning one’s work as being more economically valuable, IMO that’s a distinction worth making.
In software this distinction breaks down - the "design" _is_ the finished product. It's really a different kind of thing.
Construction offers a better analogy: the architect produces a high-level design, and the builder is responsible for construction, which includes the full detailed design (which is usually not written down anywhere but manifested in the finished product).
Craftsmen are generally high-level experts, because they are involved in craft production. Craft production means producing small numbers of highly customised things. One craftsman can often produce the entire thing from primitives. Craft production is not about precise tolerances and interchangeability; craft production is about sanding down this particular component until the fit is perfect for the specific one-off purpose. Did I mention this is very expensive and not reusable at all?
This is in contrast to e.g. mass production where interchangeability and huge volume and a single model ("any colour as long as it's black") rules. The mass production worker isn't drawing on a long and wide experience; they do a job that was designed to be learnt in a few days, and they do it over and over. No feedback cycles are designed into the system. You can make defective parts for hours or days and nobody will notice -- and it's probably best if you keep quiet about it, too. The important thing is that you produce your daily volume, defective or not. Mass production is all about local optimisation at the cost of system performance. But hey, it's cheaper than craft production! (And the output is correspondingly shoddier.)
Then lean production aims for the huge volumes of mass production, except by optimising the entire system instead of local tasks. Books have been written about this so I won't but the end product often costs less than the mass produced, and can also be of higher quality than the craft produced.
I bring this up because as quaint as craftsmen are, if our goal is to be like craft production we'll drive up costs and be outcompeted by someone who realises that craft production isn't all that hot other than for very specific up-scale purposes, where cost is a feature.
I hate the craftsman trope. In my view baked in is the idea we're somehow more creative or special than other engineers, and worse less bound by principles of math and science. It simultaneously denigrates those other engineering disciplines and primes software engineers with a really bad intuition about the proper way to carry out their work.
I don't mean to pick on you or the original author, it's a widely held idea pushed by some very influential figures, I just think it's in desperate need of reexamination.