I'm taking cooking classes from Gloria Bonfanti this month.
Observations: I made some really good pizza yesterday, I chose to make a Margherita I believe it's called. When I opened the huge bag of basil leaves, it was like walking into an opium den. I almost passed out from a drug-induced stupor. I'd be making this again today if it weren't that it's my granddaughter's birthday and she's asked for feijoada.
We made risotto e funghi. Gloria likes a lot of salt in the food. When we tasted the risotto, she asked if we liked the taste. I said I did, but that it was too salty by far. She said, "Ah, now that's the French for you."
Then we made a penne with broccoli and sausage dish. It was fun using her kitchen for this: the broccoli blanched and the pasta cooked in little compartments that fit a rack then plunged into a deep fat fryer except filled with boiling water. When she asked how I thought it tasted, I said it was perfect. She said, "Hmmm... there's not nearly enough salt in it."
Next week is pollo con funghi, meatballs in tomato sauce and a section on how to marinate meat and potatoes.
The week after that is tiramisu and crostata al cioccolato.
It's very instructive to see how a practicing chef works. I'm now totally bummed by my own kitchen. I need a real cooktop and real ovens. I'm already starting to think seriously about the ovens because I've got room to do something about it if I want (because of how I redesigned my kitchen when we bought the house).
Technical debt is a recent metaphor in my industry concocted to refer to the phenomenon that as we write and modify computer program code, its increased complexity costs us more.
The idea is that as programs age, they cost a company more money in terms of developer time and expertise to maintain or enhance them. Debt can also be a function of resources the application consumes, stuff like computer power, database size, increased disk space, memory and network bandwidth requirements.
This debt metaphor applies especially to the accumulation of code that's duplicated, tightly coupled, untested or doesn't fall under paths of known test coverage—all creating the situation where a developer goes in to add a feature and finds either that he cannot do it without breaking something else because of unforeseen dependencies between existing components or must do a great deal more work because there are considerably more points in the source base that demand his attention than might be estimated.
Obviously, reducing existing debt is thought to be important; limiting it in the first place is a pretty big goal.
And yet, this metaphor can be abused.
One might postulate that an application's debt can be seen like a mortgage at a certain interest rate. If the company considers "paying it off," the exercise quickly becomes daunting. A great deal of effort must be expended to make that happen.
Of course, the tools used to measure technical debt are suspicious in and of themselves. Their use and configuration cannot be taken lightly.
In the end, technical debt isn't really like a mortgage because one needn't always pay it down. One particularly nasty component may, in the wisdom of a measuring tool, constitute a huge debt in terms of its complexity. But, tools don't measure the fact that maybe there aren't bugs in it or that there is little or no need to go into that component to do anything. Whatever its cost may be estimated at, if no developer's ever going to have to touch it, the imaginary cost is not important.
Other code that must be touched frequently, such as a user interface, would be an important undertaking full of potential pitfalls. It would be more important to concentrate on doing it right, maybe choosing a widely understood framework, ensuring freater much test coverage, etc. than other components.
Beyond these considerations is the longevity of an application. If an application is soon to be replaced by a new version or by another application altogether, it's not important to spend any more money on it. It's like spending money on janitors to clean up a building that will fall to the wrecking ball.
Nevertheless, this metaphor is apt. And it underlines the need for software development to be agile, invested in test- or behavior-driven development techniques so that no code is written that's not covered by tests.
Test first; then code. State behavior by means of a test first, then code to solve the challenge.
