Sunday, August 14, 2022
Delivery Lead Time, aka code velocity
If you care about software development for operations (DevOps) and the DevOps Research Assessment (DORA) guidelines, you know about the four DORA metrics. Following up on his excellent post about DORA metrics in 2022 earlier this year, Logan Mortimer has written an excellent, deep analysis of Delivery Time that's worth your time to read and understand, especially if you read Accelerate and want to implement DORA matrics in your organization.
Labels:
devops
Saturday, August 13, 2022
In God's Path by Robert Hoyland
I don't know why I subject myself to reading dense, detailed "phone book" history books with too many people and events to keep straight. The book is a great text book for students and professionals exploring 5th - 7th century accounts from all sides of the rise of the Islamic empire. I had no previous exposure to Persian, Byzantine, or North African history of that era, so it was very enlightening. And I appreciate the summary at the end describing the survival of non-Arabic languages. Our common understanding, history, and popular culture was written by the victors and this important book points out some inconvenient facts that are intrinsically interesting. 3/5 Stars, worth the intensity.
Thursday, August 4, 2022
Wednesday, August 3, 2022
I feel the earth move under my feet
Personally, I believe everyone in our solar system should settle upon a single time zone, a single time standard, and we should all stop being so provincial in our thinking. The most-adopted and most-popular time standards in communications, networking and computing are Unix Time in the UTC time zone. Unix Time is the number of seconds since Unix was created (on January 1, 1970) and the time zone called universal coordinated time or temps universel coordonné (UTC) is the standard timezone in which almost all computer system clocks are set. Folks in the military sometimes use "zulu" time, consisting of 4 digits and a trailing z, as in "1655z." The time zone "z" is UTC. The 4 digits are 24-hour HHMM. If we adopt this standard, eventually we could all drop the "z" and we would all share the meaning of what time it is in 4 digits. Wouldn't that be wonderful? The main problem with UTC and our time standards is the "leap second." Recently, the earth recorded its shortest day ever because earth's geographical poles (not the magnetic poles) moved so quickly. Normally earth's rotation is sped up by tides or earthquakes (tectonic shifts). Leap seconds were invented to add or subtract a second from UTC time to account for these changes in earth's rotation. What a clumsy hack!
There is a much-better standard than UTC, proposed in the 1970's and created by a now-defunct department of the French government (whose officials were called seigneurs du temps or time lords). The standard can keep track of the number of attoseconds since the big bang formation of the universe in our local general relativistic sphere. The standard is called International Atomic Time or temps atomique international (TAI). But very few of us bother to install the code libraries and use TAI for our logging timestamps or other purposes because people are lazy; they find it inconvenient to convert to and from the standard Unix Time in UTC that is used in the rest of our software and conventions. But think about it: Time Lords! C'mon man. Conversions are not that hard.
Now Meta (Facebook) has joined the anti-leap second fray. The discussions in Dubai next year should be interesting.
Hommage to Carol King for the title of this post.
Sunday, July 31, 2022
. . . and libyears to go before I sleep
A link to this idea appeared in my feed. I have noticed most people gravitate towards single-number summaries such as (shudder) arithmetic mean so the idea does have some merit. And, the measurement is very easy to drop into any set of repositories.
Apologies to Robert Frost for the title.
The woods are lovely, dark and deep,
But I have promises to keep,
And miles to go before I sleep,
And miles to go before I sleep.
But I have promises to keep,
And miles to go before I sleep,
And miles to go before I sleep.
Labels:
devops
Complexity & Chaos, cause Crushing Complications
Do you remember when our production systems were less-complicated and easier to debug? Production Issues were easy to diagnose and it was always faster to recover. I remember writing an application in a single page of HTML that used server-side include directives in the web server. The entire application (order form, order acknowledgment receipt, order processing) is 200 lines of HTML, 4.6KB. Sigh. Pete Hodgeson at Honeycomb wrote an interesting analysis of the giant leaps backwards we have made in the last 25 years because we have piled on so much unneeded complexity in our systems. Someday I may create a conspiracy theory based on the cui bono (who profits) from this ridiculous inefficiency. I recommend browsing through Hodgeson's article but not my HTML code or my article.
Labels:
devops
Saturday, July 30, 2022
Subscribe to:
Posts (Atom)