On the Seventh Day

Before I get started, it's a good time to correct errata that occurred in previous blog entries.


First of all, my dog is not 155 pounds--which should have read "55 pounds," anyway--but is, according to the scale at my vet's, 67 pounds. And why you care is because of my comment that my dog walks me and not the other way around. If he did outweigh me by 20 pounds, as originally reported, it's not so unusual that he can pull me around. (Though I defy anyone to maintain footing when Thunder sees--as he did last winter--11 uninvited elk bedded down in his backyard.  Big excitement. He pulled me right over.)


Second of all, I am pleased to report that Jack Love, my former Hebrew teacher, whom I had reported as no longer teaching Hebrew is, in fact, still teaching Hebrew. Barukh ha-Shem (Hebrew for "Praise the Lord," though literally, "Bless the Name!") I hope to see him at Oracle OpenWorld and catch up on his family and the Qal conjugation. He's about to start teaching Aramaic, which is also a cool language.



I am writing this in advance of Labor Day. The welcome prospect of a three-day weekend got me to thinking about how we work, why we work, and how almost everything in our lives is now geared to cramming in as much activity as possible to the allotted time. (And yes, ultimately there is a security issue there.) The way so many of us work, you almost think we are hoping our epitaph will read: "My inbox was empty," which would be sad, indeed.


The reality is that you need a certain amount of time to do certain activities well, and shortchanging the time means the activity is shortchanged, also. Nothing very profound there. Whether you are talking about work or leisure, time isn't unlimited and the "when" of time is often as important as the "how much" of time.


For example, when I am in San Francisco, I like to surf after work. Generally, the later I go, the better, since I enjoy catching a nice sunset and the beach isn't as crowded close to dark. (One of the guys at my local surf break is convinced I am a vampire, since he never sees me in daylight.)  The only problem is that, when I don't pay attention to when sunset actually is (it's published in the paper every day, generally with the tide tables that are a surfer's friend), or I get caught in traffic getting to the beach, I have a really small window of time in which to surf.


I might be--and often am--very motivated to catch lots of waves after a hard day, but no matter how hard I push myself, you only get 20 minutes or so of "afterglow" after the sun goes down. Ceteris paribus (fancy Latin term economists use that means "all things being equal") I just cannot catch as many waves in 20 minutes as I can when I'm out in the lineup for, say, 2 hours. Surfing in darkness is risky both because you have to feel--not see--the swell, and because it is "predator feeding time." Shudder.


A subtler point is that the joy of surfing isn't merely the number of waves I catch. If I miss the sunset (because I had to do "just one more email"), it isn't just that I get fewer waves because there is only a small window of daylight. I missed the ineffable beauty of watching the sun go down from my surfboard, and I will never get it back. Carpe diem ("seize the day"), indeed.


Time is always a factor in product development cycles. You have a certain amount of overhead related to just getting your product out. On the front end, this can include requirements gathering, design, test plans and reviews to make sure you got the requirements and design nailed before you start actual coding. On the back end, testing, documentation, training (your sales folks and support analysts need to understand the product), and for Oracle, rolling products out in production, since we run our own company on our own software. "Eating our own dogfood," is the industry-standard phrase, though I prefer "sipping our own champagne." The actual coding time isn't always that long compared to the overhead of getting the release out ("overhead" here is not meant pejoratively). In some cases, it doesn't need to be, just as baking a pie goes a lot faster if you've laid out all the ingredients, measuring cups, utensils, and preheated the oven ahead of time. (I can make a rhubarb pie in about 15 minutes if I use pre-made piecrusts and have everything ready to cut and measure before starting.)


I joke from time to time that the software industry is the only one that tries to shoehorn in extra things to a product on the grounds that they haven't actually cut the tape (or burned a CD) yet. Imagine what would happen to automobiles if, say, General Motors decided a week before cars were to be manufactured that they should add an extra row of seats and throw the air-conditioner in the trunk. Needless to say, you don't always get good results when you make drastic changes late in the game. (Like deciding to make a peach pie instead of a rhubarb pie just before I pop dessert in the oven. Uh, it's too late, really. The crust is already sealed.) Development process is important, and so is the actual discipline of adhering to the process. I have to discipline myself to leave work at a reasonable hour if I want to improve my surfing (through regular practice) and people building software have to discipline themselves not to add a ton of stuff 20 minutes before the product ships (or suffer the consequences).


Sometimes there is a tendency to think that more resources will help a time crunch. The reality is that at some point you cannot successfully add more people or "machines" to get something faster. In my earlier example, more surfboards wouldn't help me catch more waves in 20 minutes. Similarly, 9 women can't collectively have a baby in one month. I took a quantitative methods class in business school that impressed this lesson upon me very well. (In quantitative methods, you had problems you were supposed to optimize the solutions for and yes, we used computers to do it, and yes, that's when it first dawned on me that I was really a lousy programmer.)  Probably the most important lesson I took away from that class was that (and of course, the programming language we used also imposed this limitation): you simply can't optimize on all parameters. You can't maximize A, B and C and minimize D, E and F. A glib way of remembering this is the expression: "You can have it right, or you can have it now, but you can't always have it right now."

Where does this leave us as regards security? First of all, while people sometimes complain about process "adding time to releases," good processes are developers' friends. I once worked on a vertical market product team where we did't "own the code." The team that did "own the code" we were adding a feature to was quite proprietary about it (even insisting we indent their code their way), including rigorous reviews of functional and design specs. Wonder of wonders, due to all the reviews and "work upfront" to make sure we knew exactly how our new accounting feature was supposed to work and everybody bought off on it, there were no changes to the feature once the developer started coding. He just sailed right along, coded it in record time and the feature did exactly what it was supposed to do--and no more. It was one of the smoothest projects I have ever worked on and made me a process fanatic. The result was high quality code, and few bugs, since he knew what he was going to code before he started and there were no late-breaking changes to add complexity and "unintended consequences."

Thrashing around because you forgot something or had to go back to redo something all wastes time. Good process doesn't produce perfect product, or perfectly secure product, but more people won't fix a bad process. Developers would rather "code smoothly" than redo things, which is why (beating this horse to an efficient death), we really try to embed security into the development process itself and have a strong development process that we stick to with discipline. If you haven't discovered this yourself, "just start coding" is not a development process.

Second, and perhaps more subtle point: you need to encourage good behavior as regards secure coding practice, to include measuring and rewarding the right things--and giving people enough time to do what you are expecting them to do. I've (on rare occasions) had developers sidle up to me and say that they wanted to take the time to do all the correct input validation, but their manager was more concerned about getting the feature done than doing the right validation. True, nobody has infinite time to work on a release. True, we do want to add new cool enhancements. More true, it's "pay now or pay later" as regards secure coding. You code it right the first time or I can abso-bloody-lutely guarantee you will be revisiting that code later. I talked in an earlier blog about the importance of adding time to a development cycle (once you start using automated tools), so you give developers time to fix the problems they find in their code.  You want people to use the tools, and fix what they find. Encourage and reward good behavior by allowing time for people to do good work.

One of the changes we've implemented to try to reward the right behavior is (with regard to bugs), while the general metric once you do find a bug is "how fast did you close it?," the relevant metric with regard to security bugs is "did this bug ever get reopened?" You can get someone to close a security bug really fast if they only fix the exact manifestation or fault that was reported.  What you want is for them to fix it completely, which--ceteris paribus--may mean that that it takes longer to fix it, to find and fix all conditions that will cause you problems, not just the single one that was reported. You can have it right, or you can have it now, but you can't always have it right now.


One last point about time, which perhaps is what I was leading up to, is that sometimes the best thing you can do with it is respect it and respect people's use of it. If you don't, you lose good people, which isn't a security problem per se but it is a management one.


When I was in the Navy, I was literally on duty 24 hours a day. Many military officers give up part of their weekends regularly to stand watch (I am proud to say, we never had enemies of the United States break into my barracks building in Newport, Rhode Island. Everyone at the Naval Education and Training Center could sleep soundly on that point.)  Also, you are never not a naval officer. Your time is the Navy's because you are always on duty, to a point. You can have leave (vacation) cancelled for things like, oh, war breaking out. Most people in the armed forces understand things like "I am sorry, your honeymoon is cancelled, the ship has to deploy to quell unrest in (name troubled spot in the world)."


For the most part, corporate America (or corporate anywhere) does not have "national emergencies" like that. We do have customers who operate around the world, and many companies have adapted their business (e.g., their support organizations) to "follow the customers around the globe." This is just being a good supplier and partner of customers. That's a different thing from asking a particular individual to "follow the globe" and stay up for 24 hours. People who work in IT like machines that are up 7 by 24, but realistically, people need regular "downtime" or they have a "core dump." Unfortunately, some of us suffer from a lack of perspective that treats time as something that we always have plenty of, and that means we are not willing to make reasonable and considerate choices in terms of how we spend our time and other people's time. Employees are generally not on duty 24 hours a day, and shouldn't be.


A long time ago, I worked for a manager who (I am not making this up) asked my coworker not to go on her honeymoon for something work-related. Mind you, she and her husband had planned their honeymoon around the Olympics that year (and had gotten tickets) so postponing the honeymoon really meant derailing their plans for 4 years, not a couple of weeks. I am pleased to note that my then-manager's Senior Vice President got wind of the "postpone your honeymoon" VP's management techniques, ran down to the VP's office, closed the door and said "What are you thinking? Let the woman go on her honeymoon!" Nobody remembers what was allegedly so critical that my coworker should have given up her honeymoon, but I can guarantee you that had that VP persisted, I would have lost a valuable coworker (and her husband, who also worked for the company).


One way to gauge how important something is that you are asking an employee to give up something personal for it is to ask the question: "Will this matter in a week? A month? A year?" Time is so precious and (generally speaking), you are only going to have one honeymoon. Maybe there is a sunset every evening, but oh, the beautiful ones I have seen-- each one of them different, and I treasure them all.


 The origin of the word "Sabbath" is the Hebrew word shabbat (ת×�שׂ). Shabbat means "cease" or "rest," and the first place it appears in the Bible is the book of Genesis (Bereshith, in Hebrew).  "And on the seventh day God ended his work which he had made; and he rested on the seventh day from all his work which he had made." (Gen 2:2) Which is where we get both the idea of a Sabbath, and the word for it. From time to time in my career I have had to work on weekends, if not through the weekend. Weekends when I did naval reserve duty, for example, or times when I worked in development organizations and we were trying to ship product. "Sometimes, you just gotta." But as a general rule, I do like to remember that even God rested on the seventh day. (And thus, being human, I figure it should be OK that we take two days off every week.)


Many people are familiar with a section of the book of Ecclesiastes, in no small part because it was made into a hit song in the 1960s called "Turn, Turn, Turn." The passage begins, "There is a time for everything, and a season for every activity under heaven." You can listen to the song (The Byrds recorded it) or check out Ecclesiastes 3 if you want to read the entire thing. Most people miss the punchline, which is even more lyrical:


9 What does the worker gain from his toil? 10 I have seen the burden God has laid on men. 11 He has made everything beautiful in its time.


Labor Day is a good day to rest from your labors, and to experience something beautiful in its time. The work will still be there tomorrow. Me, I have an appointment with a fly rod and the Big Wood River.


Of course, now I am too old to be much of a fisherman, and now of course I usually fish the big waters alone, although some friends think I shouldn't. Like many fly fishermen in western Montana where the summer days are almost Arctic in length, I often do not start fishing until the cool of the evening. Then in the Arctic half-light of the canyon, all existence fades to a being with my soul and memories and the sounds of the Big Blackfoot River and a four-count rhythm and the hope that a fish will rise.

Eventually, all things merge into one, and a river runs through it. The river was cut by the world's great flood and runs over rocks from the basement of time. On some of the rocks are timeless raindrops. Under the rocks are the words, and some of the words are theirs. I am haunted by waters.

A River Runs Through It, by Norman MacLean

For more information:


On the meaning of ceteris paribus:<o:p></o:p>




An interlineal (Hebrew and English) Bible entry for Genesis 2:




And for Ecclesiastes 3:




More about A River Runs Through It:




More about flyfishing on the Big Wood River:




Hello! I find your blog very interesting. I like the mix between the passion for dogs & cryptography :) I hope you will write more soon. Take care! Anca

Posted by Anca on September 26, 2006 at 09:10 AM PDT #

Would love to see you in a future blog entry comment on Oracle's adoption of the XACML specification throughout its product line and the benefits it will bring to customers...

Posted by James on October 28, 2006 at 09:05 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed



« July 2016