13 November 2018

Canceling Query

This query has been running for six and a half minutes and I'm expecting a call from a DBA any minute now. So I try to cancel it, but SQL Studio knows: I'm in too deep. It tells me, "Canceling query..." and there's a helpful little spinner to show it's doing its best.

Nine minutes. Ten.

Not good enough, SQL Studio. Not good enough, Micah.

Nothing. Is. Good. Enough.

Ring, ring.

Our Meal

This morning, I shared a meal with a 97-year-old woman who should have died in surgery and a single mother struggling to keep the lights on and an older man immersed in a slog of depression. We came hungry, broken, and tired, intensely aware of our deep need.

We feasted on the holy love generated by our shared lives, shared pain, and shared redemption. We wept and laughed and prayed together, delighting in brothers and sisters who gladly bear our burdens, share our joys and sorrows, and give selflessly, generously, of themselves.

We also feasted on physical food: Bits of bread torn from the loaf, just as our outlawed Lord's body was torn by His tormentors; sips of blood-red juice poured from the cup, just as His blood dripped onto the dry dust beneath His cross.

It's a desperate sort of remembrance, I suppose. After all, what sort of fool places his hope in the strength of a condemned, tortured man slowly suffocating beneath a darkened sky two millennia ago?

The answer is desperate fools like me. We see the weakness of our own strength. We see the futility of our self-made righteousness. And we are captured by the glorious hope in this story that sometimes seems too good to be true. 

More than that, we see its fruit in our lives. If this be a vain pretense, then it is at least one that has swept away vast swaths of darkness and death in my life and the lives of my sisters and brothers. It has utterly changed me and continues to do so.

So I partook of the blessed feast again this morning, looking back with thankfulness at how it removed me from the realm of darkness and death and looking forward with hope to the redemption of my flesh and this lovely broken world. Even so, come quickly, Lord Jesus.

11 October 2018

The Great Bug Hunt

Day after futile day,
I chase code across the screen
Until I'm cross-eyed
And my brain doesn't remember, anymore,
What solutions I've tried.

I've tried them all, I think,
And then some. Even StackOverflow,
That great oracle, has run dry.
OK, Google, let's try this one more time
With slightly different terms.

I hope against hope to find some overlooked
Silver bullet, a magical panacea
To banish this mysterious bug
That infects my code.

Perhaps some generous soul has posted the answer
After sharing my travail and triumphing over it --
But alas! I cannot find any.

My search result links are all purple:
Used up, worthless, desiccated husks.
I still re-click them, of course,
Because deep down I think it ridiculous
That this blasted problem hasn't been solved,
And I still hold out hope that I will
Land on precisely the right page,
Scroll to precisely the right line,
And see there, in lovely  black and white,
The blessed answer to my troubles.

(I do not, of course.)

And so at last I return,
Again and again and again,
To the debugger,
Trying to evade insanity
And somehow discover,
Perhaps in a divine epiphany,

The source of all my trouble.

10 October 2018

Terrorism Rerun

The radio says
Terrorists hit a train
As if it is all Quite Shocking Indeed.
Three are dead,
Two were brothers,
And one the authorities haven't yet named.

I cut off the radioman in the middle
Of his frantic lament
And think of Thoreau, who,
when offered a newspaper,
Said "No, thanks -- I've already seen one."

This is like how TBS shows the same movie
Twelve times in two weeks.

I've seen this already
In Paris and Kabul
And Denver and Belfast and Hiroshima
And Baghdad and Constantinople
And Manila and Capetown and Bethlehem.

The ending is unbelievable and unoriginal,
And that actress was much prettier
When she was much younger.

Isn't it strange
How much a person can change
Over time,
And yet how little

People do?

23 September 2018

The Mythical Man-Month: A Review

I picked up Frederick P. Brooks Jr.'s The Mythical Man-Month from the library on the advice of my friend Judson, who called it "required reading for anyone in the software profession." I'm so glad I did! This is easily my favorite piece of writing about computer engineering.

(Note: All my page numbers come from the 20th anniversary edition, linked above.)

In the very first chapter, "The Tar Pit," Brooks gives a compelling list of reasons why programming is rewarding. He concludes it with:
The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures. (As we shall see later, this very tractability has its own problems.) (p. 7)
Brooks writes clearly, intelligently, and occasionally very beautifully about the craft of software development. Another example of his wisdom wrapped in elegant prose comes later in the same chapter:
For the human makers of things, the incompleteness and inconsistencies of our ideas become clear only during implementation. Thus it is that writing, experimentation, "working out" are essential disciplines for the theoretician (p. 15). 
Although it has some lovely passages, the book is not principally a collection of creative essays about programming. Rather, it is Brooks's attempt to identify and correct some of the common problems that software development professionals go through. It contains some really good advice and valuable cautionary statements. For example, in the chapter that gives the book its title:
Hence the man-month as a unit for measuring the size of a job is a dangerous and deceptive myth. It implies that men and months are interchangeable (p. 16, emphasis in original).
This is excellent advice for programmers, but even better advice for project managers and upper management in technology companies. Brooks has valuable ideas, too, for technical writers:
English, or any other human language, is not naturally a precision instrument for [definitions of system architecture]. Therefore the manual writer must strain himself and his language to achieve the precision needed. An attractive alternative is to use a formal notation for such definitions (p. 63).
And again, for testers:
The project manager's best friend is his daily adversary, the independent product-testing organization. This group checks machines and programs against specifications and serves as a devil's advocate, pinpointing every conceivable defect and discrepancy. Every development organization needs such an independent auditing group to keep it honest. 
In the last analysis the customer is the independent auditor. In the merciless light of real use, every flaw will show. The product-testing group then is the surrogate customer, specialized for finding flaws. Time after time, the careful product tester will find places where the word didn't get passed, where the design decisions were not properly understood or accurately implemented. For this reason such a testing group is a necessary link in the chain by which the design word is passed, a link that needs to operate early and simultaneously with design (p. 69).
Some of the documentation sections also have important thoughts for UX designers:
A computer program is a message from a man to a machine. The rigidly marshaled syntax and the scrupulous definitions all exist to make intention clear to the dumb engine.
But a written program has another face, that which tells its story to the human user. For even the most private of programs, some such communication is necessary; memory will fail the author-user, and he will require refreshing on the details of his handiwork.
I really love Brooks's concrete examples. To illustrate the role of upstream dependencies in planning, he writes that "The bearing of a child takes nine months, no matter how many women are assigned" (p. 17). Later, he gives the extended example of an omelette when discussing why it's important not to deliver a product before it's ready (p. 21).

For all of its usefulness, this isn't a perfect book. It was written in 1975, so many examples and ideas are outdated or irrelevant.

For instance, we don't need a pool of typists to compile the code changes from the previous day and bind them in a book for distribution to all programmers. Shared version control has thankfully made that practice a thing of the past.

There are also lengthy treatments of sharing processing time, dumping memory to printouts for debugging, and low-level hardware and software concerns that modern programmers simply don't have to deal with anymore.

For this reason, some reviewers have complained that the book is so outdated as to be of very little use. I have a couple of responses to this:

  1. Many of the technological advances we enjoy today are owing to people like Brooks, who highlighted the difficulty of the status quo. This book is such a fundamental building block in our field that it has almost certainly encouraged the growth of IDEs with integrated debuggers, shared source control repositories, and so on.
  2. Even though some parts are not relevant today, they still serve a valuable historical purpose. In addition, they often have analogs to problems we face in programming today.
Another drawback that some reviewers have noted is Brooks's very traditional mindset. For example, he makes no effort to consider the existence of women in any role other than members of the secretarial pool. The theoretical programmer always gets "he/him/his" pronouns. While this is problematic in our modern culture, it is perhaps relevant that in Brooks's time, very few women were programmers. Thus, his assumption that they would be male is at least statistically defensible, if not ideologically so.

I think this book is worth a read for anyone in the software development industry. Project managers and people managers would find it especially useful, I think. Most of the less useful and applicable portions are later in the book, so I'd advise reading the first three or four chapters pretty carefully, then skimming the remainder if you'd prefer.