Tod means Fox

It is (or should be) common knowledge that you should never send an email, write a blog or forum post, or make a phone call when you’re totally ticked off about something! You are likely to say something you don’t mean or perhaps you’ll be a little too honest.

First cool down, and then respond. Easy enough, but what if you can’t wait to cool down using traditional methods (you know like, take a long hot bath)?

The solution: Simply write your name a few times on a piece of paper using your non-dominant hand. Apparently, it will force the logical side of your brain to start working, giving your emotional side a few seconds to forget why it is so upset (or sad, or excited, etc.). For all the neurosurgeons out there who might want to debate brain lateralization, I’m not the guy for you! But this technique has worked many times for me (and it recently got my sister-in-law out of a funk).

Over the past several days, I’ve also been looking into other ways to train my brain to either help in logical tasks, management tasks, programming, motivation, etc. I stumbled upon a blog entry (from Gary’s Historical Art) that spoke of the book “Drawing on the right side of the brain“. I remember this book from my childhood and was thrilled to see it has a new addition. It contains some additional information on (a) the latest developments in brain research, and (b) information on using drawing skills for problem solving. I plan to get a copy soon.

In the book “The 80/20 Principle: The Secret to Success by Achieving More with Less“, author Richard Koch describes how a minority of “causes, inputs, or efforts” will lead to the majority of “results, outputs, or rewards”.

A great demonstration of how the 80/20 Principle (aka Pareto’s Law) works can be seen through examining source code. Clearly, a small minority of code in an application produces the vast majority of business benefit to the user. Usually, this code is well defined, tested, and performs great — after all, it is the core of what the application does. Once in production, this code is low maintenance. Any changes or enhancements are usually well scrutinized and will be tested thoroughly. Your applications are bought based on this core minority of code.

Then there’s the other code.

The other code plays more of a supporting or supplemental role: It’s the code that handles your ultra-cool menu system; It’s that extra group of reports that seldom get run; It’s that cool Calendar control that seemed like a good idea at the time; It’s all the extra features that you’ve tacked on over the years. This vast majority of code contributes least to the business needs of the application, costs you the most money to maintain, and is likely to contain the most bugs.

So what’s a developer to do?

Surely bells and whistles, gold plating, and other extras help sell the product. So I am not an advocate of stripping software down so that it is only functional. Software users expect to have a somewhat enjoyable experience behind the keyboard. Boring, functional applications would look a lot like a dos window and be the subject of many scornful conversations at the water cooler.

Instead, get the most bang for your buck. Identify the 20% and expand it. Identify the 80% and depreciate it. Revisit and repeat at each release cycle. Easier said than done? I’ll give you an example:

80/20 In Action

The volume of user reports in a mature application can get out of hand. I’ve worked on Applications in the past that have had more than 100 user reports. One day I wondered (out loud to my coworkers) which reports were actually being used. No one truly knew the answer, but we all had a hunch that the answer was “not many”. So, I added a secret logging script in my report class that logged report usage to a flat text file stored in the root directory of the application. I stored the report name, the user, and the timestamp. We retrieved the file when dialed in for support services. I found that out of 130 custom reports, only 6 were being used on a regular basis at about 100 installed locations, and a whole 50% of the reports were never run at all over the test period (11 months).

Whoa. Consider now that we spent time regression testing these reports during our latest release, that we regularly trained our users on how to run them, and that they are all included and dutifully updated in our documentation. Bad management? Poor software design? Scope bloat? Or just a perfect demonstration of how the 80/20 Principle works in software development: you decide.

The solution in this example was simple: We stopped supporting the unused reports (we continued to monitor the usage logs) and would not add any new reports without careful consideration. It felt good to trim the fat and in the end, we saved ourselves a considerable amount of work.

80/20 Analysis

During the different release periods of the software life cycle, an 80/20 Analysis should be done to both identify the core minority and the excess majority. Start with actual features (User Reports, Ad hoc Reports, Custom Query Engine, the Internet Backup Utility, Etc.) and then drill down into each feature and look for low hanging fruit. Once identified, monetize its impact on your engineering, quality, and client services teams. Also, place a value (using real sales dollars if available) on the feature itself.

This kind of analysis should reveal some interesting things about the software. If there are gray areas, for example if you are unsure of what is being utilized, consider doing something like I did to track report usage. Coverage profiling engines will allow you to identify seldom run or never run lines of code. These areas might give you clues as to what code will buy your house or pull you under. You can create a simple but professional survey on your website and ask your users what features they find most helpful and which features they don’t use. Not only would this survey tell you what is not being used, but it could also help you identify areas where you can increase the 20%.

For more information on the 80/20 Principle, I invite you to pick up Richard Koch’s book at Amazon. Have a read, and share with me your thoughts!

Buy The 80/20 Principle: The Secret to Success by Achieving More with Less now at Amazon.

I wanted to take a moment to introduce a new section on Tod means Fox: Whitepapers.

This page lists articles, whitepapers, memos, and other documents that address a business need, offer advice, breakdown a process, or otherwise present some technical overview. I was tempted to add these items to my Resources page, but in the end determined that separating articles from resources was a good idea. I generally define a resource (such as the FoxPro Wiki) as a conglomerate of information.

Currently, the items on this page were pulled from my Firefox bookmarks and are subject to change.

My hope is that you will have some good suggestions on what should be linked here. Contact me (privately via email at tod at grengama dot com), or by commenting to this post with your suggestions. The only rule is that when a reader clicks on a link, there is no registration or sign-up process: just the article. It would be even better, if you are a copyright holder, to let me host the article or whitepaper on my server — repackaged and refreshed.

I hope you all find this new page useful.

Or as I like to say, my “easel’s broken”, because it helps me remember how to pronounce it. Which is funny because ezelsbruggen, in dutch (and German too, I think), translates into “donkey bridges” (according to the Internet and my wife). A donkey bridge is a memory technique for creating visual bridges between disparate words. In English, the translation is “memory aid”, or “mnemonic”.

Whether you have a rat in separate, your princiPAL is your PAL, or your committee does nothing but mutter mutter, talk talk, and eat eat, donkey bridges are quite handy. They help you remember little bits and pieces of information, like the form instantiation order in FoxPro (the lovely Lisa G.). Oftentimes donkey bridges are illogical, arbitrary, and downright silly — but they always seem to work. Who is this Lisa G. anyway?

So, here is a list of some of the mnemonics — Ezelsbruggen — that I have learned over the years. If you have any fun or interesting ones, please share!

• LISA G.
  Load, Init, Show, Activate, GotFocus
• Lucky Cows Drink Milk
  The order of Roman numerals (ascending): LCDM
• Please Excuse My Dear Aunt Sally
  Parentheses, Exponents, Multiplication, Division, Addition, Subtraction.
• My Very Educated Mother Just Served Us Nachos
  There are only eight planets now! Sad… but true.
• Better Be Right Or Your Great Big Van Goes West
  Ohms value for the color bands of resistors (Black, brown, red, orange, yellow, green, blue, violet, gray, white).
• Silly People Drive Fast
  Spectroscopic notation, after F, the rest is alphabetic

So here I am in a canoe in the middle of the Atlantic Ocean, drinking the salt water out of a coffee filter. Smoke from my hibachi is getting in my eyes as my veggie burgers begin to burn. Although I’m ankle deep in plums, I manage to toss Ben and Jerry overboard so they can fix the motor, which is nothing more than a dust buster turned from suck to blow.

That, my friends, was yesterday’s shopping list. Poland Springs, coffee filters, veggie burgers, plums, ice cream, and a new hand vacuum. If I don’t create an absolutely absurd story, I’m liable to forget something without a list.

Method of Loki

Another great way to remember sequences and lists is employing the Method of Loki. In its most basic form, you simply find a location you are familiar with in your head (your bedroom, office, kitchen, etc), and begin placing things inside the room. It’s a method many use for giving paperless speeches or for remembering meeting agendas. For example, in my office, I may see the head of the research department typing away at my computer, a spinning globe just off to her right, and a bowing shelf of paper documents within arm’s reach. This will remind me to discuss the new research project, segue into our International strategy, and finally end by discussing a much needed content management solution.

These and other such techniques for remembering items, spellings, sequences, etc, have been a big help for me. In the health care industry, I’m often required to remember many acronyms, processes, and procedures that are quite foreign (I have no medical background whatsoever — unless you count years of watching ER). The same might be true for you as well.

Now if you’ll excuse me, I need to see the quill from behind the tall man who’s sitting on a beanbag chair fiddling with a rubix cube.

I’ve always wanted to make a ‘Top 7′ list.

Most of our time is wasted away throughout the day on trivial and unimportant tasks. Some of this is busy work that we create, while other things creep in unexpectedly. Here is a list of seven things that I feel will increase your productivity during a typical workday. Let me know if you think I’m missing or over-emphasizing something. I’m always looking for ways to improve my effectiveness and efficiency; to do more with less.

1.) Find your most productive time
Some developers prefer to work through the night. Most CEOs start their day before 6am. Find your sweet spot and plan your day around this block of time. From what I’ve read, this block of time varies from 4 to 7 good hours. Mine happens to be from about 5am through to 11am. After this, my concentration wanes and my patience thins (until I get home from work, at which time I’m re-energized).

2.) Identify critical tasks
List your most critical tasks for the day, and do them first. Critical does not mean most difficult. Critical tasks may be the easiest and quickest tasks of your day. Perhaps it’s as simple as calling back an important client, or a more difficult task such as finally fixing that nasty bug that’s hard to reproduce. I find that making this list the day before helps me to get started the next day much quicker.

3.) Avoid distractions
Distractions can really lead you astray and spell disaster for your carefully planned schedule. Avoid these things, especially when in your most productive block of time, and certainly while you are completing your critical tasks. Because I spend a large part of my workday in a cubical, and cubes are distraction magnets to begin with, I’m often inundated with visitors who have come by for various reasons (few of them have any relevance to my current tasks). To help combat this, I will often put headphones on to deter all but the most important guest.

I consider mail (e-, voice-, and snail-) a distraction. Very few actual mail items require my immediate attention throughout the week. I suspect you’re in the same boat. So, Manage your mail wisely. Set aside specific time for reading and responding to mail in all its forms. This is especially good advice for email. Never look at email during your most productive time. And please, turn off the automatic notification and get rid of that envelop icon that Outlook puts in your tray. Every email that hits your Inbox is a potential detour. To combat this, I try to tackle email first thing in the morning (5am), with 2 additional checks throughout the day (10am, 3pm-ish). I will only open Outlook during these times.

4.) Automate as much as possible
Automation is the key to more productivity. The more you can automate, the more time you can spend on important tasks. For years I had been manually making additional ’sanity’ backups of my source code (above and beyond VSS and normal backups). Finally, I woke up and realized that this (and many other things) can be automated. You can be fancy and schedule a backup through some backup software, or be simple and create some .bat files to do the heavy lifting. Sounds simple enough. This is just one example. There are potentially hundreds of tasks you can automate.

5.) Apply Pareto’s Law
Otherwise known as the 80/20 principal (or rule), this law states that 80% of the effects comes from 20% of the causes. The vital many verse the trivial few. Learning how this works can be like hiring a new employee (a better you) and firing that resource hog (the old you). Find out what busy work you’re doing and eliminate it. Identify the work you do that produces the best results, and capitalize.

6.) No more multitasking
Despite popular belief, multitasking breaks concentration, causes distraction, and inevitably costs you time and money. This is especially true of technical work, like software development. Shutdown your Outlook, your Accounting software, your Internet Browser, your News Aggregators (you can leave mine on, though ;-)), etc. Focus on the task at hand, complete it, and move on.

7.) Ergonomics are your friend
Get comfortable and put a greater focus on your work environment. It should be healthy, comfortable, and safe. Stand up once in a while to stretch and relax your hands, wrists, and neck. You can loosen the kung fu grip on your mouse, flatten your feet on the floor, adjust the top of the monitor to be at eye level, and do many other things to improve your condition. I’m terrible at all of this: I seldom get up, I sit Indian-style, and my dual monitors are angled and a little high. But I have seen others recover from this and start on the path of a more ergonomic-enriched existence. Being comfortable helps you to be productive.

Do you have productivity advice? Is there anything missing form my list?

I’ve left Blogger and Windows Live Spaces for my own domain, more control, and greater flexibility. I hope you all like the new digs. My intention now is to grow this site by including some downloads, more resources, and additional FoxPro and Business Intelligence information.

So please, take a moment to update your RSS feeds to my new one: http://blog.todmeansfox.com/feed and your Bookmarks (use one of the Social Bookmarking links on the right-hand-side if you want).

And, feel free to contact me (todatgrengamadotcom) if you have any comments or questions!