tag:blogger.com,1999:blog-29543598122490720532017-08-17T21:24:38.926-07:00Cary MillsapMy web log for things I’m interested in, including design, software development, performance analysis, learning, and running a business.Cary Millsaphttp://www.blogger.com/profile/16697498718050285274noreply@blogger.comBlogger110125tag:blogger.com,1999:blog-2954359812249072053.post-46077808176877327232017-08-15T16:25:00.000-07:002017-08-15T16:25:23.106-07:00Words I Don’t Use, Part 5: “Wait”The fifth “word I do not use” is the Oracle technical term <i>wait</i>.<br /><h2>The Oracle Wait Interface</h2>In 1991, Oracle Corporation released some of the most important software instrumentation of all time: the wait statistics that were implemented in Oracle&nbsp;7.0. Here’s part of the story, in <a href="https://www.oracle.com/corporate/executives/juan-loaiza.html" target="_blank">Juan Loaiza</a>’s words, as told in <a href="http://amzn.to/2bGSJ46"><i>Nørgaard et. al (2004), Oracle Insights: Tales of the Oak Table</i></a>.<br /><blockquote class="tr_bq">This stuff was developed because we were running a benchmark that we could not get to perform. We had spent several weeks trying to figure out what was happening with no success. The symptoms were clear—the system was mostly idle—we just couldn’t figure out why.<br /><br />We looked at the statistics and ratios and kept coming up with theories, the trouble was that none of them were right. So we wasted weeks tuning and fixing things that were not the problem. Finally we ran out of ideas and were forced to go back and instrument the code to figure out what the problem was.<br /><br />Once the waits were instrumented the problem was diagnosed in minutes. We were having “free buffer” waits because the DBWR was not writing blocks fast enough. It’s amazing how hard that was to figure out with statistics, and how easy it was to figure out once the waits were instrumented.<br /><br />...In retrospect a lot of the names could be greatly improved. The wait interface was added after the freeze date as a “stealth” project so it did not get as well thought through as it should have. Like I said, we were just trying to solve a problem in the course of a benchmark. The trouble is that so many people use this stuff now that if you change the names it will break all sorts of thing tools, so we have to leave them alone.</blockquote>Before Juan’s team added this code, the Oracle kernel would show you only how much time its <i>user</i> calls (like <i>parse</i>, <i>exec</i>, and <i>fetch</i>) were taking. The new instrumentation, which included a set of <a href="http://docs.oracle.com/database/121/REFRN/GUID-4EDAB293-F3FC-40FE-BC75-4FEE6A4D7705.htm#REFRN30229" target="_blank">new fixed views like <i>v$session_wait</i></a> and <a href="http://amzn.to/2bzTJd0" target="_blank">new <code>WAIT</code> lines in our trace files</a>, showed how much time Oracle’s <a href="https://en.wikipedia.org/wiki/System_call"><i>system</i> calls (like reads, writes, and semops)</a> were taking.<br /><h2>The Working-Waiting Model</h2>The wait interface begat a <a href="https://support.oracle.com/epmos/faces/DocContentDisplay?id=190124.1" target="_blank">whole new mental model about Oracle performance, based on the principle of <i>working</i> versus <i>waiting</i></a>:<br /><blockquote class="tr_bq"><a href="https://support.oracle.com/epmos/faces/DocContentDisplay?id=223117.1" target="_blank">Response Time = Service Time + Wait Time</a></blockquote>In this formula, Oracle defines <i>service time</i> as the duration of the CPU used by your Oracle session (the duration Oracle spent <i>working</i>), and <i>wait time</i> as the sum of the durations of your Oracle wait events (the duration that Oracle spent <i>waiting</i>). Of course, <i>response time</i> in this formula means the duration spent inside the Oracle Database kernel.<br /><h2>Why I Don’t Say <i>Wait</i>, Part 1</h2>There are two reasons I don’t use the word <i>wait</i>. The first is simply that it’s ambiguous.<br /><br />The Oracle formula is okay for talking about database time, but the scope of my attention is almost never just Oracle’s response time—I’m interested in the <i>business’s</i> response time. And when you think about the whole stack (which, of course you do; <a href="https://www.blogger.com/blogger.g?blogID=2954359812249072053">see holistic</a>), there are events we could call <i>wait events</i> all the way up and down:<br /><ul><li>The customer <b>waits</b> for an answer from a user.</li><li>The user <b>waits</b> for a screen from the browser.</li><li>The browser <b>waits</b> for an HTML page from the application server.</li><li>The application server <b>waits</b> for a database call from the Oracle kernel.</li><li>The Oracle kernel <b>waits</b> for a system call from the operating system.</li><li>The operating system’s I/O request <b>waits</b> to clear the device’s queue before receiving service.</li><li>...</li></ul>If I say <i>waits</i>, the users in the room will think I’m talking about application response time, the Oracle people will think I’m talking about Oracle system calls, and the hardware people will think I’m talking about device queueing delays. Even when I’m not.<br /><h2>Why I Don’t Say <i>Wait</i>, Part 2</h2>There is a deeper problem with <i>wait</i> than just ambiguity, though. The word <i>wait</i> invites a mental model that <i>actually obscures your thinking about performance</i>.<br /><br />Here’s the problem: <i>waiting</i> sounds like something you’d want to avoid, and <i>working</i> sounds like something you’d want more of. Your program is <i>waiting</i>?! Unacceptable. You want it to be <i>working</i>. The connotations of the words <i>working</i> and <i>waiting</i> are unavoidable. It sounds like, if a program is waiting a lot, then you need to fix it; but if it’s working a lot, then it is probably okay. Right?<br /><br /><a href="https://method-r.com/2013/02/19/why-you-should-focus-on-lios-instead-of-pios/" target="_blank">Actually, no.</a><br /><br />The connotations “work is virtuous” and “waits are abhorrent” are <i>false</i> connotations in Oracle. One is not inherently better or worse than the other. <i>Working</i> and <i>waiting</i> are not accurate value judgments about Oracle software. On the contrary, they’re not even <i>meaningful</i>; they’re just arbitrary labels. We could just as well have been taught to say that an Oracle program is “working on disk I/O” and “waiting to finish its CPU instructions.”<br /><br />The terms <i>working</i> and <i>waiting</i> really just refer to different subroutine call types:<br /><br /><table style="margin-left: 2em;"><tbody><tr><td class="right nowrap">“Oracle is <i>working</i>”</td><td class="nowrap">means</td><td class="nowrap">“your Oracle kernel process is executing a <i>user</i> call”</td></tr><tr><td class="right nowrap">“Oracle is <i>waiting</i>”</td><td class="nowrap">means</td><td class="nowrap">“your Oracle kernel process is executing a <i>system</i> call”</td></tr></tbody></table><br />The working-waiting model implies a distinction that does not exist, because these two call types have equal footing. One is no worse than the other, except by virtue of how much time it consumes. <i>It doesn’t matter whether a program is working or waiting; it only matters how long it takes.</i><br /><h2>Working-Waiting Is a Flawed Analogy</h2>The working-waiting paradigm is a flawed analogy. I’ll illustrate. Imagine two programs that consume 100&nbsp;seconds apiece when you run them:<br /><br /><table><thead><tr><td class="column-label" colspan="2"><b>Program A</b></td><td style="width: 4em;"></td><td class="column-label" colspan="2"><b>Program B</b></td></tr><tr><th class="number">Duration</th><th class="column-label">Call type</th><td></td><th class="number">Duration</th><th class="column-label">Call type</th></tr></thead> <tbody><tr><td class="number">98</td><td>system calls (waiting)</td><td></td><td class="number">98</td><td>user calls (working)</td></tr><tr><td class="number">2</td><td>user calls (working)</td><td></td><td class="number">2</td><td>system calls (waiting)</td></tr></tbody> <tfoot><tr><th class="number">100</th><th class="column-label">Total</th><td></td><th class="number">100</th><th class="column-label">Total</th></tr></tfoot> </table><br />To improve program&nbsp;A, you should seek to eliminate unnecessary system calls, because that’s where most of A’s time has gone. To improve&nbsp;B, you should seek to <a href="https://method-r.com/2013/02/19/why-you-should-focus-on-lios-instead-of-pios/">eliminate unnecessary user calls</a>, because that’s where most of B’s time has gone. That’s it. <a href="https://method-r.com/Faq_quare/explain-method-r/" target="_blank">Your diagnostic priority shouldn’t be based on your calls’ names; it should be based solely on your calls’ contributions to total duration.</a> <i>Specifically, conclusions like, “Program&nbsp;B is okay because it doesn’t spend much time waiting,” are false.</i><br /><h2>A Better Model</h2>I find that discarding the working-waiting model helps people optimize better. Here’s how you can do it. First, understand the substitute phrasing: <i>working</i> means executing a <i>user</i> call; and <i>waiting</i> means executing a <i>system</i> call. Second, understand that <a href="http://amzn.to/2uNVh7R" target="_blank">the excellent ideas people use to optimize other software</a> <a href="http://carymillsap.blogspot.com/2010/09/my-otn-interview-at-oow2010-which-hasnt.html" target="_blank">are excellent ideas for optimizing Oracle, too:</a><br /><ol><li><a href="http://carymillsap.blogspot.com/2008/12/small-adventure-in-profiling.html" target="_blank">Any program’s duration is a function of all of its subroutine call durations (both user calls and system calls),</a> and</li><li><a href="https://carymillsap.blogspot.com/2015/02/what-happened-to-when-application-is.html" target="_blank">A program is running as fast as possible only when (1)&nbsp;its unnecessary calls have been eliminated, and (2)&nbsp;its necessary calls are running at hardware speed.</a></li></ol>Oracle’s wait interface is vital because it helps us measure an Oracle program’s <i>complete</i> execution duration—not just Oracle’s <i>user</i> calls, but its <i>system</i> calls as well. But I avoid saying <i>wait</i> to help people steer clear of the incorrect bias introduced by the working-waiting analogy.Cary Millsaphttp://www.blogger.com/profile/16697498718050285274noreply@blogger.com3tag:blogger.com,1999:blog-2954359812249072053.post-75944183130626000342017-08-07T07:55:00.000-07:002017-08-07T14:12:46.681-07:00Words I Don’t Use, Part 4: “Expert”<div class="separator" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em; text-align: center;"><a href="https://en.wikipedia.org/wiki/Nullius_in_verba"><img border="0" data-original-height="197" data-original-width="383" height="164" src="https://2.bp.blogspot.com/-d6lX33Xxscw/WXpPk02ltUI/AAAAAAAACQQ/tnbAjxUfLwYGWl_gR4WoJNfzlbHyK78UwCLcBGAs/s320/CA-Plate.png" width="320" /></a></div>The fourth “word I do not use” is <i>expert</i>.<br /><br />When I was a young boy, my dad would sometimes drive me to school. It was 17&nbsp;miles of country roads and two-lane highways, so it gave us time to talk.<br /><br />At least once a year, and always on the first day of school, he would tell me, “Son, there are two answers to every test question. There’s the correct answer, and there’s the answer that the teacher expects. ...They’re not always the same.”<br /><br />He would continue, “And I expect you to know them <i>both</i>.”<br /><br />He wanted me to make perfect grades, but he expected me to understand&nbsp;<i>my responsibility</i> to know the difference between <i>authority</i> and <i>truth</i>. <a href="http://www.fotuva.org/feynman/what_is_science.html" target="_blank">My dad thus taught me from a young age to be skeptical of experts.</a><br /><br />The word <i>expert</i> always warns me of a potentially dangerous type of thinking. The word is used to confer authority upon the person it describes. But it’s <i>ideas</i> that are right or wrong; not <i>people</i>. You should evaluate an idea on its own merit, not on the merits of the person who conveys it. <a href="https://en.wikiquote.org/wiki/Arthur_C._Clarke" target="_blank">For every expert, there is an equal and opposite expert;</a> <a href="https://en.wikipedia.org/wiki/Clarke%27s_three_laws" target="_blank">but for every fact, there is not necessarily an equal and opposite fact.</a><br /><br />A big problem with <i>expert</i> is corruption—when self-congratulators hijack the label to confer authority upon themselves. But of course, misusing the word erodes the word. After too much abuse within a community, <i>expert</i>&nbsp;makes sense only with finger quotes. It becomes a word that critical thinkers use only ironically, to describe people they want to avoid.Cary Millsaphttp://www.blogger.com/profile/16697498718050285274noreply@blogger.com6tag:blogger.com,1999:blog-2954359812249072053.post-65841936519056720832017-07-29T08:24:00.000-07:002017-07-29T08:24:02.563-07:00Words I Don’t Use, Part 3: “Best Practice”The third “word I do not use” is&nbsp;<i>best practice</i>.<br /><br />The “best practice” serves a vital need in any industry. It is the answer to, “Please don’t make me learn about this; just tell me what to <i>do</i>.” The “best practice” is a fine idea in spirit, but here’s the thing: many practices labeled “best” don’t deserve the adjective. They’re often containers for bad advice.<br /><br />The most common problem with “best practices” is that they’re not parameterized like they should be. A good practice usually <i>depends</i> on something: <i>if</i> this is true, <i>then</i> do that; <i>otherwise</i>, do this other thing. But most “best practices” don’t come with conditions of execution—they often contain no <i>if</i> statements at all. They come disguised as recipes that can save you time, but they often encourage you to skip past thinking about things that you really ought to be thinking about.<br /><br />Most of my objections to “best practices” go away when the practices being prescribed are actually good. But the ones I see are often not, like the old SQL “avoid full-table scans” advice. Enforcing practices like this yields applications that don’t run as well as they should and developers that don’t learn the things they should. Practices like “Measure the efficiency of your SQL at every phase of the software life cycle,” are actually “best”-worthy, but alas, they’re less popular because they sound like real work.Cary Millsaphttp://www.blogger.com/profile/16697498718050285274noreply@blogger.com4tag:blogger.com,1999:blog-2954359812249072053.post-59225482263398469442017-07-27T09:51:00.001-07:002017-07-27T09:51:32.017-07:00Words I Don’t Use, Part 2: “Holistic”The second “word I do not use” is <i>holistic</i>.<br /><br />When people use the word “holistic” in my industry (Oracle), it means that they’re paying attention to not just an individual subcomponent of a system, but to a whole system, including (I hope) even the people it serves.<br /><br />But trying to differentiate technology services by saying “we take a holistic view of your system” is about like differentiating myself by saying I’ll wear clothes to work. Saying “holistic” would make it look like I’ve only just recently become aware that optimizing a system’s individual subsystems is not a reliable way to optimize the system itself.&nbsp;<i>This</i> should not be a distinctive revelation.Cary Millsaphttp://www.blogger.com/profile/16697498718050285274noreply@blogger.com1tag:blogger.com,1999:blog-2954359812249072053.post-16630396976158322422017-07-21T10:58:00.000-07:002017-07-21T10:58:03.787-07:00Words I Don’t Use, Part 1: “Methodology”Today, I will begin a brief sequence of blog posts that I’ll call “Words I Don’t Use.” I hope you’ll have some fun with it, and maybe find a thought or two worth considering.<br /><br /><a href="http://www.cafepress.com/mf/95125254/method-not-methodology_tshirt?productId=1450646280" target="_blank"><img border="0" data-original-height="762" data-original-width="642" height="320" src="https://3.bp.blogspot.com/-BX0Ni9GsPT4/WXI0mZ4FIqI/AAAAAAAACP4/bcc6D_GZirUMRXAORQds-EAqvcTvdT11ACLcBGAs/s320/2017-07-21_12-05-28.png" style="float: right;" width="269" /></a>The first word I’ll discuss is <i>methodology</i>. <a href="http://www.cafepress.com/mf/95125254/method-not-methodology_tshirt?productId=1450646280" target="_blank">Yes. I made a shirt about it.</a><br /><br />Approximately 100% of the time in the [mostly non-scientific] Oracle world that I live in, when people say “methodology,” they’re using it in the form that <a href="https://books.google.com/books?id=xb6ie6PqYhwC&amp;lpg=PA299&amp;ots=25Yhafdrlb&amp;dq=american%20heritage%20methodology%20pretentious%20substitute&amp;pg=PA299#v=onepage&amp;q=american%20heritage%20methodology%20pretentious%20substitute&amp;f=false" target="_blank"><i>American Heritage</i> describes as a pretentious substitute for “method.”</a> But methodology is not the same as method. <i>Methods</i> are processes. Sequences of steps. <i>Methodology</i> is the scientific study of methods.<br /><br />I like this article called <a href="https://organizationsandmarkets.com/2007/04/07/method-versus-methodology/" target="_blank">“Method versus Methodology” by Peter Klein</a>, which cites the same <i>American Heritage Dictionary</i> passage that I quoted on page 358 of <i><a href="http://amzn.to/173bpzg" target="_blank">Optimizing Oracle Performance</a></i>.Cary Millsaphttp://www.blogger.com/profile/16697498718050285274noreply@blogger.com6tag:blogger.com,1999:blog-2954359812249072053.post-46084457373583917792016-05-19T12:51:00.000-07:002017-08-07T14:28:59.830-07:00Messed-Up App of the Day: Tables of NumbersQuick, which database is the biggest space consumer on this system?<br /><pre>Database Total Size Total Storage<br />-------------------- --------------- ---------------<br />SAD99PS 635.53 GB 1.24 TB<br />ANGLL 9.15 TB 18.3 TB<br />FRI_W1 2.14 TB 4.29 TB<br />DEMO 6.62 TB 13.24 TB<br />H111D16 7.81 TB 15.63 TB<br />HAANT 1.1 TB 2.2 TB<br />FSU 7.41 TB 14.81 TB<br />BYNANK 2.69 TB 5.38 TB<br />HDMI7 237.68 GB 476.12 GB<br />SXXZPP 598.49 GB 1.17 TB<br />TPAA 1.71 TB 3.43 TB<br />MAISTERS 823.96 GB 1.61 TB<br />p17gv_data01.dbf 800.0 GB 1.56 TB</pre>It’s harder than it looks.<br /><br />Did you come up with ANGLL? If you didn’t, then you should look again. If you did, then what steps did you have to execute to find the answer?<br /><br />I’m guessing you did something like I did:<br /><ol><li>Skim the entire list. Notice that HDMI7 has a really big value in the third column.</li><li>Read the column headings. Parse the difference in meaning between “size” and “storage.” Realize that the “storage” column is where the answer to a question about space consumption will lie.</li><li>Skim the “Total Storage” column again and notice that the wide “476.12” number I found previously has a GB label beside it, while all the other labels are TB.</li><li>Skim the table again to make sure there’s no PB in there.</li><li>Do a little arithmetic in my head to realize that a TB is 1000× bigger than a GB, so 476.12 is probably not the biggest number after all, in spite of how big it looked.</li><li>Re-skim the “Total Storage” column looking for big TB numbers.</li><li>The biggest-looking TB number is 15.63 on the H111D16 row.</li><li>Notice the trap on the ANGLL row that there are only three significant digits showing in the “18.3” figure, which looks physically the same size as the three-digit figures “1.24” and “4.29” directly above and below it, but realize that 18.3 (which should have been rendered “18.30”) is an order of magnitude larger.</li><li>Skim the column again to make sure I’m not missing another such number.</li><li>The answer is ANGLL.</li></ol>That’s a lot of work. Every reader who uses this table to answer that question has to do it.<br /><br />Rendering the table differently makes your readers’ (plural!) job much easier:<br /><pre>Database Size (TB) Storage (TB)<br />---------------- --------- ------------<br />SAD99PS .64 1.24<br />ANGLL 9.15 18.30<br />FRI_W1 2.14 4.29<br />DEMO 6.62 13.24<br />H111D16 7.81 15.63<br />HAANT 1.10 2.20<br />FSU 7.41 14.81<br />BYNANK 2.69 5.38<br />HDMI7 .24 .48<br />SXXZPP .60 1.17<br />TPAA 1.71 3.43<br />MAISTERS .82 1.61<br />p17gv_data01.dbf .80 1.56</pre>This table obeys an important design principle:<br /><blockquote class="tr_bq"><b>The <a href="https://en.wikipedia.org/wiki/Edward_Tufte">amount of ink</a> it takes to render each number is proportional to its relative magnitude</b>.</blockquote>I fixed two problems: (i)&nbsp;now all the units are consistent (I have guaranteed this feature by adding unit label to the header and deleting all labels from the rows); and (ii)&nbsp;I’m showing the same number of significant digits for each number. Now, you don’t have to do arithmetic in your head, and now you can see more easily that the answer is ANGLL, at 18.30&nbsp;TB.<br /><br />Let’s go one step further and finish the deal. If you really want to make it as easy as possible for readers to understand your space consumption problem, then you should sort the data, too:<br /><pre>Database Size (TB) Storage (TB)<br />---------------- --------- ------------<br />ANGLL 9.15 18.30<br />H111D16 7.81 15.63<br />FSU 7.41 14.81<br />DEMO 6.62 13.24<br />BYNANK 2.69 5.38<br />FRI_W1 2.14 4.29<br />TPAA 1.71 3.43<br />HAANT 1.10 2.20<br />MAISTERS .82 1.61<br />p17gv_data01.dbf .80 1.56<br />SAD99PS .64 1.24<br />SXXZPP .60 1.17<br />HDMI7 .24 .48</pre>Now, your answer comes in a glance. Think back at the comprehension steps that I described above. With the table here, you only need:<br /><ol><li>Notice that the table is sorted in descending numerical order.</li><li>Comprehend the column headings.</li><li>The answer is ANGLL.</li></ol>As a reader, you have executed <i>far</i>&nbsp;less code path in your brain to completely comprehend the data that the author wants you to understand.<br /><br />Good design is a topic of consideration. And even <i>conservation</i>. If spending 10 extra minutes formatting your data better saves 1,000 readers 2 minutes each, then you’ve saved the world 1,990 minutes of wasted effort.<br /><br />But good design is also a very practical matter for you personally, too. If you want your audience to understand your work, then make your information easier for them to consume—whether you’re writing email, proposals, reports, infographics, slides, or software. It’s part of the pathway to being more persuasive.<br /><br />Cary Millsaphttp://www.blogger.com/profile/16697498718050285274noreply@blogger.com1tag:blogger.com,1999:blog-2954359812249072053.post-34792943588177405632016-05-13T15:22:00.001-07:002016-05-13T15:22:33.202-07:00Fail FastAmong movements like <a href="https://en.wikipedia.org/wiki/Agile_software_development">Agile</a>, <a href="https://en.wikipedia.org/wiki/Lean_startup">Lean Startup</a>, and <a href="https://en.wikipedia.org/wiki/Design_thinking">Design Thinking</a> these days, you hear the term <em>fail fast</em>. The principle of <em>failing fast</em> is vital to efficiency, but I’ve seen project managers and business partners be offended or even agitated by the term <em>fail fast</em>. I’ve seen it come out like, “Why the hell would I want to <em>fail fast</em>?! I don’t want to fail <em>at all</em>.” The implication, of course: “Failing is for losers. If you’re planning to fail, then I don’t want you on my team.”<br /><br />I think I can help explain why the principle of “fail fast” is so important, and maybe I can help you explain it, too.<br /><br />Software developers know about <em>fail fast</em> already, whether they realize it or not. Yesterday was a prime example for me. It was a really long day. I didn’t leave my office until after 9pm, and then I turned my laptop back on as soon as I got home to work another three hours. I had been fighting a bug all afternoon. It was a program that ran about 90 seconds normally, but when I tried a code path that should have been much faster, I could let it run 50&nbsp;times that long and it <em>still</em> wouldn’t finish.<br /><br />At home, I ran it again and left it running while I watched the <a href="http://www.nba.com/games/20160512/SASOKC/gameinfo.html?ls=eref:google:1b:post">Thunder beat the Spurs</a>, assuming the program would finish eventually, so I could see the log file (which we’re not flushing often enough, which is another problem). My MacBook Pro ran so hard that the fan compelled my son to ask me why my laptop was suddenly so loud. I was wishing the whole time, “I wish this thing would fail faster.” And there it is.<br /><br />When you know your code is destined to fail, you want it to fail <em>faster</em>. Debugging is hard enough as it is, without your stupid code forcing you to wait an hour just to see your log file, so you might gain an idea of what you need to go fix. If I could fail faster, I could fix my problem earlier, get more work done, and ship my improvements sooner.<br /><br />But how does that relate to wanting my <em>business idea</em> to fail faster? Well, imagine that a given business idea is in fact destined to fail. When would you rather find out? (a)&nbsp;In a week, before you invest millions of dollars and thousands of hours investing into the idea? Or (b)&nbsp;In a year, after you’ve invested millions of dollars and thousands of hours?<br /><br />I’ll take option (a) a million times out of a million. It’s like asking if I’d like a crystal ball. Um, <em>yes</em>.<br /><br />The operative principle here is “destined to fail.” When I’m fixing a reported bug, I know that once I create reproducible test case for that bug, my software will fail. It is <em>destined to fail</em> on that test case. So, of course, I want for my process of creating the reproducible test case, my software build process, and my program execution itself to all happen as fast as possible. Even better, I wish I had come up with the reproducible test case a year or two ago, so I wouldn’t be under so much pressure <em>now</em>. Because seeing the failure earlier—<em>failing fast</em>—will help me improve my product earlier.<br /><br />But back to that business idea... Why would you want a business idea to <em>fail fast</em>? Why would you want it to fail at all? Well, of course, you don’t want it to fail, but it doesn’t matter what you want. What if it is <em>destined</em> to fail? It’s really important for you to <i>know</i> that. So how can you know?<br /><br />Here’s a little trick I can teach you. Your business idea <em>is</em> destined to fail. It is. No matter how awesome your idea is, if you implement your current vision of some non-trivial business idea that will take you, say, a month or more to implement, not refining or evolving your original idea at all, your idea will fail. It will. Seriously. If your brain won’t permit you to conceive of this as a possibility, then your brain is actually increasing the probability that your idea will fail. <br /><br />You need to figure out <em>what will make your idea fail</em>. If you can’t find it, then find smart people who can. Then, don’t fear it. Don’t try to pretend that it’s not there. Don’t work for a year on the easy parts of your idea, delaying the inevitable hard stuff, hoping and praying that the hard stuff will work its way out. Attack that hard stuff first. That takes courage, but you need to do it.<br /><br />Find your worst bottleneck, and make it your highest priority. If you cannot solve your idea’s worst problem, then get a new idea. You’ll do yourself a favor by killing a bad idea before it kills you. If you solve your worst problem, then find the next one. Iterate. Shorter iterations are better. You’re done when you’ve proven that your idea actually works. In reality. And then, because life keeps moving, you have to keep iterating.<br /><br />That’s what <em>fail fast</em> means. It’s about shortening your feedback loop. It’s about learning the most you can about the most important things you need to know, as soon as possible.<br /><br />So, when I wish you <em>fail fast</em>, it’s a blessing; not a curse.Cary Millsaphttp://www.blogger.com/profile/16697498718050285274noreply@blogger.com2tag:blogger.com,1999:blog-2954359812249072053.post-48813971881969079712016-03-07T12:16:00.000-08:002016-03-07T12:16:09.449-08:00Loss Aversion and the Setting of DB_BLOCK_CHECKSUMWithin <a href="https://www.enkitec.com/">Accenture Enkitec Group,</a> we have recently been discussing the Oracle <i>db_block_checksum</i> parameter and how difficult it is to get clients to set it to a safer setting.<br /><br />Clients are always concerned about the performance impact of features like this. Several years ago, I met a lot of people who had—in response to some expensive advice with which I strongly disagreed—turned off redo logging with an underscore parameter. The performance they would get from doing this would set the expectation level in their mind, which would cause them to resist (strenuously!) any notion of switching this [now horribly expensive] logging back on. Of course, it makes you wish that it had never even been a parameter.<br /><br />I believe that the right analysis&nbsp;is to think clearly about <i>risk</i>. Risk is a non-technical word in most people’s minds, but in finance courses they teach that risk is quantifiable as a probability distribution. For example, you can calculate the probability that a disk will go bad in your system today. For disks, it’s not too difficult, because vendors do those calculations (MTTF) for us. But the probability that you’ll wish you had set <i>db_block_checksum=full</i> yesterday is probably more difficult to compute.<br /><br />From a psychology perspective, customers would be happier if their systems had <i>db_block_checksum</i> set to <i>full</i> or <i>typical</i> to begin with. Then in response to the question,<br /><blockquote class="tr_bq">“Would you like to remove your safety net in exchange for going between 1% and 10% faster? Here’s the horror you might face if you do it...”</blockquote>...I’d wager that most people would say no, thank you. They will react emotionally to the idea of their safety net being taken away.<br /><br />But with the baseline of its being turned off to begin with, the question is,<br /><blockquote class="tr_bq">“Would you like to install a safety net in exchange for slowing your system down between 1% and 10%? Here’s the horror you might face if you don’t...”</blockquote>...I’d wager that most people would answer no, thank you, even though this verdict that is opposite to the one I predicted above. They will react emotionally to the idea of their performance being taken away.<br /><br />Most people have a strong propensity toward <a href="https://en.wikipedia.org/wiki/Loss_aversion">loss aversion</a>. They tend to prefer avoiding losses over acquiring gains. If they already have a safety net, they won’t want to lose it. If they don’t have the safety net they need, they’ll feel averse to losing performance to get one. It ends up being a problem more about psychology than technology.<br /><br />The only tools I know to help people make the right decision are:<br /><ol><li>Talk to good salespeople about how they overcome the psychology issue. They have to deal with it every day.</li><li>Give concrete evidence. Compute the probabilities. Tell the stories of how bad it is to&nbsp;have insufficient protection. Explain that any software feature that provides a benefit is going to cost some system capacity (just like a new report, for example), and that this safety feature is worth the cost. Make sure that when you size systems, you include the incremental capacity cost of switching to <i>db_block_checksum=full</i>.</li></ol>My teammates get it, of course, because they’ve lived the stories, over and over again, in their roles on the corruption team at Oracle Support. You can get it, too, without leaving your keyboard. If you want to see <a href="https://davidloinaz.wordpress.com/2016/02/24/db_block_checksum-and-risk-perception/">a fantastic and absolutely horrifying short story about what happens if you do not use Oracle’s <i>db_block_checksum</i> feature properly, read David Loinaz’s article</a> now.<br /><br />When you read <a href="https://davidloinaz.wordpress.com/2016/02/24/db_block_checksum-and-risk-perception/">David’s article</a>, you are going to see heavy quoting of my post here in his intro. He did that with my full support. (He wrote his article when my article here wasn’t an article yet.) If you feel like you’ve read it before, just keep reading. You really, really need to see what David has written, beginning with the question:<br /><blockquote class="tr_bq"><a href="https://davidloinaz.wordpress.com/2016/02/24/db_block_checksum-and-risk-perception/">If I’ve never faced a corruption, and I have good backup strategy, my disks are mirrored, and I have a great database backup strategy, then why do I need to set these kinds of parameters that will impact my performance?</a></blockquote>Enjoy.Cary Millsaphttp://www.blogger.com/profile/16697498718050285274noreply@blogger.com1tag:blogger.com,1999:blog-2954359812249072053.post-16810911682295458842016-01-08T12:21:00.000-08:002016-01-08T21:13:48.337-08:00The “Two Spaces After a Period” ThingOnce upon a time, I told my friend <a href="http://www.oraclenerd.com/">Chet Justice</a> why he should start using one space instead of two after a sentence-ending period. I’m glad I did.<br /><br />Here’s the story.<br /><br />When you type, you’re inputting data into a machine. I know you like feeling like you’re in charge, but really you’re not in charge of all the rules you have to follow while you’re inputting your data. Other people—like the designers of the machine you’re using—have made certain rules that you have to live by. For example, if you’re using a QWERTY keyboard, then the ‘A’ key is in a certain location on the keyboard, and whether it makes any sense to you or not, the ‘B’ key is way over there, not next to the ‘A’ key like you might have expected when you first started learning how to type. If you want a ‘B’ to appear in the input, then you have to reach over there and push the ‘B’ key on the keyboard.<br /><br />In addition to the rules imposed upon you by the designers of the machine you’re using, you follow other rules, too. If you’re writing a computer program, then you have to follow the syntax rules of the language you’re using. There are alphabet and spelling and grammar rules for writing in German, and different ones for English. There are typographical rules for writing for <a href="http://www.newyorker.com/">The New Yorker</a>, and different ones for the <a href="http://www.ams.org/home/page">American Mathematical Society</a>.<br /><br />A lot of people who are over about 40&nbsp;years old today learned to type on an actual typewriter. A typewriter is a machine that used rods and springs and other mechanical elements to press metal dies with backwards letter shapes engraved onto them through an inked ribbon onto a piece of paper. Some of the rules that governed the data input experience on typewriters included:<br /><ul><li>You had to learn where the keys were on the keyboard.</li><li>You had to learn how to physically return the carriage at the end of a line.</li><li>You had to learn your project’s rules of spelling.</li><li>You had to learn your project’s rules of grammar.</li><li>You had to learn your project’s rules of typography.</li></ul>The first two rules listed here are physical, but the final three are syntactic and semantic. Just like you wouldn’t press the ‘A’ key to make a ‘B’, you wouldn’t use the strings “definately” or “we was” to make an English sentence.<br /><br />On your typewriter, you might not have realized it, but you did adhere to some typography rules. They might have included:<br /><ul><li>Use two carriage returns after a paragraph.</li><li>Type two spaces after a sentence-ending period.</li><li>Type two spaces after a colon.</li><li>Use two consecutive hyphens to represent an em dash.</li><li>Make paragraphs no more than 80 characters wide.</li><li>Never use a carriage return between “Mr.” and the proper name that follows, or between a number and its unit.</li></ul>The rules were different for different situations. For example, when I wrote a book back in the mid 1980s, one of the distinctive typography rules my publisher imposed upon me was:<br /><ul><li>Double-space all paragraph text.</li></ul>They wanted their authors to do this so that their copyeditor had plenty of room for <a href="http://biostatmatt.com/uploads/ProofreadSymbols.pdf">markup</a>. Such typography rules can vary from one project to another.<br /><br />Most people who didn’t write for different publishers got by just fine on the one set of typography rules they learned in high school. To them, it looked like there were only a few simple rules, and only one set of them. Most people had never even heard of a lot of the rules they should have been following, like <a href="http://www.fonts.com/content/learning/fontology/level-2/text-typography/rags-widows-orphans">rules about widows and orphans</a>.<br /><br />In the early 1980s, I began using computers for most of my work. I can remember learning how to use word processing programs like <a href="https://en.wikipedia.org/wiki/WordStar">WordStar</a> and&nbsp;<a href="https://en.wikipedia.org/wiki/Sprint_(word_processor)">Sprint</a>. The rules were a lot more complicated with word processors. Now there were rules about “control keys” like ^X and ^Y, and there were no-break spaces and styles and leading and kerning and ligatures and all sorts of new things I had never had to think about before. A word processor was much more powerful than a typewriter. If you did it right, typesetting could could make your work look like a real book. But word processors revealed that typesetting was way more complicated than just typing.<br /><br />Doing your own typesetting can be kind of like doing your own oil changes. Most people prefer to just put gas in the tank and not think too much about the esoteric features of their car (like their tires or their turn signal indicators). Most people who went from typewriters to word processors just wanted to type like they always had, using the good-old two or three rules of typography that had been long inserted into their brains by their high school teachers and then committed by decades of repetition.<br /><br />Donald Knuth published <i><a href="http://amzn.to/1OgAbSY">The TeXBook</a></i> in&nbsp;1984. I think I bought it about ten minutes after it was published. Oh, I loved that book. Using TeX was my first real exposure to the world of actual professional-grade typography, and I have enjoyed thinking about typography ever since. I practice typography&nbsp;every day that I use <a href="https://en.wikipedia.org/wiki/Keynote_(presentation_software)">Keynote</a> or&nbsp;<a href="https://en.wikipedia.org/wiki/Pages_(word_processor)">Pages</a> or <a href="https://en.wikipedia.org/wiki/Adobe_InDesign">InDesign</a> to do my work.<br /><br />Many people don’t realize it, but when you type input into programs like Microsoft Word should follow typography rules including these:<br /><ul><li>Never enter a blank line (edit your paragraph’s style to manipulate its spacing).</li><li>Use a single space after a sentence-ending period (the typesetter software you’re using will make the amount of space look right as it composes the paragraph).</li><li>Use a non-breaking space after a non-sentence-ending period (so the typesetter software won’t break “Mr.&nbsp;Harkey” across lines).</li><li>Use a non-breaking space between a number and its unit (so the typesetter software won’t break “8&nbsp;oz” across lines).</li><li>Use an en dash—not a hyphen—to specify ranges of numbers (like “3–8”).</li><li>Use an em dash—not a pair of hyphens—when you need an em dash (like in this sentence).</li><li>Use proper quotation marks, like “this” and ‘this’ (or even « this »).</li></ul>Of course, you can choose to not follow these rules, just like you can choose to be willfully ignorant about spelling or grammar. But to a reader who has studied typography even just a little bit, seeing you break these rules feels the same as seeing a sentence like, “You was suppose to use apostrophe's.” It affects how people perceive you.<br /><br />So, it’s always funny to me when people get into heated arguments on Facebook about using one space or two after a period. It’s the tiniest little tip of the typography iceberg, but it opens the conversation about typography, for which I’m glad. In these discussions, two questions come up repeatedly: “When did the rule change? Why?”<br /><br />Well, the rule never did change. The next time I type on an actual typewriter, I will use two spaces after each sentence-ending period. I will also use two spaces when I create a Courier font court document or something that I want to look like it was created in the&nbsp;1930s. But when I work on <a href="http://method-r.com/">my book</a> in Adobe InDesign, I’ll use one space. When I use my iPhone, I’ll tap in two spaces at the end of a sentence, because it automatically replaces them with a period and a single space. I adapt to the rules that govern the situation I’m in.<br /><br />It’s not that the rules have changed. It’s that the set of rules was always a lot bigger than most people ever knew.Cary Millsaphttp://www.blogger.com/profile/16697498718050285274noreply@blogger.com10tag:blogger.com,1999:blog-2954359812249072053.post-8050761589162165242015-10-01T15:23:00.000-07:002015-10-28T14:50:10.343-07:00What I Wanted to Tell Terry BradshawI met&nbsp;<a href="https://en.wikipedia.org/wiki/Terry_Bradshaw">Terry Bradshaw</a>&nbsp;one time. It was about ten years ago, in front of a movie theater near where I live.<br /><br />When I was little, Terry Bradshaw was my enemy because, unforgivably to a young boy,&nbsp;he and his Pittsburgh Steelers <a href="https://en.wikipedia.org/wiki/Cowboys%E2%80%93Steelers_rivalry">kept beating</a> my beloved Dallas Cowboys in Super Bowls. As I grew up, though, his personality on TV talk shows won me over, and I enjoy watching him to this day on <a href="https://en.wikipedia.org/wiki/Fox_NFL_Sunday">Fox NFL Sunday</a>. After learning a little bit about his life, I’ve grown to really&nbsp;admire and respect him.<br /><br />I had heard that he owned a ranch not too far from where I live, and so I had it in mind that inevitably I would meet him someday, and I would say thank you. One day I had that chance.<br /><br />I completely blew it.<br /><br />My wife and I saw him there at the theater one day, standing by himself not far from us. It seemed like if I were to walk over and say hi, maybe it wouldn’t bother him. So I walked over, a little bit nervous. I shook his hand, and I said, “Mr. Bradshaw, hi, my name is Cary.” I would then say this:<br /><br /><blockquote>I was a big Roger Staubach fan growing up. I watched Cowboys vs. Steelers like I was watching Good vs. Evil. <br /><br />But as I’ve grown up, I have gained the deepest admiration and respect for you. You were a tremendous competitor, and you’re one of my favorite people to see on TV. Every time I see you, you bring a smile to my face. You’ve brought joy to a lot of people.<br /><br />I just wanted to say thank you.</blockquote><br />Yep, that’s what I would say to Terry Bradshaw if I got the chance. But that’s not how it would turn out. How it actually went was like this, …my big chance:<br /><br /><blockquote>Me: I was a big Roger Staubach fan growing up.<br />TB: Hey, so was I!<br />Me: (stunned)<br />TB: (turns away)<br /><i>The End</i></blockquote><br />I was heartbroken. It bothers me still today. If you know Terry Bradshaw or someone who does, I wish you would please let him know. It would mean a lot to me.<br /><br />…I did learn something that day about <a href="https://en.wikipedia.org/wiki/Elevator_pitch">the elevator pitch</a>.Cary Millsaphttp://www.blogger.com/profile/16697498718050285274noreply@blogger.com1tag:blogger.com,1999:blog-2954359812249072053.post-54738037331324954152015-09-17T09:46:00.000-07:002016-06-08T14:00:36.312-07:00The Fundamental Challenge of Computer System PerformanceThe fundamental challenge of computer system performance is <b>for your system to have enough power to handle the work you ask it to do.</b> It sounds really simple, but helping people meet this challenge has been the point of my whole career. It has kept me busy for 26&nbsp;years, and there’s no end in sight.<br /><h2>Capacity and Workload</h2>Our challenge is the relationship between a computer’s <i>capacity</i> and its <i>workload</i>. I think of capacity as an empty box representing a machine’s ability to do work over time. <i>Workload</i> is the work your computer does, in the form of programs that it runs for you, executed over time. Workload is the content that can fill the capacity box.<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-gSIZhbWA2k8/VfiXd5KOgwI/AAAAAAAACBU/jt8i8LWexl8/s1600/capacity.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="236" src="https://1.bp.blogspot.com/-gSIZhbWA2k8/VfiXd5KOgwI/AAAAAAAACBU/jt8i8LWexl8/s320/capacity.png" style="border: 0;" width="320" /></a></div><br /><h2>Capacity Is the One You Can Control, Right?</h2>When the workload gets too close to filling the box, what do you do? Most people’s instinctive reaction is that, well, we need a bigger box. Slow system? Just add power. It sounds so simple, especially since—as “everyone knows”—computers get faster and cheaper every year. We call that the <i>KIWI</i> response: <i>kill it with iron.</i><br /><h2>KIWI... Why Not?</h2>As welcome as KIWI may feel, KIWI is expensive, and it doesn’t always work. Maybe you don’t have the budget right now to upgrade to a new machine. Upgrades cost more than just the hardware itself: there’s the time and money it takes to set it up, test it, and migrate your applications to it. Your software may cost more to run on faster hardware. What if your system is already the biggest and fastest one they make?<br /><br />And as weird as it may sound, upgrading to a more powerful computer doesn’t always make your programs run faster. There are classes of performance problems that adding capacity <i>never</i> solves. (Yes, it is possible to predict when that will happen.) KIWI is not always a viable answer.<br /><h2>So, What Can You Do?</h2>Performance is not just about capacity. Though many people overlook them, there are solutions on the <i>workload</i> side of the ledger, too. What if you could make workload smaller without compromising the value of your system?<br /><blockquote>It is usually possible to make a computer produce all of the useful <i>results</i> that you need without having to do as much <i>work</i>.</blockquote>You might be able to make a system run faster by making its capacity box bigger. But you might also make it run faster by trimming down that big red workload inside your existing box. If you only trim off the wasteful stuff, then nobody gets hurt, and you’ll have winning all around.<br /><br />So, <i>how</i> might one go about doing that?<br /><h2>Workload</h2>“Workload” is a conjunction of two words. It is useful to think about those two words separately.<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-5OAGa5GeK6U/Vfm9hg5siuI/AAAAAAAACBs/3idfbUIpw44/s1600/workload.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://1.bp.blogspot.com/-5OAGa5GeK6U/Vfm9hg5siuI/AAAAAAAACBs/3idfbUIpw44/s1600/workload.png" style="border: 0;" /></a></div><br />The amount of <i>work</i> your system does for a given program execution is determined mostly by how that program is written. <a href="https://en.wikipedia.org/wiki/Program_optimization">A lot of programs make their systems do more work than they should</a>. Your <i>load</i>, on the other hand—the number of program executions people request—is determined mostly by your users. Users can waste system capacity, too; for example, by running reports that nobody ever reads.<br /><br />Both work and load are variables that, with skill, you can manipulate to your benefit. You do it by improving the code in your programs (reducing work), or by improving your business processes (reducing load). I like workload optimizations because they usually save money and work better than capacity increases. Workload optimization can seem like magic.<br /><h2>The Anatomy of Performance</h2>This simple equation explains why a program consumes the time it does:<br /><blockquote><var>r</var> = <var>cl</var>&nbsp; &nbsp; &nbsp; &nbsp; or&nbsp; &nbsp; &nbsp; &nbsp; <var>response time</var> = <var>call count</var> × <var>call latency</var></blockquote>Think of a <i>call</i> as a computer instruction. <i>Call count</i>, then, is the number of instructions that your system executes when you run a program, and <i>call latency</i> is how long each instruction takes. How long you wait for your answer, then—your <i>response time</i>—is the product of your call count and your call latency.<br /><br /><div style="font-size: 7pt; margin-left: 3em; margin-right: 3em;"><i>Some fine print:</i> It’s really a little more complicated than this, but actually not that much. Most response times are composed of many different types of calls, all of which have different latencies (we see these in <a href="http://method-r.com/software/profiler">program execution profiles</a>), so the real equation looks like <var>r</var> = <var>c</var><sub>1</sub><var>l</var><sub>1</sub> + <var>c</var><sub>2</sub><var>l</var><sub>2</sub> + ... + <var>c<sub>n</sub>l<sub>n</sub></var>. But we’ll be fine with <var>r</var> = <var>c</var><var>l</var> for this article.</div><br /><i>Call count</i> depends on two things: how the code is written, and how often people run that code.<br /><ul><li><i>How the code is written (work)</i> — If you were programming a robot to shop for you at the grocery store, you could program it to make one trip from home for each item you purchase. Go get bacon. Come home. Go get milk... It would probably be dumb if you did it that way, because the duration of your shopping experience would be dominated by the execution of clearly unnecessary travel instructions, but you’d be surprised at how often people write programs that act like this.</li><li><i>How often people run that code (load)</i> — If you wanted your grocery store robot to buy 42&nbsp;things for you, it would have to execute more instructions than if you wanted to buy only&nbsp;7. If you found yourself repeatedly discarding spoiled, unused food, you might be able to reduce the number of things you shop for without compromising anything you really need.</li></ul><i>Call latency</i> is influenced by two types of delays: queueing delays and coherency delays.<br /><ul><li><i>Queueing delays</i> — Whenever you request a resource that is already busy servicing other requests, you wait in line. That’s a queueing delay. It’s what happens when your robot tries to drive to the grocery store, but all the roads are clogged with robots that are going to the store to buy one item at a time. Driving to the store takes only 7&nbsp;minutes, but waiting in traffic costs you another 13&nbsp;minutes. The more work your robot does, the greater its chances of being delayed by queueing, and the more such delays your robot will inflict upon others as well.</li><li><i>Coherency delays</i> — You endure a coherency delay whenever a resource you are using needs to communicate or coordinate with another resource. For example, if your robot’s cashier at the store has to talk with a specific manager or other cashier (who might already be busy with a customer), the checkout process will take longer. The more times your robot goes to the store, the worse your wait will be, and everyone else’s, too.</li></ul><h2>The Secret</h2>This <var>r</var> = <var>cl</var> thing sure looks like the equation for a line, but because of queueing and coherency delays, the value of&nbsp;<var>l</var> increases when <var>c</var> increases. This causes response time to act <i>not</i> like a line, but instead like a hyperbola.<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="https://1.bp.blogspot.com/--rlnJHiZLxY/V1iHYYhO2YI/AAAAAAAACJw/nbVhRVjWxzoyibnLe5WsgDKaAGwTvil8ACLcB/s1600/r%253Dcl.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="260" src="https://1.bp.blogspot.com/--rlnJHiZLxY/V1iHYYhO2YI/AAAAAAAACJw/nbVhRVjWxzoyibnLe5WsgDKaAGwTvil8ACLcB/s320/r%253Dcl.png" width="320" /></a></div><div class="separator" style="clear: both; text-align: center;"></div><div class="separator" style="clear: both; text-align: center;"></div><br />Because <a href="http://www.amazon.com/gp/product/0201479486/ref=as_li_tl?ie=UTF8&amp;camp=1789&amp;creative=9325&amp;creativeASIN=0201479486&amp;linkCode=as2&amp;tag=methodrcom-20&amp;linkId=HPUTBI5W6TFV3VF2">our brains tend to conceive of our world as linear</a>, nobody expects for everyone’s response times to get seven times worse when you’ve only added some new little bit of workload, but that’s the kind of thing that routinely happens with performance. ...And not just computer performance. Banks, highways, restaurants, amusement parks, and grocery-shopping robots all work the same way.<br /><br />Response times are trememdously sensitive to your call counts, so <b>the secret to great performance is to keep your call counts small.</b> This principle is the basis for perhaps the best and most famous performance optimization advice ever rendered:<br /><blockquote>The First Rule of Program Optimization: Don’t do it.<br /><br />The Second Rule of Program Optimization (for experts only!): Don’t do it yet.<br /><br /><div style="text-align: right;">— <a href="https://en.wikipedia.org/wiki/Michael_A._Jackson" title="Michael A. Jackson">Michael A. Jackson</a></div></blockquote><h2>The Problem</h2>Keeping call counts small is really, really important. This makes being a vendor of information services difficult, because it is <i>so easy</i> for application users to make call counts grow. They can do it by running more programs, by adding more users, by adding new features or reports, or by even by just the routine process of adding more data every day.<br /><br />Running your application with other applications on the same computer complicates the problem. What happens when all these application’ peak workloads overlap? It is a problem that <a href="https://en.wikipedia.org/wiki/Application_service_provider">Application Service Providers (ASPs)</a>, <a href="https://en.wikipedia.org/wiki/Software_as_a_service">Software as a Service (SaaS)</a> providers, and <a href="https://en.wikipedia.org/wiki/Cloud_computing#Provider">cloud computing</a> providers must solve.<br /><h2>The Solution</h2>The solution is a process:<br /><ol><li>Call counts are sacred. They can be difficult to forecast, so you have to measure them continually. Understand that. Hire people who understand it. Hire people who know how to measure and improve the efficiency of your application programs and the systems they reside on.</li><li>Give your people time to fix inefficiencies in your code. An inexpensive code fix might return many times the benefit of an expensive hardware upgrade. If you have bought your software from a software vendor, work with them to make sure they are streamlining the code they ship you.</li><li>Learn when to say no. Don’t add new features (especially new long-running programs like reports) that are inefficient, that make more calls than necessary. If your users are already creating as much workload as the system can handle, then start prioritizing which workload you will and won’t allow on your system during peak hours.</li><li>If you are an information service provider, charge your customers for the amount of work your systems do for them. The economic incentive to build and buy more efficient programs works wonders.</li></ol>Cary Millsaphttp://www.blogger.com/profile/16697498718050285274noreply@blogger.com6tag:blogger.com,1999:blog-2954359812249072053.post-63999304931060414202015-08-20T15:26:00.003-07:002015-10-01T08:47:42.709-07:00Messed-Up App of the Day: Crux CCH-01WToday’s Messed-Up App of the Day is the “Crux CCH-01W rear-view camera for select 2007-up Jeep Wrangler models.”<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-pXJWPkJsPF8/VdZEArd0TbI/AAAAAAAAB_Y/Pob6K2ti8bY/s1600/CruxCamera.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="http://4.bp.blogspot.com/-pXJWPkJsPF8/VdZEArd0TbI/AAAAAAAAB_Y/Pob6K2ti8bY/s1600/CruxCamera.png" /></a></div><div class="" style="clear: both; text-align: left;">A rear-view camera is an especially good idea in the Jeep Wrangler, because it is very difficult to see behind the vehicle. The rear seat headrests, the wiper motor housing, the spare tire, and the center brake light all conspire to obstruct much of what little view the window had given you to begin with.</div><div class="" style="clear: both; text-align: left;"><br /></div><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-vmrtCKIS5hM/VdZEGVJ4luI/AAAAAAAAB_8/y7Zqslifxc4/s1600/RearView.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="http://2.bp.blogspot.com/-vmrtCKIS5hM/VdZEGVJ4luI/AAAAAAAAB_8/y7Zqslifxc4/s1600/RearView.png" /></a></div><div class="" style="clear: both; text-align: left;">The view is so bad that it’s easy to, for example, accidentally demolish a mailbox.</div><div><br /></div><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-RqNALjlVE10/VdZEFy_n09I/AAAAAAAAB_0/c7QoBb-Uy68/s1600/Mailbox.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="http://4.bp.blogspot.com/-RqNALjlVE10/VdZEFy_n09I/AAAAAAAAB_0/c7QoBb-Uy68/s1600/Mailbox.png" /></a></div><div class="" style="clear: both;">I chose the Crux CCH-01W because it is purpose-built for our 2012 Jeep Wrangler. It snaps right into the license plate frame. I liked that. It had 4.5 out of 5.0 stars in four reviews at <a href="http://crutchfield.com/">crutchfield.com</a>, my favorite place to buy stuff like this. I liked that, too.</div><div class="" style="clear: both;"><br /></div><div class="" style="clear: both;">But I do not like the Crux CCH-01W. I returned it because our Jeep&nbsp;will be safer without this camera than with it. Here’s the story.</div><div class="" style="clear: both;"><br /></div><div class="" style="clear: both;">My installation process was probably pretty normal. I had never done a project like this before, so it took me longer than it should have. Crux doesn’t include any installation instructions with the camera, which is a little frustrating, but I knew that from the reviews. There is a lot of help online, and Crutchfield helped as much as I needed. After all the work of installing it, it was a huge thrill when I first shifted into Reverse and—voilà!—a picture appeared in my dashboard.</div><div class="separator" style="clear: both;"><br /></div><div class="" style="clear: both;">However, that was where the happiness would end. When I tried to <i>use</i> the camera, I noticed right away that the red, yellow, and green grid lines that the camera superimposes upon its picture didn’t make any sense. The grid lines showed that I was going to collide with the vehicle on my left that clearly wasn’t in jeopardy (an inconvenient false negative), and they showed that I was all-clear on the right when in fact I was about to ram into my garage door facing (a dangerous false positive).<br /><br /></div><div class="" style="clear: both;"><a href="https://www.blogger.com/blogger.g?blogID=2954359812249072053" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"></a><a href="https://www.blogger.com/blogger.g?blogID=2954359812249072053" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"></a><a href="https://www.blogger.com/blogger.g?blogID=2954359812249072053" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"></a>The problem is that the grid lines are offset about two feet to the left. Of course, this is because the camera is about two feet to the left of the vehicle’s centerline. It’s above the license plate, below the left-hand tail light.<br /><br /></div><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-4eGerVjl33A/VdZEF8pqpoI/AAAAAAAACAI/BfH-vvndQSc/s1600/LicensePlate.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="http://1.bp.blogspot.com/-4eGerVjl33A/VdZEF8pqpoI/AAAAAAAACAI/BfH-vvndQSc/s1600/LicensePlate.png" /></a></div><div class="" style="clear: both;">So then, to use these grid lines, you have to shift them in your mind about two feet to the right. <i>In your mind.</i> There’s no way to adjust them on the screen. Since this camera is designed exclusively for the left-hand corner of a 2007-up Jeep Wrangler, shouldn’t the designers have adjusted the location of the grid lines to compensate?</div><div class="" style="clear: both;"><br /></div><div class="" style="clear: both;">So, let’s recap. The safety device I bought to <i>relieve</i> driver workload and <i>improve</i> safety will, unfortunately, <i>increase</i> driver workload and <i>degrade</i> safety.</div><div class="" style="clear: both;"><br /></div><div class="" style="clear: both;">That’s bad enough, but it doesn’t end there. There is a far worse problem than just the misalignment of the grid lines.</div><div class="" style="clear: both;"><br /></div><div class="" style="clear: both;">Here is a photo of a my little girl standing a few feet behind the Jeep, directly behind the right rear wheel:<br /><br /></div><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-0gWsRTl6oG0/VdZEFUPdnkI/AAAAAAAAB_4/xBuWoWBjBUw/s1600/GirlRear.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="http://3.bp.blogspot.com/-0gWsRTl6oG0/VdZEFUPdnkI/AAAAAAAAB_4/xBuWoWBjBUw/s1600/GirlRear.png" /></a></div><div class="separator" style="clear: both; text-align: left;">And here is what the camera shows the driver while she is standing there:</div><div class="separator" style="clear: both; text-align: left;"><br /></div><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-Tv19c7bCUyk/VdZEFbyeL-I/AAAAAAAAB_w/ROjNhKsYcLw/s1600/GirlCamera.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="http://3.bp.blogspot.com/-Tv19c7bCUyk/VdZEFbyeL-I/AAAAAAAAB_w/ROjNhKsYcLw/s1600/GirlCamera.png" /></a></div><div class="separator" style="clear: both; text-align: left;">No way am I keeping that camera on the vehicle.</div><div class="separator" style="clear: both;"><br /></div><div class="separator" style="clear: both;">It’s easy to understand why it happens. The camera, which has a 120° viewing angle, is located so far off the vehicle centerline that it creates a blind spot behind the right-hand corner of the vehicle and grid lines that don’t make sense.</div><div class="separator" style="clear: both;"><br /></div><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-t2hIVvGV10o/VdZT5z3eGEI/AAAAAAAACAg/N8ggbmdrGC0/s1600/BlindSpot.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="http://4.bp.blogspot.com/-t2hIVvGV10o/VdZT5z3eGEI/AAAAAAAACAg/N8ggbmdrGC0/s1600/BlindSpot.png" /></a></div><div class="separator" style="clear: both;">The Crux CCH-01W is one of those products that seems like nobody who designed it ever actually had to use it. I think it should never have been released.</div><div class="separator" style="clear: both;"><br /></div><div class="separator" style="clear: both;">As I was shopping for this project, my son and a local professional installer advised me to buy a camera that mounted on the vehicle centerline instead of this one. I didn’t take their advice because the reviews for the CCH-01W were good, and the price was $170 less. Fortunately, Crutchfield has a generous return policy, and the <a href="http://www.crutchfield.com/p_212BM8848/Brandmotion-9002-8848.html">center-mounting 170°-view replacement camera </a>that I’ll install this weekend has arrived today.</div><div class="separator" style="clear: both;"><br /></div><div class="separator" style="clear: both;">I’ve learned a lot. The second installation will go much more quickly than the first.</div><div class="separator" style="clear: both;"><br /></div>Cary Millsaphttp://www.blogger.com/profile/16697498718050285274noreply@blogger.com5tag:blogger.com,1999:blog-2954359812249072053.post-86816619913857930822015-07-29T16:26:00.001-07:002015-09-19T15:11:16.786-07:00I Wish I Sold MoreI flew home yesterday from <a href="http://carymillsap.blogspot.com/2015/07/my-friend-karen.html">Karen’s memorial service</a> in Jacksonville, on a connecting flight through Charlotte. When I landed in Charlotte, I walked with all my stuff from my JAX arrival gate (D7) to my DFW departure gate (B15). The walk was more stressful than usual because the airport was so crowded.<br /><br />The <i>moment</i> I set my stuff down at B15, a passenger with expensive clothes and one of those permanent grins established eye contact, pointed his finger at me, and said, “Are you in First?”<br /><br />Wai... Wha...?<br /><br />I said, “No, platinum.” My first instinct was to explain that I had a right to occupy the space in which I was standing. It bothers me that this was my first instinct.<br /><br />He dropped his pointing finger, and his eyes went no longer interested in me. The big grin diminished slightly.<br /><br />Soon another guy walked up. Same story: the I’m-your-buddy-because-I’m-pointing-my-finger-at-you thing, and then, “First Class?” This time the answer was yes. “ALRIGHT! WHAT ROW ARE YOU IN?” Row two. “AGH,” like he’d been shot in the shoulder. He holstered his pointer finger, the cheery grin became vaguely menacing, and he resumed his stalking.<br /><br />One guy who got the “First Class?” question just stared back. So, big-grin guy asked him again, “Are you in First Class?” No answer. Big-grin guy leaned in a little bit and looked him square in the eye. Still no answer. So he leaned back out, laughed uncomfortably, and said half under his breath, “Really?...”<br /><br />I pieced it together watching this big, loud guy explain to his traveling companions so everybody could hear him, he just wanted to sit in Row&nbsp;1 with his wife, but he had a seat in Row&nbsp;2. And of course it will be so much easier to take care of it <i>now</i> than to wait and take care of it when everybody gets on the plane.<br /><br />Of course.<br /><br />This is the kind of guy who sells things to people. He has probably sold a lot&nbsp;of things to a lot&nbsp;of people. That’s probably why he and his wife have First Class tickets.<br /><br />I’ll tell you, though, I had to battle against hoping he’d hit his head and fall down on the jet bridge (I battled coz it’s not nice to hope stuff like that). I would never have said something to him; I didn’t want to be Other Jackass to his Jackass. (Although people might have clapped if I had.)<br /><br />So there’s this surge of emotions, none of them good, going on in my brain over stupid guy in the airport. Sales reps...<br /><br />This is why <a href="http://method-r.com/">Method&nbsp;R Corporation</a> never had sales reps.<br /><br />But that’s like saying I’ve seen bad aircraft engines before and so now in <i>my</i> airline, I never use aircraft engines. Alrighty then. In that case, I hope you like gliders. And, hey: gliders are fine if that makes you happy. But a glider can’t get me home from Florida. Or even take off by itself.<br /><br />I wish I sold more <a href="http://method-r.com/software">Method&nbsp;R software</a>. But never at the expense of being like the guy at the airport. It seems I’d rather perish than be that guy. This raises an interesting question: is my attitude on this topic just a luxury for me that cheats my family and my employees out of the financial rewards they really deserve? Or do I need to become that guy?<br /><br />I think the answer is not A or B; it’s C.<br /><br />There are also good sales people, people who sell a&nbsp;lot&nbsp;of things to a&nbsp;lot&nbsp;of people, who are nothing like the guy at the airport. People like&nbsp;<a href="http://businessofsoftware.org/speaker/paul-kenny/">Paul Kenny</a>&nbsp;and the honorable, decent, considerate people I work with now at&nbsp;Accenture Enkitec Group who sell through serving others. There were good people selling software at Hotsos, too, but the circumstances of my departure in 2008 prevented me from working with them. (Yes, I do realize: my circumstances would not have prevented me from working with them if I had been more like the guy at the airport.)<br /><br />This need for duality—needing both the person who <i>makes</i>&nbsp;the creations and the person who <i>connects</i> those creations to people who will pay for them—is probably the most essential of <a href="http://www.amazon.com/gp/product/0691158304/ref=as_li_tl?ie=UTF8&amp;camp=1789&amp;creative=9325&amp;creativeASIN=0691158304&amp;linkCode=as2&amp;tag=methodrcom-20&amp;linkId=JLUPHRSAR73PDPUM">the founder’s dilemmas</a>. These two people usually have to be <i>two different people</i>. And both need to be Good.<br /><br />In both senses of the word.Cary Millsaphttp://www.blogger.com/profile/16697498718050285274noreply@blogger.com2tag:blogger.com,1999:blog-2954359812249072053.post-19914550430973056152015-07-29T10:54:00.001-07:002015-09-19T15:11:39.024-07:00My Friend Karen<a href="http://karenmorton.blogspot.com/">My friend Karen Morton</a> passed away on July 23, 2015 after a four-month battle against cancer. <a href="https://vimeo.com/117615858">You can hear her voice here</a>.<br /><br />I met Karen Morton in February 2002. The day I met her, I knew she was awesome. She told me the story that, as a consultant, she had been doing something that was unheard-of. She guaranteed her clients that if she couldn’t make things on their systems go at least X much faster on her very first day, then they wouldn’t have to pay. She was a Give First person, even in her business. That is <i>really</i>&nbsp;hard to do. After she told me this story, I asked the obvious question. She smiled <a href="https://www.enkitec.com/about/bios/karen.morton">her big smile</a> and told me that her clients had <i>always</i> paid her—<i>cheerfully</i>.<br /><br />It was an honor when Karen joined my company just a little while later. She was the best teammate ever, and she delighted every customer she ever met. The times I got to work with Karen were bright spots in my life, during many of the most difficult years of my career. For me, she was a continual source of knowledge, inspiration, and courage.<br /><br />This next part is for Karen’s family and friends outside of work. You know that she was smart, and you know she was successful. What you may not realize is <i>how</i>&nbsp;successful she was. Your girl was famous all over the world. She was literally one of the top experts on Earth at making computing systems run faster. She used her brilliant gift for explaining things through stories to become one of the most interesting and fun presenters in the Oracle world to go watch, and her attendance numbers proved it. Thousands of people all over the world know the name, the voice, and the face of your friend, your daughter, your sister, your spouse, your mom. <br /><br />Everyone loved Karen’s stories. She and I told stories and talked about stories, it seems like, all the time we were together. Stories about how Oracle works, stories about helping people, stories about her college basketball career, stories about our kids and their sports, ... <br /><br />My favorite stories of all—and my family’s too—were the stories about her younger brother Ted. These stories always started out with some middle-of-the-night phone call that Karen would describe in her most somber voice, with the Tennessee accent turned on full-bore: “Kar’n: This is your brother, Theodore LeROY.” Ted was Karen’s brother Teddy Lee when he wasn’t in trouble, so of course he was always Theodore LeROY in her stories.&nbsp;Every story Karen told was funny and kind.<br /><br />We all wanted to have more time with Karen than we got, but she touched and warmed the lives of literally thousands of people. Karen Morton used her half-century here on Earth with us as well as anyone I’ve ever met. She did it right.<br /><br />God bless you, Karen. I love you.Cary Millsaphttp://www.blogger.com/profile/16697498718050285274noreply@blogger.com7tag:blogger.com,1999:blog-2954359812249072053.post-12510157935112859822015-02-27T13:00:00.002-08:002015-09-19T15:14:16.412-07:00What happened to “when the application is fast enough to meet users’ requirements?”On January 5, I received an email called “Video” from my friend and former employee Guđmundur Jósepsson from Iceland. His friends call him Gummi (rhymes with “who-me”). Gummi is the guy whose name is set in the ridiculous monospace font on page xxiv of <a href="http://amzn.to/OM0q75"><i>Optimizing Oracle Performance</i></a>, apparently because O’Reilly’s Linotype Birka font didn’t have <a href="http://en.wikipedia.org/wiki/Eth">the letter eth&nbsp;(đ)</a> in it. Gummi once modestly teased me that this is what he is best known for. But I digress...<br /><br />His email looked like this:<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-L11rF6yVT74/VKqsPBUn7RI/AAAAAAAAB68/-C-M3nMVHz4/s1600/2015-01-05_09-21-43.png" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: 0; margin-right: 1em;"><img border="0" src="http://2.bp.blogspot.com/-L11rF6yVT74/VKqsPBUn7RI/AAAAAAAAB68/-C-M3nMVHz4/s1600/2015-01-05_09-21-43.png" /></a></div><br />It’s a screen shot of frame 3:12 from my November 2014 video called “<a href="http://youtu.be/AHCwwAAW3YA" target="_blank">Why you need a profiler for Oracle</a>.” At frame 3:12, I am answering the question of how you can know when you’re finished optimizing a given application function. Gummi’s question is, «Oi! What happened to “when the application is fast enough to meet users’ requirements?”»<br /><br />Gummi noticed (the good ones will do that) that the video says something different than the thing he had heard me say for years. It’s a fair question. Why, in the video, have I said this new thing? It was not an accident.<br /><h2>When are you finished optimizing?</h2>The question in focus is, “When are you finished optimizing?” Since 2003, I have actually used <em>three</em> different answers:<br /><blockquote class="tr_bq">When are you are finished optimizing?<br /><ol style="list-style-type: upper-alpha;"><li>When the cost of call reduction and latency reduction exceeds the cost of the performance you’re getting today.<br /><cite><span style="font-size: x-small;">Source: <a href="http://amzn.to/OM0q75" style="font-style: italic;" target="_blank">Optimizing Oracle Performance</a>&nbsp;(2003) pages 302–304.</span></cite></li><li>When the application is fast enough to meet your users’ requirements.<br /><cite><span style="font-size: x-small;">Source: I have taught this in various courses, conferences, and consulting calls since 1999 or so.</span></cite></li><li>When there are no unnecessary calls, and the calls that remain run at hardware speed.<br /><cite><span style="font-size: x-small;">Source: “<a href="http://youtu.be/AHCwwAAW3YA" target="_blank">Why you need a profiler for Oracle</a>” (2014) frames 2:51–3:20.</span></cite></li></ol></blockquote>My motive behind answers A and B was the idea that optimizing beyond what your business needs can be wasteful. I created these answers to deter people from misdirecting time and money toward perfecting something when those resources might be better invested improving something else. This idea was important, and it still is.<br /><br />So, then, where did C come from? I’ll begin with a picture. The following figure allows you to plot the response time for a single application function, whatever “given function” you’re looking at. You could draw a similar figure for every application function on your system (although I wouldn’t suggest it).<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-qoZVVsn-Kr4/VMqmPkM6OAI/AAAAAAAAB8s/HR-_TG2K_rg/s1600/Fig1.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://4.bp.blogspot.com/-qoZVVsn-Kr4/VMqmPkM6OAI/AAAAAAAAB8s/HR-_TG2K_rg/s1600/Fig1.png" /></a></div><br />Somewhere on this response time axis for your given function is the function’s actual response time. I haven’t marked that response time’s location specifically, but I know it’s in the blue zone, because at the bottom of the blue zone is the special response time&nbsp;<i>R<sub>T</sub></i>. This value&nbsp;<i>R<sub>T</sub></i> is the function’s <i>top speed</i> on the hardware you own today. Your function can’t go faster than this without upgrading something.<br /><br />It so happens that this top speed is the speed at which your function will run if and only if (i)&nbsp;it contains no unnecessary calls and (ii)&nbsp;the calls that remain run at hardware speed. ...Which, of course, is the idea behind this new answer C.<br /><h2>Where, exactly, is your “requirement”?</h2>Answer B (“When the application is fast enough to meet your users’ requirements”) requires that you know the users’ response time requirement for your function, so, next, let’s locate that value on our response time axis.<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-3atLLZsSWAY/VMqtGE5h-ZI/AAAAAAAAB9E/QjX4hqveKrs/s1600/Fig2.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://1.bp.blogspot.com/-3atLLZsSWAY/VMqtGE5h-ZI/AAAAAAAAB9E/QjX4hqveKrs/s1600/Fig2.png" /></a></div>This is where the trouble begins. Most DBAs don’t know what their users’ response time requirements really are. Don’t despair, though; most users don’t either.<br /><br />At banks, airlines, hospitals, telcos, and nuclear plants, you need strict service level agreements, so those businesses investment into quantifying them. But realize: quantifying all your functions’ response time requirements isn’t about a bunch of users sitting in a room arguing over which subjective speed limits sound the best. It’s about knowing your technological speed limits and understanding how close to those values your business needs to pay to be. It’s an expensive process. At some companies, it’s worth the effort; at most companies, it’s just not.<br /><br />How about using, “well, nobody complains about it,” as all the evidence you need that a given function is meeting your users’ requirement? It’s how a lot of people do it. You might get away with doing it this way if your systems weren’t growing. But systems <em>do</em> grow. More data, more users, more application functions: these are all forms of growth, and you can probably measure every one of them happening where you’re sitting right now. All these forms of growth put you on a collision course with failing to meet your users’ response time requirements, whether you and your users know exactly what they are, or not.<br /><br />In any event, if you don’t know exactly what your users’ response time requirements are, then you won’t be able to use “meets your users’ requirement” as your finish line that tells you when to stop optimizing. This very practical problem is the demise of answer B for most people.<br /><h2>Knowing your top speed</h2>Even if you do know exactly what your users’ requirements are, it’s not enough. You need to know something more.<br /><br />Imagine for a minute that you <i>do</i>&nbsp;know your users’ response time requirement for a given function, and let’s say that it’s this: “95% of executions of this function must complete within 5&nbsp;seconds.” Now imagine that this morning when you started looking at the function, it would typically run for 10&nbsp;seconds in your Oracle SQL Developer worksheet, but now after spending an hour or so with it, you have it down to where it runs pretty much every time in just 4&nbsp;seconds. So, you’ve eliminated 60% of the function’s response time. That’s a pretty good day’s work, right? The question is, are you done? Or do you keep going?<br /><br />Here is the reason that answer C is so important. You cannot responsibly answer whether you’re done without knowing that function’s top speed. Even if you know how fast people <i>want</i> it to run, you can’t know whether you’re finished without knowing how fast it <i>can</i> run.<br /><br />Why? Imagine that 85% of those 4&nbsp;seconds are consumed by Oracle <em>enqueue</em>, or <em>latch</em>, or <em>log file sync</em> calls, or by hundreds of <em>parse</em> calls, or 3,214&nbsp;network round-trips to return 3,214&nbsp;rows. If any of these things is the case, then no, you’re absolutely <i>not</i> done yet. If you were to allow some ridiculous code path like that to survive on a production system, you’d be diminishing the whole system’s effectiveness for everybody (even people who are running functions <i>other</i> than the one you’re fixing).<br /><br />Now, sure, if there’s something else on the system that has a higher priority than finishing the fix on this function, then you should jump to it. But you should at least leave this function on your to-do list. Your analysis of the higher priority function might even reveal that this function’s inefficiencies are <i>causing</i> the higher-priority functions problems. Such can be the nature of inefficient code under conditions of high load.<br /><br />On the other hand, if your function is running in 4 seconds and (i) its profile shows no unnecessary calls, and (ii) the calls that remain are running at hardware speeds, then you’ve reached a milestone:<br /><ol><li>if your code meets your users’ requirement, then you’re done;</li><li>otherwise, either you’ll have to reimagine how to implement the function, or you’ll have to upgrade your hardware (or both).</li></ol>There’s that “users’ requirement” thing again. You see why it has to be there, right?<br /><br />Well, here’s what most people do. They get their functions’ response times reasonably close to their top speeds (which, with good people, isn’t usually as expensive as it sounds), and then they worry about requirements only if those requirements are so important that it’s worth a project to quantify them. A requirement is usually considered really important if it’s close to your top speed or if it’s really expensive when you violate a service level requirement.<br /><br />This strategy works reasonably well.<br /><br />It is interesting to note here that <strong>knowing a function’s top speed is actually more important than knowing your users’ requirements for that function.</strong> A lot of companies can work just fine not knowing their users’ requirements, but without knowing your top speeds, you really are in the dark. A second observation that I find particularly amusing is this: not only is your top speed more important to know, <strong>your top speed is actually easier to compute than your users’ requirement</strong> (…if you have a profiler, which was my point in the video).<br /><br />Better <em>and</em> easier is a good combination.<br /><h2>Tomorrow is important, too</h2><blockquote class="tr_bq">When are you are finished optimizing?<br /><ol style="list-style-type: upper-alpha;"><li>When the cost of call reduction and latency reduction exceeds the cost of the performance you’re getting today.</li><li>When the application is fast enough to meet your users’ requirements.<br /><cite></cite></li><li>When there are no unnecessary calls, and the calls that remain run at hardware speed.<br /><cite></cite></li></ol></blockquote>Answer A is still a pretty strong answer. Notice that it actually maps closely to answer C. Answer C’s prescription for “no unnecessary calls” yields answer A’s goal of call reduction, and answer C’s prescription for “calls that remain run at hardware speed” yields answer A’s goal of latency reduction. So, in a way, C is a more action-oriented version of A, but A goes further to combat the perfectionism trap with its emphasis on the cost of action versus the cost of inaction.<br /><br />One thing I’ve grown to dislike about answer A, though, is its emphasis on <em>today</em> in “…exceeds the cost of the performance you’re getting today.” After years of experience with the question of when optimization is complete, I think that answer A under-emphasizes the importance of <em>tomorrow</em>. Unplanned <em>tomorrow</em>s can quickly become ugly <em>today</em>s, and as important as <em>tomorrow</em> is to businesses and the people who run them, it’s even more important to another community: database application developers.<br /><h2>Subjective goals are treacherous for developers</h2>Many developers have no way to test, <i>today</i>, the true production response time behavior of their code, which they won’t learn until <i>tomorrow</i>. ...And perhaps only until some remote, distant tomorrow.<br /><br />Imagine you’re a developer using 100-row tables on your desktop to test code that will access 100,000,000,000-row tables on your production server. Or maybe you’re testing your code’s performance only in isolation from other workload. Both of these are problems; they’re procedural mistakes, but they are everyday real-life for many developers. When this is how you develop, telling you that “your users’ response time requirement is <em>n</em>&nbsp;seconds” accidentally implies that you are finished optimizing when your query finishes in less than <em>n</em>&nbsp;seconds on your no-load system of 100-row test tables.<br /><br />If you are a developer writing high-risk code—and <i>any</i> code that will touch huge database segments in production is high-risk code—then of course you must aim for the “no unnecessary calls” part of the <em>top speed</em> target. And you must aim for the “and the calls that remain run at hardware speed” part, too, but you won’t be able to measure your progress against that goal until you have access to full data volumes <em>and</em> full user workloads.<br /><br />Notice that to do both of these things, <strong>you must have access to full data volumes and full user workloads in your development environment. </strong>To build high-performance applications, you must do <em>full data volume testing</em> and <em>full user workload testing</em> in each of your functional development iterations.<br /><br /><a href="http://carymillsap.blogspot.com/2010/10/agile-is-not-dirty-word.html">This is where agile development methods yield a huge advantage</a>: agile methods provide a project structure that encourages full performance testing for each new product function as it is developed. Contrast this with the <em>terrible</em> project planning approach of putting all your performance testing at the end of your project, when it’s too late to actually fix anything (if there’s even enough budget left over by then to do any testing at all). If you want a high-performance application with great performance diagnostics, then <a href="http://carymillsap.blogspot.com/search?q=instrumentation">performance instrumentation should be an important part of your feedback for each development iteration of each new function you create</a>.<br /><h2>My answer</h2>So, when are you finished optimizing?<br /><ol style="list-style-type: upper-alpha;"><li>When the cost of call reduction and latency reduction exceeds the cost of the performance you’re getting today.</li><li>When the application is fast enough to meet your users’ requirements.</li><li><strong>When there are no unnecessary calls and the calls that remain run at hardware speed.</strong></li></ol>There is some merit in all three answers, but as Dave Ensor taught me inside Oracle many years ago, the correct answer is&nbsp;C. Answer&nbsp;A specifically restricts your scope of concern to <em>today</em>, which is especially dangerous for developers. Answer&nbsp;B permits you to promote horrifically bad code, unhindered, into production, where it can hurt the performance of every function on the system. Answers&amp;nnbsp;A and B both presume that you know information that you probably don’t know and that you may not <em>need</em> to know. Answer&nbsp;C is my favorite answer because it is tells you exactly when you’re done, using units you can measure and that you <i>should</i> be measuring.<br /><br />Answer&nbsp;C is usually a tougher standard than answer&nbsp;A or&nbsp;B, and when it’s not, it is the best possible standard you can meet without upgrading or redesigning something. In light of this “tougher standard” kind of talk, it is still important to understand that what is optimal from a software engineering perspective is not always optimal from a business perspective. The term <i>optimized</i> must ultimately be judged within the constraints of what the business chooses to pay for. In the spirit of answer&nbsp;A, you can still make the decision not to optimize all your code to the last picosecond of its potential. How perfect you make your code should be a business decision. That decision should be informed by facts, and these facts should include knowledge of your code’s top speed.<br /><br />Thank you, <span style="font-family: Courier New, Courier, monospace;">Guđmundur Jósepsson</span>, of Iceland, for your question. Thank you for waiting patiently for several weeks while I struggled putting these thoughts into words.Cary Millsaphttp://www.blogger.com/profile/16697498718050285274noreply@blogger.com4tag:blogger.com,1999:blog-2954359812249072053.post-22901462150550847902014-02-28T20:35:00.001-08:002017-08-07T15:08:19.899-07:00“How did you learn so much stuff about Oracle?”In LinkedIn, a new connection asked me a very nice question. He asked, “I know this might sound stupid, but how did you learn so much stuff about Oracle. :)”<br /><br />Good one. I like the presumption that I know a lot of stuff about Oracle. I suppose that I do, at least about some some aspects of it, although I often feel like I don’t know enough. It occurred to me that answering publicly might also be helpful to anyone trying to figure out how to prepare for a career. Here’s my answer.<br /><br />I took a job with the young consulting division of Oracle Corporation in September 1989, about two weeks after the very first time I had heard the word “Oracle” used as the name of a company. My background had been mathematics and computer science in school. I had two post-graduate degrees: a Master of Science Computer Science with a focus on language design and compilers, and a Master of Business Administration with a focus in finance.<br /><br />My first “career job” was as a software engineer, which I started before the MBA. I designed languages and wrote compilers to implement those languages. Yes, people actually pay good money for that, and it’s possibly still the most fun I’ve ever had at work. I wrote software in <i><a href="http://en.wikipedia.org/wiki/C_(programming_language)">C</a></i>, <i><a href="http://en.wikipedia.org/wiki/Lex_(software)">lex</a></i>, and <a href="http://en.wikipedia.org/wiki/Yacc" style="font-style: italic;">yacc</a>, and I taught my colleagues how to do it, too. In particular, I spent a lot of time teaching my colleagues how to make their C code faster and more portable (so it would run on more computers than just the one on which you wrote it).<br /><br />Even though I loved my job, I didn’t see a lot of future in it. At least not in Colorado Springs in the late 1980s. So I took a year off to get the MBA at SMU in Dallas. I went for the MBA because I thought I needed to learn more about money and business. It was the most difficult academic year of my life, because I was not particularly connected to or even interested in most of the subject matter. I hated a lot of my classes, which made it difficult to do as well as I had been accustomed. But I kept grinding away, and finished my degree in the year it was supposed to take. Of course I learned many, many things that year that have been vital to my career.<br /><br />A couple of weeks after I got my MBA, I went to work for Oracle in Dallas, with a salary that was 168% of what it had been as a compiler designer. My job was to visit Oracle customers and help them with their problems.<br /><br />It took a while for me to get into a good rhythm at Oracle. My boss was sending me to these local customers that were having problems with the Oracle Financial Applications (the “Finapps,” as we usually called them, which would many years later become the E-Business Suite) on version 6.0.26 of the ORACLE database (it was all caps back then). At first, I couldn’t help them near as much as I had wanted to. It was frustrating.<br /><br />That actually became my rhythm: week after week, I visited these people who were having horrific problems with ORACLE and the Finapps. The database in 1990, although it had some pretty big bugs, was still pretty good. It was the applications that caused most of the problems I saw. There were a lot of problems, both with the software and with how it was sold. My job was to fix the problems. Some of those problems were technical. Many were not.<br /><br />A lot of the problems were performance; problems of the software running “too slowly.” I found those problems particularly interesting. For those, I had some experience and tools at my disposal. I knew a good bit about operating systems and compilers and profilers and linkers and debuggers and all that, and so learning about Oracle indexes and rollback segments (two good examples, continual sources of customer frustration) wasn’t that scary of a step for me.<br /><br />I hadn’t learned anything about Oracle or relational databases in school, I learned about how the database worked at Oracle by reading the documentation, beginning with the excellent <i>Oracle<sup>®</sup> Database Concepts.</i> Oracle sped me along a bit with a couple of the standard DBA courses.<br /><br />My real learning came from being in the field. The problems my customers had were immediately interesting by virtue of being important. The resources available to me for solving such problems back in the early 1990s were really just books, email, and the telephone. The Internet didn’t exist yet. (Can you imagine?) The Oracle books available back then, for the most part, were absolutely horrible. Just garbage. Just about the only thing they were good for was creating problems that you could bill lots of consulting hours to fix. The only thing that was left was email and the telephone.<br /><br />The problem with email and telephones, however, is that there has to be someone on the other end. Fortunately, I had that. The people on the other end of my email and phone calls were my saviors and heroes. In my early Oracle years, those saviors and heroes included people like Darryl Presley, Laurel Jamtgaard, Tom Kemp, Charlene Feldkamp, David Ensor, Willis Ranney, Lyn Pratt, Lawrence To, Roderick Mañalac, Greg Doherty, Juan Loaiza, Bill Bridge, Brom Mahbod, Alex Ho, Jonathan Klein, Graham Wood, Mark Farnham (who didn’t even work for Oracle, but who could cheerfully introduce me to anyone I needed), Anjo Kolk, and Mogens Nørgaard. I could never repay these people, and many more, for what they did for me. ...In some cases, at all hours of the night.<br /><br />So, how did I learn so much stuff about Oracle? It started by immersing myself into a universe where every working day I had to solve somebody’s real Oracle problems. Uncomfortable, but effective. I survived because I was persistent and because I had a great company behind me, filled with spectacularly intelligent people who loved helping each other. Could I have done that on my own, today, with the advent of the Internet and lots and lots of great and reliable books out there to draw upon? I doubt it. I sincerely do. But maybe if I were young again...<br /><br />I tell my children, there’s only one place where money comes from: other people. <b>Money comes <i>only</i> from other people.</b> So many things in life are that way.<br /><br />I’m a natural introvert. I naturally withdraw from group interactions whenever I don’t feel like I’m helping other people. Thankfully, my work and my family draw me out into the world. If you put me into a situation where I need to solve a technical problem that I can’t solve by myself, then I’ll seek help from the wonderful friends I’ve made.<br /><br />I can never pay it back, but I can try to <a href="http://en.wikipedia.org/wiki/Pay_it_forward">pay it forward</a>.<br /><br />(Oddly, as I’m writing this, I realize that I don’t take the same healthy approach to solving <i>business</i> problems. Perhaps it’s because I naturally assume that my friends would have fun helping solve a <i>technical</i> problem, but that solving a <i>business</i> problem would <i>not</i> be fun and therefore I would be imposing upon them if I were to ask for help solving one. I need to work on that.)<br /><br />So, to my new LinkedIn friend, here’s my advice. Here’s what worked for me:<br /><ul><li>Educate yourself. Read, study, experiment. Educate yourself <i>especially</i> well in the fundamentals. So many people don’t. Being fantastic at the fundamentals is a competitive advantage, no matter what you do. If it’s Oracle you’re interested in learning about, that’s software, so learn about software: about operating systems, and C, and linkers, and profilers, and debuggers, .... Read the <i>Oracle Database Concepts</i> guide and all the other free Oracle documentation. Read every book there is by Tom Kyte and Christian Antognini and Jonathan Lewis and Tanel Põder and Kerry Osborne and Karen Morton and James Morle all the other great authors out there today. And read their blogs.</li><li>Find a way to hook yourself into a network of people that are willing and able to help you. You can do that online these days. You can earn your way into a community by doing things like asking thoughtful questions, treating people respectfully (even the ones who don’t treat you respectfully), and finding ways to teach others what you’ve learned. Write. Write what you know, for other people to use and improve. And for God’s sake, if you <i>don’t</i> know something, don’t act like you do. That just makes everyone think you’re an asshole, which isn’t helpful.</li><li>Immerse yourself into some real problems. Read <a href="http://www.amazon.com/Scuttle-Your-Ships-Before-Advancing/dp/019508408X"><i>Scuttle Your Ships Before Advancing</i></a> if you don’t understand why. You can solve real problems online these days, too (e.g., <a href="http://stackexchange.com/">StackExchange</a>&nbsp;and even <a href="http://oracle.com/">Oracle.com</a>), although I think that it’s better to work on real live problems at real live customer sites. Stick with it. Fix things. Help people.</li></ul><div>Help people.<br /><br />That’s my advice.</div>Cary Millsaphttp://www.blogger.com/profile/16697498718050285274noreply@blogger.com4tag:blogger.com,1999:blog-2954359812249072053.post-47038272790750716922013-04-05T04:00:00.000-07:002013-04-09T10:15:33.586-07:00NoSQL and Oracle, Sex and MarriageAt <a href="http://memberservices.membee.com/538/2013%20Events.aspx">last week’s Dallas Oracle Users Group meeting</a>, an Oracle DBA asked me, “With all the new database alternatives out there today, like all these open source NoSQL databases, would you recommend for us to learn some of those?”<br /><br />I told him I had a theory about how these got so popular and that I wanted to share that before I answered his question.<br /><br />My theory is this. Developers perceive Oracle as being too costly, time-consuming, and complex:<br /><ul><li>An Oracle Database costs a lot. If you don’t already have an Oracle license, it’s going to take time and money to get one. On the other hand, you can just install Mongo DB today.</li><li>Even if you have an Oracle site-wide license, the Oracle software is probably centrally controlled. To get an installation done, you’re probably going to have to negotiate, justify, write a proposal, fill out forms, ...you know, supplicate yourself to—er, I mean negotiate with—your internal IT guys to get an Oracle Database installed. It’s a lot easier to just install MySQL yourself.</li><li>Oracle is too complicated. Even if you have a site license and someone who’s happy to install it for you, it’s so big and complicated and proprietary... The only way to run an Oracle Database is with SQL (a declarative language that is alien to many developers) executed through a thick, proprietary, possibly even difficult-to-install layer of software like Oracle Enterprise Manager, Oracle SQL Developer, or sqlplus. Isn’t there an open source database out there that you could just manage from your operating system command line?</li></ul>When a developer is thinking about installing a database today because he need one to write his next feature, he wants something cheap, quick, and lightweight. None of those constraints really sounds like Oracle, does it?<br /><br />So your Java developers install this NoSQL thing, because it’s easy, and then they write a bunch of application code on top of it. Maybe so much code that there’s no affordable way to turn back. Eventually, though, someone will accidentally crash a machine in the middle of something, and there’ll be a whole bunch of partway finished jobs that die. Out of all the rows that are supposed to be in the database, some will be there and some won’t, and so now your company will have to figure out how to delete the parts of those jobs that aren’t supposed to be there.<br /><br />Because now everyone understands that this kind of thing will probably happen again, too, the exercise may well turn into a feature specification for various “eraser” functions for the application, which (I hope, anyway) will eventually lead to the team discovering the technical term <i>transaction</i>. A transaction is <a href="https://en.wikipedia.org/wiki/Database_transaction">a unit of work that must be atomic, consistent, isolated, and durable</a> (that’where this acronym <a href="https://en.wikipedia.org/wiki/ACID">ACID</a> comes from). If your database doesn’t guarantee that every arbitrarily complex unit of work (every <i>transaction</i>) makes it either 100% into the database or not at all, then your developers have to write that feature themselves. That’s a big, tremendously complex feature. On an Oracle Database, the transaction is a fundamental right given automatically to every user on the system.<br /><br />Let’s look at just that ‘I’ in ACID for a moment: <i>isolation</i>. How big a deal is transaction isolation? Imagine that your system has a query that runs from 1&nbsp;pm to 2&nbsp;pm. Imagine that it prints results to paper as it runs. Now suppose that at 1:30&nbsp;pm, some user on the system updates two rows in your query’s base table: the table’s first row and its last row. At 1:30, the pre-update version of that first row has already been printed to paper (that happened shortly after 1 pm). The question is, what’s supposed to happen at 2 pm when it comes time to print the information for the final row? You should hope for the <i>old</i> value of that final row—the value as of 1&nbsp;pm—to print out; otherwise, your report details won’t add up to your report totals. However, if your database doesn’t handle that transaction isolation feature for you automatically, then either you’ll have to lock the table when you run the report (creating an 30-minute-long performance problem for the person wanting to update the table at 1:30), or your query will have to make a snapshot of the table at 1&nbsp;pm, which is going to require both a lot of extra code <i>and</i>&nbsp;that same lock I just described. On an Oracle Database, high-performance, non-locking read consistency is a standard feature.<br /><br />And what about backups? Backups are intimately related to the read consistency problem, because backups are just really long queries that get persisted to some secondary storage device. Are you going to quiesce your whole database—freeze the whole system—for whatever duration is required to take a cold backup? That’s the simplest sounding approach, but if you’re going to try to run an actual business with this system, then shutting it down every day—taking down time—to back it up is a real operational problem. Anything fancier (for example, rolling downtime, quiescing parts of your database but not the whole thing) will add cost, time, and complexity. On an Oracle Database, high-performance online “hot” backups are a standard feature.<br /><br />The thing is, your developers could write code to do transactions (read consistency and all) and incremental (“hot”) backups. Of course they could. Oh, and constraints, and <a href="https://en.wikipedia.org/wiki/Database_trigger">triggers</a> (don’t forget to remind them to handle the mutating table problem), and automatic query optimization, and more, ...but to write those features Really Really Well™, it would take them 30&nbsp;years and a hundred of their smartest friends to help write it, test it, and fund it. Maybe that’s an exaggeration. Maybe it would take them only a couple years. But Oracle has already done all that for you, and they offer it at a cost that doesn’t seem as high once you understand what all is in there. (And of course, if you buy it on May 31, they’ll cut you a break.)<br /><br />So I looked at the guy who asked me the question, and I told him, it’s kind of like getting married. When you think about getting married, you’re probably focused mostly on the sex. You’re probably not spending too much time thinking, “Oh, baby, <i>this</i> is the woman I want to be doing family budgets with in fifteen years.” But you <i>need</i> to be. You need to be thinking about the boring stuff like transactions and read consistency and backups and constraints and triggers and automatic query optimization when you select the database you’re going to marry.<br /><br />Of course, my 15-year-old son was in the room when I said this. I think he probably took it the right way.<br /><br />So my answer to the original question—“Should I learn some of these other technologies?”—is “Yes, absolutely,” for at least three reasons:<br /><ul><li>Maybe some development group down the hall is thinking of installing Mongo DB this week so they can get their next set of features implemented. If you know something about both Mongo DB and Oracle, you can help that development group and your managers make better informed decisions about that choice. Maybe Mongo DB is all they need. Maybe it’s not. You can help.</li><li>You’re going to learn a lot more than you expect when you learn another database technology, just like learning another natural language (like English, Spanish, etc.) teaches you things you didn’t expect to learn about your native language.</li><li>Finally, I encourage you to diversify your knowledge, if for no other reason than your own self-confidence. What if market factors conspire in such a manner that you find yourself competing for an Oracle-unrelated job? A track record of having learned at least two database technologies is proof to yourself that you’re not going to have that much of a problem learning your third.</li></ul>Cary Millsaphttp://www.blogger.com/profile/16697498718050285274noreply@blogger.com14tag:blogger.com,1999:blog-2954359812249072053.post-359184629052401792013-04-03T14:57:00.000-07:002015-09-19T15:19:17.261-07:00And now, ...the videoFirst, I want to thank everyone who responded to <a href="http://carymillsap.blogspot.com/2012/11/when-is-video-better.html">my prior blog post and its accompanying survey, where I asked when video is better than a paper</a>. As I mentioned already in the comment section for that blog post, the results were loud and clear: 53.9% of respondents indicated that they’d prefer reading a paper, and 46.1% indicated that they’d prefer watching a video. Basically a clean 50/50 split.<br /><br />The comments suggested that people have a lower threshold for “polish” with a video than with a paper, so one of the ideas to which I’ve needed to modify my thinking is to just create decent videos and publish them without expending a lot of effort in editing.<br /><br />But how?<br /><br />Well, the idea came to me in the process of agreeing to perform a 1-hour session for my good friends and customers at <a href="http://www.pythian.com/">The Pythian Group</a>. Their education department asked me if I’d mind if they recorded my session, and I told them I would love if they would. They encouraged me to open it up the the public, which of course I thought (cue light bulb over head) was the best idea ever. So, really, it’s not a video as much as it’s a recorded performance. <br /><br />I haven’t edited the session at all, so it’ll have rough spots and goofs and imperfect audio... But I’ve been eager ever since the day of the event (2013-02-15) to post it for you.<br /><br />So here you go. For the “other 50%” who prefer watching a video, I present to you: “The Method R Profiling Ecosystem.” If you would like to follow along in the accompanying paper, you can get it here: “<a href="http://method-r.com/downloads/doc_view/175-method-r-software-white-paper-1-a-first-look-at-using-method-r-workbench-software?tmpl=component&amp;format=raw">A First Look at Using Method&nbsp;R Workbench Software</a>.”<br /><br /><iframe allowFullScreen='true' webkitallowfullscreen='true' mozallowfullscreen='true' width='320' height='266' src='https://www.youtube.com/embed/S-ih1ST8Vt0?feature=player_embedded' FRAMEBORDER='0' />Cary Millsaphttp://www.blogger.com/profile/16697498718050285274noreply@blogger.com1tag:blogger.com,1999:blog-2954359812249072053.post-23829534582054076162012-11-15T14:59:00.000-08:002015-09-19T15:19:42.403-07:00When is Video Better?Ok, I’m stuck, and I need your help.<br /><br />At <a href="http://method-r.com/">my company</a>, we sell&nbsp;<a href="http://method-r.com/software">software tools</a>&nbsp;that help Oracle application developers and database administrators see exactly where their code spends their users’ time. I want to publish better information at our web page that will allow people who are interested to learn more about our software, and that will allow people who don’t even realize we exist to discover what we have. My theory is that the more people who understand <i>exactly</i>&nbsp;what we have, the more customers we’ll get, and we have some evidence that bears that out.<br /><br />I’ve gotten so much help from YouTube in various of my endeavors that I’ve formed the grand idea in my head:<br /><blockquote class="tr_bq">We need more videos showing our products.</blockquote>The first one I made is the 1:13 video on YouTube called “<a href="http://www.youtube.com/watch?v=kBSJqji-Bg0&amp;feature=youtu.be&amp;hd=1">Method R Tools v3.0: Getting Started</a>.” I’m interested to see how effective it is. I think this content is perfect for the video format because the whole point is to <i>show</i>&nbsp;you how easy it is to get going. <i>Saying</i> it’s easy just isn’t near as fun or convincing as <i>showing</i>&nbsp;it’s easy.<br /><br />The next thing I need to share with people is a great demonstration that Jeff Holt has helped me pull together, which shows off all the tools in our suite, how they interact and solve an interesting and important common problem. But this one can’t be a 1-minute video; it’s a story that will take a lot longer to tell than that. It’s probably a 10- to 15-minute story, if I had to guess.<br /><br />Here’s where I’m stuck.&nbsp;Should I make a video? Or write up a blog post for it? The reason this is a difficult question is that making a video costs me about 4 hours per minute of output I can create. That will get better over time, as I practice and accumulate experience. But right now, videos cost me a lot of time.&nbsp;On the other hand, I can whip together a blog post with plenty of detail in a fraction of the time.<br /><br />Where I need your help is to figure out how much benefit there is, really, to creating a video instead of just a write-up. Some things I have to consider:<br /><ul><li>Would a 15-minute video capture the attention of people who Do people glaze over (TL;DR) on longish printed case studies on which they’d gladly watch about 15 minutes of video?</li><li>Or do people just pass on the prospect of watching a 15-minute case study about a problem they might not even realize they have yet? I ask this, because I find myself not clicking on any video that I know will take longer than a minute or two, unless I believe it’s going to help me solve a difficult problem that I know I have right now.</li></ul><div>So, if you don’t mind giving me a hand, I’ve created a <a href="http://www.surveymonkey.com/s/XJPBY6J">survey at SurveyMonkey</a> that asks just three simple questions that will help me determine which direction to go next. I’m eager to see what you say.</div><div><br /></div><div>Thank you for your time.</div>Cary Millsaphttp://www.blogger.com/profile/16697498718050285274noreply@blogger.com12tag:blogger.com,1999:blog-2954359812249072053.post-83134062479113034832012-08-28T10:16:00.001-07:002012-08-28T10:17:00.243-07:00Is “Can’t” Really the Word You Want?My friend Chester (<a href="http://www.linkedin.com/in/chetjustice">Chet Justice</a> in real life; <a href="http://www.oraclenerd.com/"><span style="font-family: Courier New, Courier, monospace;">oraclenerd</span></a> when he puts his cape on) <a href="https://twitter.com/oraclenerd/status/240265082515357696">tweeted</a> this yesterday:<br /><blockquote class="tr_bq">can’t lives on won’t street - i’m sure my son will hate me when he’s older for saying that all the time.</blockquote><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-WgHiqQlxXqE/UDz5xYEqoEI/AAAAAAAABzk/EEHwBcZtw9U/s1600/WONT+ST.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img alt="" border="0" height="192" src="http://1.bp.blogspot.com/-WgHiqQlxXqE/UDz5xYEqoEI/AAAAAAAABzk/EEHwBcZtw9U/s320/WONT+ST.jpg" title="&quot;WONT ST&quot; sign generated at http://www.streetsigngenerator.com/" width="320" /></a></div><br />I like it. It reminds me of an article that I drafted a few months ago but hadn’t posted yet. Here it is...<br /><br />When I ask for help sometimes, I find myself writing a sentence that ends with, “…but I can’t figure it out.” I try to catch myself when I do that, because <i>can’t</i> is not the correct word.<br /><br />Here’s what <i>can’t</i> means.&nbsp;Imagine a line representing time, with the middle marking where you are at some “right now” instant in time. The leftward direction represents the past, and the rightward direction represents the future.<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-wYDu4fnuhe4/UDzdjbSGZmI/AAAAAAAABys/BRbCfqsg6pw/s1600/Can't-1.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img alt="" border="0" src="http://2.bp.blogspot.com/-wYDu4fnuhe4/UDzdjbSGZmI/AAAAAAAABys/BRbCfqsg6pw/s1600/Can't-1.png" title="A timeline" /></a></div><br /><i>Can’t</i> means that I am incapable of doing something at every point along this timeline: past, present, and future.<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-j1c7BSxPI78/UDzlDPtXZoI/AAAAAAAABzA/0MRDdbjPbmU/s1600/Can't-2.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img alt="" border="0" src="http://3.bp.blogspot.com/-j1c7BSxPI78/UDzlDPtXZoI/AAAAAAAABzA/0MRDdbjPbmU/s1600/Can't-2.png" title="&quot;Can't&quot; on a timeline." /></a></div><br />Now, of course, <i>can’t</i> is different from <i>mustn’t</i>—“must not”<i>—</i>which means that you’re not supposed to try to do something, presumably because it’s bad for you. So I’m not talking about the can/may distinction that grammarians bring to your attention when you say, “Can I have a candy bar?” and then they say, “I don’t know, <i>can</i> you?” And then you have to say, “Ok, <i>may</i> I have a candy bar” to actually have candy bar. I digress.<br /><br />Back to the timeline. There are other words you can use to describe specific parts of that timeline, and here is where it becomes more apparent that <i>can’t</i> is often just not the right word:<br /><ul class="ul1"><li class="li1"><i>Didn’t</i>, a contraction of “did not.” It means that you did not do something in the past. It doesn’t necessarily mean you couldn’t have, or that you were incapable of doing it; it’s just a simple statement of fact that you, in fact, did not.</li><li class="li1"><i>Aren’t</i>, a contraction of “are not.” It means that you are in fact not doing something right now. This is different from “don’t,” which often is used to state an intention about the future, too, as in “I don’t smoke,” or “<a href="http://en.wikipedia.org/wiki/Green_Eggs_and_Ham">I do not like them, Sam-I-am</a>.”</li><li class="li1"><i>Won’t</i>, a contraction of “will not.” It means that you will not do something in the future. It doesn’t necessarily mean you couldn’t, or that you are going to be incapable of doing it; it’s just a simple statement of <i>intention</i> that you, right now, don’t plan to. That’s the funny thing about your future. Sometimes you decide to change your plans. That’s ok, but it means that sometimes when you say <i>won’t</i>, you’re going to be wrong.</li></ul>Here’s how it all looks on the timeline:<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-wZvPXUwF3lA/UDzomD8jeQI/AAAAAAAABzQ/hxzWMiJJcPQ/s1600/Can't-3.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img alt="" border="0" src="http://2.bp.blogspot.com/-wZvPXUwF3lA/UDzomD8jeQI/AAAAAAAABzQ/hxzWMiJJcPQ/s1600/Can't-3.png" title="&quot;Didn't,&quot; &quot;aren't,&quot; and &quot;won't&quot; on a timeline" /></a></div><br />So, when I ask for help and I almost say, “I can’t figure it out,” the truth is really only that “I <i>didn’t</i> figure it out.”<br /><br />“...Yet.”<br /><br />...Because, you see, I do not have complete knowledge about the future, so it is not correct for me to say that I will never figure it out. Maybe I will. However, I do have complete knowledge of the past (this one aspect of the past, anyway), and so it <i>is</i> correct to speak about that by saying that I <i>didn’t</i> figure it out, or that I <i>haven’t</i> figured it out.<br /><br />Does it seem like I’m going through a lot of bother making such detailed distinctions about such simple words? It matters, though. The people around you are affected by what you say and write. Furthermore, <i>you</i> are affected by the the stuff you say and write. Not only do our thoughts affect our words, our words affect our thoughts. The way you say and write stuff changes <i>how you think about stuff</i>. So if you aspire to tell the truth (is that still a thing?), or if you just want to <i>know</i> more about the truth, then it’s important to get your words right.<br /><br />Now, back to the timeline. Just because you haven’t done something doesn’t mean you <i>can’t</i>, which means that you never will. <i>Can’t</i> is an as-if-factual statement about your future. Careless use of the word <i>can’t</i> can hurt people when you say it about them. It can hurt you when you think it about yourself.<br /><br />Listen for it; you’ll hear it all the time:<br /><ul><li>“Why can’t you sit still?!” If you ask the question more accurately, it kind of answers itself: “Why haven’t you sat still for the past hour and a half?” Well, dad, maybe it’s because I’m bored and, oh, maybe it’s&nbsp;<i>because&nbsp;I’m five</i>! Asking why you <i>haven’t</i> been sitting still reminds me that perhaps there’s something <i>I</i> can do to make it easier for both of us to work through the next five minutes, and that maybe asking you to sit still for the next whole hour is asking too much.</li><li>“You can’t run that fast.” Prove it. Just because you haven’t doesn’t mean you never will. Before 1954, people used to say you can’t run a <a href="http://en.wikipedia.org/wiki/Four-minute_mile">four-minute mile</a>, that <i>nobody</i> can. Today, <a href="http://trackandfieldnews.com/archive/worldS4.pdf">over a thousand people have done it</a>. Can you become the most commercially successful and critically acclaimed act in history of popular music if you can’t read music? Well, apparently you can: <a href="http://wiki.answers.com/Q/Did_the_Beatles_read_sheet_music">that’s what the Beatles did</a>. I’m probably not going to, but understanding that it’s not impossible is more life-enriching than believing I <i>can’t</i>.</li><li>“You can’t be trusted.” Rough waters here, mate. If you’ve behaved in such a manner that someone would say this about you, then you’ve got a lot of work in front of you. But no. No matter what, so far, all you’ve demonstrated is that you have <i>been</i> untrustworthy in the past. A true statement about your past is not necessarily a true statement about your future. It’s all about the choices you make from this moment onward.</li></ul>Lots of parents and teachers don’t like <i>can’t</i> for its de-motivational qualities. I agree: when you think you can’t, you most likely won’t, because you won’t even try. It’s Chet’s “WONT STREET”.<br /><br />When you think clearly about its technical meaning, you can also see that it’s also a word that’s often just not true. I hate being wrong. So I try not to use the word <i>can’t</i> very often.Cary Millsaphttp://www.blogger.com/profile/16697498718050285274noreply@blogger.com10tag:blogger.com,1999:blog-2954359812249072053.post-17902021197240597242012-06-07T08:19:00.000-07:002012-06-07T08:19:05.151-07:00An Organizational Constraint that Diminishes Software QualityOne of the biggest problems in software performance today occurs when the people who write software are different from the people who are required to solve the performance problems that their software causes. It works like this: <br /><ol><li>Architects design a system and pass the specification off to the developers.</li><li>The developers implement the specs the architects gave them, while the architects move on to design another system.</li><li>When the developers are “done” with their phase, they pass the code off to the production operations team. The operators run the system the developers gave them, while the developers move on to write another system.</li></ol>The process is an assembly line for software: architects specialize in architecture, developers specialize in development, and operators specialize in operating. It sounds like the principle of industrial efficiency taken to its logical conclusion in the software world.<br /><br /><table align="center" border="0" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody><tr><td style="text-align: center;"><a href="http://1.bp.blogspot.com/-0FOPOKySN6A/T9C8zVdxEbI/AAAAAAAAByQ/JvBTD6Mx9zc/s1600/Gantt1.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="180" src="http://1.bp.blogspot.com/-0FOPOKySN6A/T9C8zVdxEbI/AAAAAAAAByQ/JvBTD6Mx9zc/s320/Gantt1.png" width="320" /></a></td></tr><tr><td class="tr-caption" style="font-size: 90%; text-align: center;"><br />In this waterfall project plan,<br />architects design systems they never see written,<br />and developers write systems they never see run.</td></tr></tbody></table><br />Sound good? It sounds like how Henry Ford made a lot of money building cars... Isn’t that how they build roads and bridges? So why not?<br /><br />With software, there’s a horrible problem with this approach. If you’ve ever had to manage a system that was built like this, you know exactly what it is.<br /><br />The problem is the absence of a feedback loop between actually using the software and building it. It’s a feedback loop that people who design and build software need for their own professional development. Developers who never see their software run don’t learn enough about how to make their software <i>run better</i>. Likewise, architects who never see their systems run have the same problem, only it’s worse, because (1)&nbsp;their involvement is even more abstract, and (2)&nbsp;their feedback loops are even longer.<br /><br />Who are the performance experts in most Oracle shops these days? Unfortunately, it’s most often the database administrators, not the database developers. It’s the people who <i>operate</i> a system who learn the most about the system’s design and implementation mistakes. That’s unfortunate, because the people who <i>design</i> and <i>write</i> a system have so much more influence over how a system performs than do the people who just operate it.<br /><br />If you’re an architect or a developer who has never had to support your own software in production, then you’re probably making some of the same mistakes now that you were making five years ago, without even realizing they’re mistakes. On the other hand, if you’re a developer who has to maintain your own software while it’s being operated in production, you’re probably thinking about new ways to make your next software system easier to support.<br /><br />So, why is software any different than automotive assembly, or roads and bridges? It’s because software design is a process of <i>invention</i>. Almost every time. When is the last time you ever built exactly the same software you built before? No matter how many libraries you’re able to reuse from previous projects, every system you design is different from any system you’ve ever built before. You don’t just stamp out the same stuff you did before.<br /><br />Software is funny that way, because the cost of copying and distributing it is vanishingly small. When you make great software that everyone in the world needs, you write it once and ship it at practically zero cost to everyone who needs it.&nbsp;Cars and bridges don’t work that way. Mass production and distribution of cars and bridges requires significantly more resources. The thousands of people involved in copying and distributing cars and bridges don’t have to know how to invent or refine cars or bridges to do great work. But with software, since copying and distributing it is so cheap, almost all that’s left is the invention process. And that requires feedback, just like inventing cars and bridges did.<br /><br />Don’t organize your software project teams so that they’re denied access to this vital feedback loop.Cary Millsaphttp://www.blogger.com/profile/16697498718050285274noreply@blogger.com18tag:blogger.com,1999:blog-2954359812249072053.post-16797565135680101522012-03-29T10:29:00.004-07:002017-08-07T15:35:27.393-07:00The String PuzzleI gave my two boys an old puzzle to solve yesterday. I told them that I’d give them each $10 if they could solve it for me. It’s one of the ways we do the “allowance” thing around the house sometimes.<br /><br />Here’s the puzzle. A piece of string is stretched tightly around the Earth along its equator. Imagine that this string along the equator forms a perfect circle, and imagine that to reach around that perfect circle, the string has to be exactly 25,000 miles long. Now imagine that you wanted to suspend this string 4 inches above the surface of the Earth, all the way around it. How much longer would the string have to be do do this?<br /><div class="separator" style="clear: both; text-align: -webkit-auto;"><br /></div><div class="separator" style="clear: both; text-align: center;"></div><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-wkBMje4x-jg/T3XijcSC08I/AAAAAAAABoU/pXqbyj_RCfE/s1600/String-Puzzle-v2.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="267" src="https://3.bp.blogspot.com/-wkBMje4x-jg/T3XijcSC08I/AAAAAAAABoU/pXqbyj_RCfE/s320/String-Puzzle-v2.png" width="320"></a></div><div class="separator" style="clear: both; text-align: center;"><br /></div>Before you read any further, guess the answer. How much longer would the string have to be? A few inches? Several miles? What do you think?<br /><br />Now, my older son Alex was more interested in the problem than I thought he would be. He knows the formula for computing the circumference of a circle as a function of its diameter, and he knew that raising the string 4 inches above the surface constituted a diameter change. So the kernel of a solution had begun to formulate in his head. And he had a calculator handy, which he loves to use.<br /><br />We were at <a href="http://chipotle.com/en-US/Default.aspx?type=default">Chipotle</a> for dinner. The rest of the family went in to order, and Alex waited in the truck to solve the problem “where he could have some peace and quiet.” He came into the restaurant in time to order, and he gave me a number that he had cooked up on his calculator in the truck. I had no idea whether it was correct or not (I haven’t worked the problem in many years), so I told him to explain to me how he got it.<br /><br />When he explained to me what he had done, he pretty quickly discovered that he had made a unit conversion error. He had manipulated the ‘25,000’ and the ‘4’ as if they had been expressed in the same units, so his answer was wrong, but it sounded like conceptually he got what he needed to do to solve the problem. So I had him write it down. On a napkin, of course:<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-kXIFmn9gxhc/T3SKLt6q7bI/AAAAAAAABn4/IxABwpNvKxM/s1600/IMG_2041.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="239" src="https://3.bp.blogspot.com/-kXIFmn9gxhc/T3SKLt6q7bI/AAAAAAAABn4/IxABwpNvKxM/s320/IMG_2041.jpg" width="320"></a></div><br />The first thing he did was draw a sphere (top center) and tell me that the diameter of this sphere is 25,000 miles divided by 3.14 (the approximation of&nbsp;π that they use at school). He started dividing that out on his calculator when I pulled the “Whoa, wait” thing where I asked him <i>why</i> he was dividing those two quantities, which caused him, grudgingly, to write out that <i>C</i> = 25,000 mi, that <i>C</i> = π<i>d</i>, and that therefore <i>d</i> = <i>C</i>/π. So I let him figure out that <i>d ≈</i>&nbsp;7,961 mi. There’s loss of precision there, because of the 3.14 approximation, and because there are lots of digits to the right of the decimal point after ‘7961’, but more about that later.<br /><br />I told him to call the length of the original string <i>C</i> (for circumference) and to call the 4-inch suspension distance of the string <i>h</i> (for height), and then write me the formula for the length of the 4-inch high string, without worrying about <i>any</i>&nbsp;unit conversion issues. He&nbsp;got the formula pretty close on the first shot. He added 4 inches to the diameter of the circle instead of adding 4 inches to the radius (you can see the ‘4’ scratched out and replaced with an ‘8’ in the “8 in/63360 in” expression in the middle of the napkin. Where did the ‘63360’ come from, I asked? He explained that this is the number of inches in a mile (5,280 × 12). Good.<br /><br />But I asked him to hold off on the unit conversion stuff until the very end. He wrote the correct formula for the length of the new string, which is [(<i>C</i>/π) + 2<i>h</i>]·π (bottom left). Then I let him run the formula out on his calculator. It came out to something bigger than exactly 25,000; I didn’t even look at what he got. This number he had produced minus 25,000 would be the answer we were looking for, but I knew there would be at least two problems with getting the answer this way:<br /><ul><li>The value of π is approximately 3.14, but it’s not exactly 3.14.</li><li>Whenever he had to transfer a precise number from one calculation to the next, I knew Alex was either rounding or truncating liberally.</li></ul>So, I told him we were going to work this problem out completely symbolically, and only plug the numbers in at the very end. It turns out that doing the problem this way yields a very nice little surprise.<br /><br />Here’s my half of the napkin:<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-3Y7kOkOXoU4/T3SKSBjyTFI/AAAAAAAABoA/_KXKs0Y0z0o/s1600/IMG_2042.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="239" src="https://4.bp.blogspot.com/-3Y7kOkOXoU4/T3SKSBjyTFI/AAAAAAAABoA/_KXKs0Y0z0o/s320/IMG_2042.jpg" width="320"></a></div><br />I called the new string length <i>c</i>ʹ and the old string length <i>c</i>. The answer to the puzzle is the value of <i>c</i>ʹ&nbsp;−&nbsp;<i>c</i>.<br /><br />The new circumference <i>c</i>ʹ will be π times the new diameter, which is <i>c</i>/π + 2<i>h</i>, as Alex figured out. The second step distributes the&nbsp;π factor through the addition, resulting in&nbsp;<i>c</i>ʹ&nbsp;−&nbsp;<i>c</i> = π<i>c</i>/π + 2π<i>h</i>&nbsp;−&nbsp;<i>c</i>. The π<i>c</i>/π term simplifies to just <i>c</i>, and it’s the final step where the magic happens: <i>c</i>ʹ&nbsp;−&nbsp;<i>c</i> = <i>c</i> + 2π<i>h</i> − <i>c</i> reduces simply to <i>c</i>ʹ −&nbsp;<i>c</i> = 2π<i>h</i>. The difference between the new string length and the old one is 2π<i>h</i>, which in our case (where <i>h</i> = 4 inches) is roughly 25.133 inches.<br /><br />So, problem solved. The string will have to be about 25.133 inches longer if we want to suspend it 4 inches above the surface.<br /><br />Notice how simple the solution is: the only error we have to worry about is how precisely we want to represent π in our calculation.<br /><br />Here’s the even cooler part, though: there is no ‘<i>c</i>’ in the formula for the answer. Did you notice that? What does that mean?<br /><br />It means that the original circumference doesn’t matter. It means that if we have a string around the Moon that we want to raise 4 inches off the surface, we just need another 25.133 inches.&nbsp;How about a string stretched around Jupiter? just 25.133 more inches. Betelgeuse, a star whose diameter is about the same size as Jupiter’s <i>orbit</i>? Just 25.133 more inches. The whole solar system? Just 25.133 more inches. The entire Milky Way galaxy? Just 25.133 more inches. A golf ball? Again, 25.133 more inches. A single electron? Still 25.133 inches.<br /><br />This is the kind of insight that solving a problem symbolically provides. A numerical solution tends to answer a question and halt the conversation. A symbolic formula answers our question and invites us to ask more.<br /><br />The calculator answer is just a fish (pardon the analogy, but a potentially tainted fish at that). The symbolic answer is a fishing pole with a stock pond.<br /><br />So, did I pay Alex for his answer? No. Giving two or three different answers doesn’t close the deal, even if one of the answers is correct. He doesn’t get paid for blurting out possible answers. He doesn’t even get paid for answering the question correctly; he gets paid for <i>convincing</i> me that he has created a correct answer. In the professional world, <i>that</i> is the key: the convincing.<br /><br />Imagine that a consultant or a salesman told you that you needed to execute a $250,000 procedure to make your computer application run faster. Would you do it? Under what circumstances? If you just trusted him and did it, but it didn’t do what you had hoped, would you ever trust him again? I would argue that you shouldn’t trust an answer without a compelling rationale, and that the recommender’s reputation alone is not a compelling rationale.<br /><br />The deal is, whenever Alex can show me the right answer and convince me that he’s done the problem correctly, that’s when I’ll give him the $10. I’m guessing it’ll happen within the next three days or so. The interesting bet is going to be whether his little brother beats him to it.Cary Millsaphttp://www.blogger.com/profile/16697498718050285274noreply@blogger.com22tag:blogger.com,1999:blog-2954359812249072053.post-17535557392274137882011-12-04T04:13:00.000-08:002011-12-04T04:13:16.272-08:00Gwen Shapira on SSDIf you haven’t seen <a href="http://www.pythian.com/news/28797/de-confusing-ssd-for-oracle-databases/">Gwen Shapira’s article about de-confusing SSD</a>, I recommend that you read it soon.<br /><br />One statement stood out as an idea on which I wanted to comment:<br /><blockquote class="tr_bq">If you don’t see significant number of physical reads and sequential read wait events in your AWR report, you won’t notice much performance improvements from using SSD.</blockquote>I wanted to remind you that you can do better. If you do notice a significant number of physical reads and sequential write wait events in your AWR report, then it’s still not certain that SSD will improve the performance of the <b>task whose performance you’re hoping to improve</b>. You don’t have to guess about the effect that SSD will have upon any business task you care about. In 2009, I wrote a <a href="http://carymillsap.blogspot.com/2009/04/cary-on-joel-on-ssd.html">blog post that explains</a>.Cary Millsaphttp://www.blogger.com/profile/16697498718050285274noreply@blogger.com1tag:blogger.com,1999:blog-2954359812249072053.post-30591043511844272602011-11-18T20:59:00.000-08:002012-06-14T18:04:31.862-07:00I Can Help You Trace It<div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-DgjVLST0iko/TscD8rmhIJI/AAAAAAAABj8/MG5GDhl9chQ/s1600/Millsap2003-256.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="200" src="http://3.bp.blogspot.com/-DgjVLST0iko/TscD8rmhIJI/AAAAAAAABj8/MG5GDhl9chQ/s200/Millsap2003-256.png" style="border-bottom-color: gray; border-bottom-style: solid; border-bottom-width: 1px; border-left-color: gray; border-left-style: solid; border-left-width: 1px; border-right-color: gray; border-right-style: solid; border-right-width: 1px; border-top-color: gray; border-top-style: solid; border-top-width: 1px;" width="152" /></a></div>The first product I ever created after leaving Oracle Corporation in 1999 was a 3-day course about optimizing Oracle performance. The experiences of teaching this course from 2000 through 2003 (heavily revising the material each time I taught it) added up to the knowledge that Jeff Holt and I needed to write <a href="http://www.amazon.com/gp/product/059600527X?ie=UTF8&amp;tag=methodrcom-20&amp;linkCode=as2&amp;camp=1789&amp;creative=9325&amp;creativeASIN=059600527X"><i>Optimizing Oracle Performance</i></a> (2003).<br /><br />Between 2000 and 2006, I spent many weeks on the road teaching this 3-day course. I stopped teaching it in 2006. An opportunity to take or teach a course ought to be a joyous experience, and this one had become too much of a grind. I didn’t figure out how to fix it until this year. How I fixed it is the story I’d like to tell you.<br /><h2>The Problem</h2>The problem was simply <i>inefficiency</i>. The inefficiency began with the structure of the course, the 3-day lecture marathon. Realize, 6 × 3 = 18 hours of sitting in a chair, listening attentively to a single voice (<i>my</i> voice) is the equivalent of a 6-week university term of a 3-credit-hour course, taught straight through in three days. No hour-plus homework assignment after each hour of lecture to reinforce the lessons; but a full semester’s worth of listening to one voice, straight through, for three days. What retention rate would you expect from a university course compressed into just 3&nbsp;days?<br /><br />So, I optimized. I have created a new course that lasts <i>one</i>&nbsp;day (not even an exhausting full day at that). But how can a student possibly learn as much in 1&nbsp;day as we used to teach in 3&nbsp;days? Isn’t a 1-day event bound to be a significantly reduced-value experience?<br /><br />On the contrary, I believe our students benefit even more now than they used to. Here are the big differences, so you can see why.<br /><h2>The Time Savings</h2>In the 3-day course, I would spend half a day explaining why people should abandon their old system-wide-ratio-based ways of managing system performance. In the new 1-day course, I spend less than an hour explaining the Method&nbsp;R approach to thinking about performance. The point of the new course is not to convince people to abandon anything they’re already doing; it’s to show students the tremendous additional opportunities that are available to them if they’ll just look at what Oracle trace files have to offer. Time savings: 2&nbsp;hours.<br /><br />In the 3-day course, I would spend a full day explaining how to interpret trace data. By hand. These were a few little lab exercises, about an hour’s worth. Students would enter dozens of numbers from trace files into laptops or pocket calculators and write results on worksheets. In the new 1-day course, the software tools that a student needs to interpret files of any size—or even directories full of files—are included in the price of the course. Time savings: 5&nbsp;hours.<br /><br />In the 3-day course, I would spend half a day explaining how to collect trace data. In the new 1-day course, the software tools that a student needs to get started collecting trace files are included in the price of the course. For software architectures that require more work than our software can do for you, there’s detailed instruction in the course book. Time savings: 3&nbsp;hours.<br /><br />In the 3-day course, I would spend half a day working through about five example cases using a software tool to which students would have access for 30&nbsp;days after they had gone home. In the new 1-day course, I spend one hour working through about eight example cases using software tools that every student will take home and keep forever. I can spend less time per case yet teach <i>more</i> because the cases are thoroughly documented in the course book. So, in class, we focus on the high-level decision making instead of the gnarly technical details you’ll want to look up later anyway. Time savings: 3&nbsp;hours.<br /><br />...That’s 13&nbsp;classroom hours we’ve eliminated from the old 3-day experience. I believe that in these 13&nbsp;hours, I was teaching material that students weren’t retaining to begin with.<br /><h2>The Book</h2>The next big difference: <i>the book</i>.<br /><br />In the old 3-day course, I distributed two books: (1)&nbsp;the “Course Notebook,” which was a black and white listing of the course PowerPoint slides, and (2)&nbsp;a copy of <i>Optimizing Oracle Performance</i> (O’Reilly 2003). The O’Reilly book was great, because it contained a lot of detail that you would want to look up after the course. But of course it doesn’t contain any new knowledge we’ve learned since 2003. The Course Notebook, in my opinion, was never worth much to begin with. (In my opinion, <i>no</i>&nbsp;PowerPoint slide printout is worth much to begin with.)<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-7_03Lf0246Q/TscDn5732lI/AAAAAAAABj0/n4U89K2E4Sg/s1600/Millsap2011-256.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="200" src="http://2.bp.blogspot.com/-7_03Lf0246Q/TscDn5732lI/AAAAAAAABj0/n4U89K2E4Sg/s200/Millsap2011-256.png" style="border-bottom-color: gray; border-bottom-style: solid; border-bottom-width: 1px; border-left-color: gray; border-left-style: solid; border-left-width: 1px; border-right-color: gray; border-right-style: solid; border-right-width: 1px; border-top-color: gray; border-top-style: solid; border-top-width: 1px;" width="150" /></a></div>The <i>Mastering Oracle Trace Data</i> (MOTD) book we give each student in my new 1-day course is a full-color, perfect-bound book that explains the course material and far more in deep detail. It is full-color for an important reason. It’s not gratuitous or decorative; it’s because I’ve been studying <a href="http://www.edwardtufte.com/tufte/">Edward Tufte.</a> I use color throughout the book to communicate detailed, high-resolution information faster to your brain.<br /><br />Color in the book helps to reduce student workload and deliver value long after a student has left the classroom. In this class, there is no collection of slide printouts like you’ve archived after every Oracle class you’ve been to since the 1980s. The MOTD book is way better than any other material I’ve ever distributed in my career. I’ve heard students tell their friends that you have to see it to believe it.<br /><blockquote>“A paper record tells your audience that you are serious, responsible, exact, credible. For deep analysis of evidence and reasoning about complex matters, permanent high-resolution displays [that is, paper] are an excellent start.” —Edward Tufte</blockquote><h2>The Software</h2>So, where does a student recoup all the time we used to spend going through trace files, and studying how to collect trace data on half a dozen different software architectures? In the thousands of man-hours we’ve invested into the <b>software that we give you</b> when you come to the course. Instead of explaining every little detail about quirks in Oracle trace data that change between Oracle versions&nbsp;10.1 and&nbsp;10.2 and&nbsp;11.2 or&nbsp;11.2.0.2 and&nbsp;11.2.0.4, the software does the work for you. Instead of having to explain all the detail work, we have time to explain how to <i>use</i> the results of our software to <i>make decisions</i> about your data.<br /><br />What’s the catch? Of course, we hope you’ll love our software and want to buy it. The software we give you is completely full-featured and yours to keep forever, but the license limits you to using it only with one login id, and it doesn’t include patches and upgrades, which we release <a href="http://www.method-r.com/component/content/article/157">a few times each year</a>. We hope you’ll love our software so much that you’ll want to buy a license that lets you use it on any of your systems and that includes the right to upgrade as we fix bugs and add features. We hope you’ll love it so much that you encourage your colleagues to buy it.<br /><br />But there’s really no catch. You get software and a course (and a book and a shirt) for less than the daily rate that we used to charge for just a course.<br /><h2>A Shirt?</h2><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody><tr><td style="text-align: center;"><a href="http://1.bp.blogspot.com/-s7cBMkH-Nuw/TscC5Irg6KI/AAAAAAAABjs/W6xk6eCOSAM/s1600/IMG_1638+copy.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="145" src="http://1.bp.blogspot.com/-s7cBMkH-Nuw/TscC5Irg6KI/AAAAAAAABjs/W6xk6eCOSAM/s200/IMG_1638+copy.jpg" width="200" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">MOTD London 2011-09-08: “I can help you trace it.”</td></tr></tbody></table>Yes, a shirt. Each student receives a Method&nbsp;R T-shirt that says, “I can help you trace it.” We don’t give these things away to anyone except for students in my MOTD course. So if you see one, the person wearing it can, in actual fact, Help You Trace It.<br /><h2>The Net Result</h2>The net result of all this optimization is benefits on several fronts:<br /><ul><li>The course costs a lot less than it used to. The fee is presently only about 25% of the 3-day course’s price, and the whole experience requires less than ⅓ of time away from work that the original course did.</li><li>In the new course, our students don’t have to work so hard to make productive use of the course material. The book and the software take so much of the pressure off. We do talk about what the fields in raw trace data mean—I think it’s necessary to know that in order to use the data properly, and have productive debates with your sys/SAN/net/etc. administration colleagues. But we don’t spend your time doing exercises to untangle nested (recursive) calls by hand. The software you take home does that for you. That’s why it is so much easier for a student to put this course to work right away.</li><li>Since the course duration is only one day, I can visit far more cities and meet far more students each year. That’s good for students who want to participate, and it’s great for me, because I get to meet more people.</li></ul><h2>Plans</h2>The only thing missing from our Mastering Oracle Trace Data course right now is <i>you</i>. I have taught the event now in Southlake, Texas (our home town), in Copenhagen, and in London. It’s field-tested and ready to roll. We have several cities on my schedule right now. I’ll be teaching the course in <a href="http://methodr20111208.eventbrite.com/">Birmingham UK</a> on the day after UKOUG wraps up, December&nbsp;8. I’ll be doing <a href="http://methodr20111213.eventbrite.com/">Orlando</a> and <a href="http://methodr20111214.eventbrite.com/">Tampa</a> in mid-December. I’ll teach two courses this coming January in <a href="http://nyoug.org/info/training-hold/htm/NYOUG_Training_Session.htm">Manhattan</a> and <a href="http://nyoug.org/info/training-hold/htm/NYOUG_Training_Session2.htm">Long Island</a>. There’s <a href="http://mit.miracleas.dk/Kursusdetaljer.aspx?id=528">Billund (Legoland) DK</a> in April. We have more plans in the works for Seattle, Portland, Dallas, and Cleveland, and we’re looking for more opportunities.<br /><br /><table cellpadding="0" cellspacing="0" class="tr-caption-container" style="clear: left; float: right; margin-bottom: 1em; margin-left: 1em; text-align: right;"><tbody><tr><td style="text-align: center;"><a href="http://2.bp.blogspot.com/-m1lrimSlEhw/TscBSPNjC2I/AAAAAAAABjk/HV5LuvVcI3E/s1600/MOTD-Soon.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="150" src="http://2.bp.blogspot.com/-m1lrimSlEhw/TscBSPNjC2I/AAAAAAAABjk/HV5LuvVcI3E/s200/MOTD-Soon.png" width="200" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Share the word by linking the official<br />MOTD sticker&nbsp;to <i>http://method-r.com/</i>.</td></tr></tbody></table>My wish is for you to help me book more cities in North America and Europe (I hope to expand beyond that soon). If you are part of a company or a user group with colleagues who would be interested in attending the course, I would love to hear from you. Registering en masse saves you money. The magic number for discounting is 10&nbsp;students on a single registration from one company or user group.<br /><br />I can help you trace it.<br /><a href="http://www.blogger.com/"></a><span id="goog_906174057"></span><span id="goog_906174058"></span><br /><div class="separator" style="clear: both; text-align: center;"></div>Cary Millsaphttp://www.blogger.com/profile/16697498718050285274noreply@blogger.com3tag:blogger.com,1999:blog-2954359812249072053.post-77014898034975067752011-06-17T11:25:00.000-07:002017-08-11T12:33:46.519-07:00Using Agile Practices to Create an Agile PresentationWhat’s the best way to make a presentation on Agile practices? Practice Agile practices.<br /><br />You could write a presentation “big bang” style, delivering version 1.0 in front of your big audience of 200+ people at <a href="http://www.odtug.com/apex/f?p=500:420:0">Kscope 2011</a> before anybody has seen it. Of course, if you do it that way, you build a lot of risk into your product. But what else can you do?<br /><br />You can execute the Agile practices of releasing early and often, allowing the reception of your product to guide its design. Whenever you find an aspect of your product that doesn’t get the enthusiastic reception you had hoped for, you fix it for the next release.<br /><br />That’s one of the reasons that my release schedule for “My Case for Agile Methods” includes a little <a href="http://www.red-gate.com/products/oracle-development/deployment-suite-for-oracle/webinars/webinar-cary-millsap-agile">online webinar hosted by Red Gate Software</a>&nbsp;next week. My release schedule is actually a lot more complicated than just one little pre-ODTUG webinar:<br /><br /><table><tbody><tr><td class="date">2011-04-15</td><td>Show key conceptual graphics to son (age 13)</td></tr><tr><td class="date">2011-04-29</td><td>Review #1 of paper with employee #1</td></tr><tr><td class="date">2011-05-18</td><td>Review #2 of paper with customer</td></tr><tr><td class="date">2011-05-14</td><td>Review #3 of paper with employee #1</td></tr><tr><td class="date">2011-05-18</td><td>Review #4 of paper with employee #2</td></tr><tr><td class="date">2011-05-26</td><td>Review #5 of paper with employee #3</td></tr><tr><td class="date">2011-06-01</td><td>Submit paper to ODTUG web site</td></tr><tr><td class="date">2011-06-02</td><td>Review #6 of paper with employee #1</td></tr><tr><td class="date">2011-06-06</td><td>Review #7 of paper with employee #3</td></tr><tr><td class="date">2011-06-10</td><td>Submit revised paper to ODTUG web site</td></tr><tr><td class="date">2011-06-13</td><td>Present “My Case for Agile Methods” to twelve people in an on-site customer meeting</td></tr><tr><td class="date">2011-06-22</td><td>Present “My Case for Agile Methods” in an <a href="http://www.red-gate.com/products/oracle-development/deployment-suite-for-oracle/webinars/webinar-cary-millsap-agile">online webinar hosted by Red Gate Software</a></td></tr><tr><td class="date">2011-06-27</td><td>Present “My Case for Agile Methods” at <a href="http://www.odtug.com/apex/f?p=500:420:0">ODTUG Kscope 2011</a> in Long Beach, California</td></tr></tbody></table><br />(By the way, the vast majority of the work here is done in <a href="http://www.apple.com/iwork/pages/">Pages</a>, not <a href="http://www.apple.com/iwork/keynote/">Keynote</a>. I think using a word processor, not an operating system for slide projectors.)<br /><br />Two Agile practices are key to everything I’ve ever done well: <i>incremental design</i> and <i>rapid iteration</i>. Release early, release often, and incorporate what you learn from real world use back into the product. The magic comes from learning how to choose wisely in two dimensions:<br /><ol><li>Which feature do you include next?</li><li>To whom do you release next?</li></ol>The key is to <b>show your work to other people</b>. Yes, there’s tremendous value in practicing a presentation, but practicing without an audience merely reinforces, it doesn’t inform. What you need while you design something is information—specifically, you need the kind of information called <i>feedback</i>. Some of the feedback I receive generates some pretty energetic arguing. I need that to fortify my understanding of my own arguments so that I’ll be more likely to survive a good Q&amp;A session on stage.<br /><br />To lots of people who have seen teams run projects into the ground using what they call “Agile,” the word “Agile” has become a synonym for sloppy, irresponsible work habits. When you hear me talk about Agile, you’ll hear about practices that are highly disciplined and that actually require a lot of focus, dedication, commitment, practice, and plain old hard work to execute.<br /><br />Agile, to me, is about injecting discipline into a process that is inevitably rife with unpredictable change.Cary Millsaphttp://www.blogger.com/profile/16697498718050285274noreply@blogger.com5