Sometimes I’ll get a ways into a chapter & realize I need to start over. Rather than just throw a chapter away this time, though, I figured I would share it with all y’all. This way you can see some of my writing process, you’ll be able to see how much the chapter changes between now & publication, & maybe you’ll get a little something out of it.
A Dollar Today
If I give you a dollar today, you can spend it on something you want or you can invest it in a way that gives you more money later. If I promise you a dollar tomorrow, it's worth less than the dollar I give you today.
You can't spend it, so it's worth less.
You can't invest it, so when you get it it will be worth less than the dollar you got today.
There's some chance that I won't actually give it to you. Well, not me. I'm entirely trustworthy. But someone else, yeah, you have to be prepared that they won't give the dollar, making that "dollar tomorrow" worth less.
How much less? Complicated question. For now, the important fact is that all dollars are not valued equally. If we want to, for example, add them up then we need a date attached to each one.
How do we value a software system? Say you have a software system & I want to buy it. How much should I reasonably pay you?
What the system _is_ is irrelevant. It's a payment system. It consists of umpteen services. It has 1.4 million lines of code. Its average function cyclomatic complexity is 14 (just kidding, the average of power-law-distributed values is useless). But none of this matters to me as a purchaser.
As a purchaser I want to know how the money is going to flow. "Gazinttas and gazouttas" as my Pappy would have said. To value the software, I can model it as a set of cash flows, some in, some out, but (and this is the key point) each flow connected to a date.
Which would you value more highly, a software system that over the next 10 years will:
Cost $10m & bring in $20m, or one that will,
Cost $10m & bring in $12m?
Trick question. "Over the next 10 years" is financially equivalent to saying "until the heat death of the universe". Those dollars aren't all the same. This is the first intuition about money--dollars without dates are as worthless as "lines of code per day" or any other bullshit metric.
Feel the difference between, "I pay $10m today & in 10 years I get $20m," and, "I get $12m today & in 10 years I pay $10m." That first deal gets me nervous. Yes, it seems like a good investment, but I'm going to be sweating out those 10 years. The second deal is a no brainer. I'm guaranteed $2m profit from day 1 plus whatever I get from investing over the 10 years. I'm excited about the 10 years instead of afraid of it.
How can we make time our friend in software development instead our inexorable enemy? By rowing with the time value of money instead of against it:
Spend money later
Earn money sooner
How do we use this understanding of money to make money with software design? Start with a distinction I wasn't making strongly enough for years: structure versus behavior.
*** And that’s where I realized I had driven into the weeds. Time to back up & start over.
This proto-chapter was still valuable -- thanks for sharing it!
I don't know if I'm thinking the same things.
It is useful to deliver sooner and more often. The client can use the software, I can get feedback (and get paid). This "small releases" approach has also other advantages (reduce complexity and others).
On the other hand, I would like this kind of collaboration to continue indefinitely. What can software design offer me?
I will design for current requirements. I make it somehow adaptable. I will apply tidy first for more adaptation. I will also evolve the legacy design based on the knowledge I have now.