September/October 2018 issue of acmqueue The September/October issue of acmqueue is out now

Subscribers and ACM Professional members login here



Development

  Download PDF version of this article PDF

Error 526 Ray ID: 48b0f140c8b29fba • 2018-12-18 10:28:23 UTC

Invalid SSL certificate

You

Browser

Working
Ashburn

Cloudflare

Working
deliverybot.acm.org

Host

Error

What happened?

The origin web server does not have a valid SSL certificate.

What can I do?

If you're a visitor of this website:

Please try again in a few minutes.

If you're the owner of this website:

The SSL certificate presented by the server did not pass validation. This could indicate an expired SSL certificate or a certificate that does not include the requested domain name. Please contact your hosting provider to ensure that an up-to-date and valid SSL certificate issued by a Certificate Authority is configured for this domain name on the origin server. Additional troubleshooting information here.

acmqueue

Originally published in Queue vol. 10, no. 3
see this item in the ACM Digital Library


Tweet


Related:

Alpha Lam - Using Remote Cache Service for Bazel
Save time by sharing and reusing build and test output


Jez Humble - Continuous Delivery Sounds Great, but Will It Work Here?
It's not magic, it just requires continuous, daily improvement at all levels.


Nicole Forsgren, Mik Kersten - DevOps Metrics
Your biggest mistake might be collecting the wrong data.


Alvaro Videla - Metaphors We Compute By
Code is a story that explains how to solve a particular problem.



Comments

(newest first)

Bob Binder | Fri, 14 Sep 2012 15:35:40 UTC

Although the technical debt metaphor is very catchy, it is not quite apt. I've argued that "technical equity" is an equally important notion for understanding the consequences of development choices. http://www.robertvbinder.com/technical-equity/

Recasting technical debt as a call option is interesting, but isn't quite right either - options are much more complex than an IOU. Buying a "naked" call on an underlying stock means that you spend a small amount in the present so that you may realize a gain in the future, but only if the value of the underlying stock increases by more than the cost of the option. The buyer risks the cost of the option to gain the possible increase. Selling a naked call has a mirror effect. Typically, you sell a call only if you expect the underlying value to drop, so that the counterparty will not require you to give them the optioned shares of the underlying. The seller's profit is the price of the option. If the underlying value rises and the buyer exercises your call, you have to buy the underlying at the higher price and give it to call buyer -- your net cost is the (higher) price of the underlying less the money received from selling the call. So, the call seller is at risk for that cost. All of this is predicated on a fixed and certain date for exercising the call, usually less than three months.

Is deferring or skimping on development like buying a naked call? Yes, in that choosing to pay a small cost now may lead to a larger benefit later (for example, designing an API, but only implementing the interface code.) But who is selling the call? Who believes that the value of your codebase will decline? Options don't make sense (and would not trade) without a counterparty that is more or less pessimistic/optimistic. The metaphor places the codebase sponsor/owner in the role of selling a naked call, which only works if we assume the sponsor believes the developer's work will be worth less later.

Similarly, making an implicit commitment to future payback for deferred or inadequate development (technical debt) is rarely based on a quantified analysis of cost/benefit or the sustainability of that commitment. The codebase sponsor/owner is the "lender" and rarely understands the economic implications of the arcane and often arbitrary decisions of developers, or of shortcuts taken to cut time and cost, or just plain incompetence. http://www.robertvbinder.com/how-technical-debt-turns-into-technical-bankruptcy/ http://www.robertvbinder.com/how-a-big-ball-of-mud-becomes-a-black-hole-why-software-architecture-and-process-matters/

I like these metaphors to the extent that they remind us of the consequences of software development strategies and trade-off choices, but they are very thin conceptual ice.


George Samaras | Fri, 25 May 2012 21:24:50 UTC

Excellent! Very well presented; now, if only folks will pay attention... BTW, your "3 variables" + debt correspond to the four fundamental attributes of new product development: Budget (resources), Schedule (time), Scope (functionality), and Quality (technical debt). So, what you are describing when you discuss different perspectives of managing technical debt is how specific stakeholders prioritize their own needs, wants, and desires and thus determine quality of the product, process, or service. GM Samaras Pueblo, CO


Leave this field empty

Post a Comment:







© 2018 ACM, Inc. All Rights Reserved.