Why NOT Having Goals is a Bad Idea

Recently, Leo Babuata (whom I normally greatly admire) had a guest post on why goals are a bad idea. This is an idea that seems to be growing; Leo wrote about achieving without goals in November in 2010 and another guest poster wrote about it in December of 2011. Leo’s first post about it may be the one from July of 2010. These posts on rejecting goals get me angry, honestly: they are a prescription for aimlessness and drifting.

The problems they list with goals are:

• Goals are fixed and inflexible.
• Goals require you to give up what you want now.
• Goals require pain.
• Goals are limiting.
• Goals missed are the system’s fault.

Goals are objectives, targets, endings, and aims: without these, we do not know where we are going. When our directions and passions change, so does our goals. Changing our goals should not be seen as weakness, but strength: goals should be continually revised for our current desires.

Sometimes a goal is to give something up that we are doing now, to make a change. Giving up smoking or a constant soda pop habit is hard – and will cause pain. Yet, the giving up of the pleasure of a smoke now will add years to your life down the road and give your children more time with their parents.

However, this is not because of the goal: a goal can be positive as well: exercising daily, reading more, learning to fly, learning a new language. Goals give you direction and provide you with a marker to strive towards.

When we miss the target, we should look inside ourselves as to why and without feeling guilt. Was the goal a badly specified goal? (Probably.) Does it match our desires and passions? Most people have vague goals that are designed to be broken, and that will lead to failure sooner or later. Confucius said this:

In archery we have something like the way of the superior man. When the archer misses the center of the target, he turns round and seeks for the cause of his failure in himself.

Just don’t feel guilt about a missed goal: throw the goal out and make a new, more realistic one – one that is specific, measurable, attainable, and focused more on changing your daily habits. Switch from a goal of “Lose weight” (vague and impossible!) to “Lift weights daily.” Don’t measure output, don’t measure weight, just “don’t break the chain” – keep it up one day after another. If you get a daily habit like that, the weight will come off.

If you don’t have goals you can’t plan. Living with out a plan leads to lack of ambition and lack of direction. What do you want to achieve? Then figure your action steps – or better yet, daily habits – that will get you there. Accomplishing your goals – your end results – can only be done by first defining the objective, then using habits and actions to get there. If you’ve no goals, then you have nothing to accomplish – and that results in no accompilishments.

Leo presents this quote at the end of his July 2010 article:

A good traveller has no fixed plans, and is not intent on arriving. — Lao Tzu

I would counter this with some other quotes. Consider this one (emphasis added):

In all things success depends on previous preparation, and without such previous preparation there is sure to be failure. If what is to be spoken be previously determined, there will be no stumbling. If affairs be previously determined, there will be no difficulty with them. If one’s actions have been previously determined, there will be no sorrow in connection with them. If principles of conduct have been previously determined, the practice of them will be inexhaustible. — Confucius

Also, from Alice’s Adventures in Wonderland (one of my favorite books!), comes this delightful snippet:

“Would you tell me, please, which way I ought to go from here?”
“That depends a good deal on where you want to get to,” said the Cat.
“I don’t much care where–” said Alice.
“Then it doesn’t matter which way you go,” said the Cat.
“–so long as I get SOMEWHERE,” Alice added as an explanation.
“Oh, you’re sure to do that,” said the Cat, “if you only walk long enough.”
(Alice’s Adventures in Wonderland, Chapter 6)

To accomplish our goals, I recommend defining the goal using what David Allen calls “envisioning wild success” and “outcome visioning”. Then figure what daily habits and other actions will lead you to the end result.

There are programs to help with daily habits and I highly recommend using one of them. My favorites are Sciral Consistency for Macintosh and Habit Streak for Android.

Making the Case for IPMI

IPMI is a system that allows you to maintain a system where it would not otherwise be able to. However, you have to convince others that it will be useful. As obvious as it is for a professional system administrator, there are others who will not see the usefulness of IPMI. This process – making the case for a technology – comes up more than most system administrators might realize.

There are numerous situations that require having a person to be actually present at a machine to do things – such as entering the setup, accessing the UNIX/Linux maintenance shell, changing boot devices, and so forth. So how do you prove how beneficial implementing full IPMI support is?

Provide a business case – and perhaps an informal user story – to show how IPMI can reduce the need for a person to actually be present.

To really make the case for IPMI, compute the actual costs in making a trip to the data center – the hourly cost of the administrator, the driving costs in gasoline (both to and from!), and the costs associated with handling the expense report. Report the other unquantifiable costs – the cost of an administrator unavailable for other tasks during the four hour round trip, including projects being delayed and problems not getting resolved. Combine this with a user story.

For example, create a user story around a possible kernel panic. A user story requires an actual user – an individual – whose story is followed. Here is our example continued as a user story:

Alma received an email that a system (db20) was unresponsive. Checking the system found that there was no response from the network at all, and checking the KVM showed that there was a panic on the display. No keystrokes were accepted by the system, and there was no way to power-cycle the system.

So Alma sends an email stating that she will be unavailable for the rest of the day, and calls her babysitter to take come and take care of her three children for the evening. Then she gets into her car and drives the two hours to the data center and parks in a lot ($10 for one hour). She power-cycles the machine by pressing its front panel power button, and checks the system response using her laptop. She finds that the server is responding and logs in.

Then Alma checks the server: logs show no problems restarting, the system has restarted cleanly, the subsystems are all running, and the monitoring system shows all systems are good.

Alma leaves the data center and drives the two hours back home.

If Alma is paid $60,000 yearly, the cost of her time spent on this event is US$144.23. If she drove 320 miles round trip at .76 cents a mile, she gets US$243.20 as an expense – in addition to the US$10 in parking fees. This makes a total direct cost of US$397.43.

If something like this happens six times a year, then the total yearly cost is US$2384.58 – and total downtime for the server is 24 hours for an uptime rate of 99.72%.

This account doesn’t include the indirect costs – such as projects being delayed because Alma was unable to work on them, nor does it include the personal costs involved such as babysitting and time away from family. It also doesn’t include the time that HR staff spent on yet another expense report. It also doesn’t include the costs associated with the server being unavailable for three hours.

On the other hand, Polly received word that another server in the data center was unresponsive, and also found that the kernel had panicked and there was no response from the console. She then used a command line tool to access the baseboard management controller (BMC) through IPMI. With an IPMI command, she rebooted the server, and watched the response on the KVM. Checking the system over, Polly found that the server had booted cleanly, subsystems were operational, and all looked good.

If Polly is paid the same amount as Alma, and her response took 15 minutes, we get a total cost of US$7.21.  Downtime was reduced by 92% (along with an associated reduction in costs tied to the server being down). If this happens to Polly six times a year, the total yearly cost is US$43.27 – and a downtime of 1.5 hours for an uptime rate of 99.98%.

Thus, IPMI and SoL would have saved Alma’s company US$2377.37 per year.

The strongest case can be made if a recent event could have been solved with the technology you are proposing. If you can point to a situation that could have been resolved through ten minutes instead of hours or days without – then the usefulness of the technology will be apparent.

With this user story and business case, the case for IPMI should be readily apparent to just about anybody. Similarly, the case can be made for other technologies in the same way.

Making Changes One Small Habit at a Time

I’ve been reading a book titled small change: Little Things Make a Big Difference and have enjoyed it tremendously. The book is written in a conversational style, with a couple as narrators.

The book focuses on the Japanese concept of kaizen, although they don’t really talk about kaizen very much. The idea is that we should make one small change each month, and do this on a regular basis. With a small change, it becomes a habit and can have a dramatic effect on the rest of our lives.

As an example, let’s say one changes from a soda a day to a glass of water every day. If you have a 12oz. soda (at US$1) each day – and switch to visiting the bubbler – then you will save US$365 in one year, and US$1825 in five years. What would you do with all that money?

Taking the same switch as an example, you would also save 140 calories each day – or 51,100 calories a year – or 255,500 calories in five years.

When you try to do too much, you can become overwhelmed and your attempts then suffer across the board. You find that you are failing in one area, and the negative reaction spills into all of the other habits you are trying to create – and none are successfully created.

Also, when you have several habits going at once, you may find that you are improving slightly – across the board – but not in any one area. None of the habits take, because you keep switching one habit for another and never completely creating a new habit.

When you succeed in one habit, the drive will propel you to succeed in another – and another.

Jason Thomas wrote an article in Lifehacker titled Practice Your Personal Kaizen which covers some of these areas. Leo Babauta in his book Less also covers the concept of changing just one habit each month. A related book (which I want to read) is One Small Step Can Change Your Life: the Kaizen Way by Robert Maurer.

What new habit are you going to create this month?

Converting VOC Audio Files from Digital Recorders

The VOC file format is already not a common format, and it can be difficult to find players for VOC files. RCA went one step further: the VOC files generated by RCA digital recorders are not recognized as the original standard VOC format created by Creative Labs. One of the problems people experience with the RCA format is that none of the multimedia players will play them – and virtually none provide any useful information about the actual cause of the failure.

There is a utility available from Dave Coffin (devoc – with source) which will convert VOC files to 16-bit uncompressed WAV files. The conversion can also be done online, driven by Dave’s utility devoc.

Using devoc takes a little more work than just installing a program (unless you are using Windows – there is a binary available for Windows). These steps should get you a working binary in Linux or other UNIX environment:

wget http://www.cybercom.net/~dcoffin/rca/devoc.c
gcc -o devoc devoc.c
sudo cp devoc /usr/local/bin
devoc -p myaudio.voc

It may also be necessary to make sure that Sound Exchange (or SoX) is installed before running gcc.

Alternately, if you have the RCA software installed (in Windows only, of course) then the software can be used to convert to a different format. Unfortunately, the conversion is performed on a single file at a time – but if you’ve only a few VOC files, this would work just fine.

If you want the UNIX utility file to recognize the VOC file format, add these lines to /usr/share/file/magic:

0 string Creative\ Voice\ File VOC audio file (Creative Labs format)
6 string _VOC_Filex VOC audio file (proprietary RCA format)

To activate the changes, do:

file -C -m /usr/share/magic

An example run then gives you this:

$ file *VOC
A0000052.VOC: VOC audio file (proprietary RCA format)

Why isn’t the RCA VOC format recognized and played or converted by generally available open source tools? Who knows?

Want to avoid these problems? Get a different recorder that supports MP3 or WAV or WMA; there is a decent review of USB-based digital recorders at HubPages.

No matter which one you get – be sure to review your notes daily and put the todos into your system.

A Novel Method of Filing

When it comes time to organize files, the common wisdom (and good advice, too) is to put everything together in a file cabinet in alphabetical order. No matter the subject, put the files in alphabetical order by their title.

Then when you need a file, you can get it out of the file cabinet, and put it back when done. When you choose the file titles wisely (usually by picking the first thing which comes to mind as a topic), this works well.

However, I added another step in my system that seemed to work and work quite well. When you take out a file folder from the file cabinet, instead of putting it back, put it in the front of a small file drawer. Even though this goes against the recommendation to sort alphabetically, what happens is the smaller file drawer is then sorted by frequency of use. The most often used files will be toward the front of the drawer.

Then, from time to time, take the files out of the back of the drawer (that is, the oldest files and least used) and put them back into the file cabinet.

These added steps mean that your file drawer is automatically filled with the most often used files, and the file cabinet is much easier to weed out and is also less often used in favor of the file drawer (which is normally closer).

Try it and see if I’m right…

How Systems Fail (and Principles of Prevention)

A system failure does not always have a single, identifiable (and preventable) cause. In fact, often it does not.

The BP oil spill provides an excellent case study of this situation: the spill has numerous contributing causes, most of which seem minor or unlikely in isolation, but which taken together resulted in catastrophe.

What general principles can we apply to prevent such cascade failures? One should already be familiar: Test, test, test fail-over systems before they are needed. Without testing, there is no guarantee that things will work as expected. In the BP oil spill, several failsafe systems did not properly engage as expected. In the recent IT disaster in Virginia, a storage system did not fail over when needed, resulting in a down-time of several days for a significant portion of state resources.

Another principle is: Sift and winnow alarms to the truly necessary. Pay attention to alarms and other indicators, and to purge alarms and notifications that are irrelevant or unnecessary. In the oil spill, one of the causes was that the indications that there was an immediate problem were masked by other occurrences at the time. Too many alarms and too much information can hide problems and lead to administrators ignoring problems that require intervention.

To improve alarms, and prevent unnecessary alarms, use time based alarms, i.e., alarms that account for change over time. Products such as SGI’s Performance CoPilot (PCP), HP’s Performance Agent (included with some versions of HP-UX), and the System Event Correlator (SEC) all help. With alarms that work over a time-span, momentary brief peaks will not result in alarms, but chronic problems will.

Another item that can improve alarm response is systemic alarms: that is, monitoring that accounts for multiple systems or processes, and combines it all into an appropriate setting. Is the web site running smoothly? Are all systems reporting logs to the central server? Are all virtual environments running?

One of the earliest problems that lead to the oil spill was a lack of oversight of the contractors involved in building the well. Each assumed that the others would do the right thing. In system administration, we assume that other systems are functioning correctly. To prevent failure, we should assume that other systems and processes could fail, and verify for ourselves that the systems we are responsible for will not fail in any case. What systems are you dependent on? Power? Cooling? Serial concentrator? Operations staff? Backup staff?

Part of the problem in the Virginia failure was that the state did not oversee the external vendor well. With proper oversight (and demands), the state IT staff could have forced the storage vendor to test the fail-over processes, and could have implemented a backup plan in case the fail-over did not take place as expected.

By studying other’s fail patterns and experiences, we can help to minimize our own.

The Organized Mindset: How to Stay Organized in 5 Steps

Recently, over at the Clutter Diet, Lorie Marrero had this to say:

People always ask me this question: “If there were just one small step I could take to get more organized that would have the most impact, what would it be?”

Often people are looking for a “tip” or some kind of expert trick, but my most authentic and accurate answer is to change your mindset.

I agree entirely. Change your mindset and you can stay organized. Many organizational “tips” are just about how store all of your stuff, or how to get rid of stuff – or how to psychoanalyze yourself and correct your organizational failings by psychotherapy. I believe that the most practical is the down-to-earth daily habit changes that will get you organized and keep you organized.

However, in her article, Lorie’s choices just don’t mesh for me; I’ve some of my own ideas. Also, these are not just ideas – but mottos to remember and apply. See if these don’t change your life:

One in, one out. We “collect” stuff; as long as more stuff is coming in than going out, we’ll keep gaining more stuff. To reduce, make it one in, six out…

“Where will I look for this the next time I need it?” If you apply this regularly, you will start finding things instead of looking for things. Every time you put something away, think of this question – and apply it.

Every time you leave a room, take something with you. This will whittle away at the dirty stuff in a room. Don’t leave a room empty-handed.

If it’ll take less than six minutes, do it now. David Allen’s GTD has the same rule, but he uses two minutes instead. Either way, this will whittle away at your to do list.

If you haven’t used it in six months, toss it out! If you haven’t used something for that long, when will you use it? You’ve not missed it, and you’ve not used it. So go ahead and toss it out or give it to good will.

If you start to indoctrinate yourself with these mottos, and apply them in your daily activities, the organization in your life will reach new heights.

For further steps in organizing, I recommend Organizing Your Life and Getting Rid of Clutter (by Carla Wolfe and DeLynn Copely) and Sink Reflections (by Maria Cilley). Both of these are very practical guides to daily organization; adopting their methods will help you stay organized.

Refining and Perfecting Your To Do Lists

What could be easier than a checklist? Before answering, consider that aircraft manufacturers spend years getting the checklists for their aircraft ready, and have entire divisions dedicated to checklists.

The answer, it turns out, is not so simple. Atul Gawande wrote a complete book about it: The Checklist Manifesto. This book is a very good read, and will change how you look at checklists.

Recently, Sarah Welch and Alicia Rockmore had a post over at the Clutter Control Freak Blog about Effective To Do Lists.

What makes a To Do List – or checklist – effective?

Everything in one place. This way, you know where to find what to do next. Don’t have multiple todo lists.

Update frequently. If things are missing from your todo list, then you won’t refer to it – or if you do, these things to do will be forgotten.

Access daily. Refer to the list every day – preferably first thing in the morning. If you do this, then you’ll be able to keep up to date with what is going on and what needs doing.

Write down actions. Don’t put big projects into your to do list – write down only actions that can be done. For example: “Get tires” is too big (unless all you have to do is go get them). Where will you go? Will you call many stores to compare? What size will you get? How many?

Revise often. Perhaps the things that are on the list are no longer to be done; remove them from the list. Your list should be current at all times.

If you keep your to do lists “alive” and active, then your ability to act on them increases and you can get a lot more done.

Drunk or Tired? No Difference!

As system administrators, the occasional all-nighter is necessary to fix things that go wrong. We also know that the majority of errors can be traced to human error – including those that affect server stability.

A recent article equates a lack of sleep to being drunk – specifically, a 24-hour wake cycle is equivalent to a blood alcohol level of 0.1. This is not good – not at all.

If we consider this fact, and expect that mistakes are very likely after 24 hours of being awake, then we must act. What can we do as system administrators when we work an all-nighter?

• Take a nap. A small nap – from 15 minutes to an hour – can revitalize you and help you to minimize errors.
• Have a coworker check your work – or work with you. Having someone to check your work will make a finer net whereby each of you can check the other’s work.
• Take an extended nap or sleeptime. For example, take off the day of an extended maintenance schedule – or go to sleep at the end of the day and wake up hours later for maintenance (if it is scheduled for late at night).

In short, it is primarily about getting enough sleep. Finding ways to minimize errors or catch errors is good, but never as good as getting enough sleep in the first place.

Life and Work with an Ubuntu Linux Laptop

I’ve been using a Ubuntu Linux desktop for over a year, and haven’t regretted it. The experience is beautiful and cost-effective.

I’ve learned to use Linux for everything. I used it to maintain HP-UX systems via screen and ssh; I’ve used it to write articles here using browsers like Firefox and Google Chrome or editors like BloGTK.

One of the nice things about Linux (in contrast to OpenSolaris, for instance) is that an installation of Linux has everything it needs on disk to work in any system. Moving the hard drive from one system to another causes no difficulty as the appropriate drivers are loaded as needed. This allows things like moving a virtual environment to a physical environment without problems.

Nothing is perfect, however. In running Ubuntu, it seems that the six-month turnaround leads the developers to push off fixes until the next release. I am also finding that there are many bugs in new releases of Ubuntu; the latest Lucid Lynx showed about a half-dozen bugs within the first day’s operations. Recently an article (and follow-up) expounded on the poor bug-fixing process in Ubuntu, with the author Caitlyn Martin blaming the six-month cycle – and pointing out that several Ubuntu-based distributions were changing to Debian instead. She wasn’t the first; Christopher Smart bemoaned Ubuntu stability in an article back in November 2009.

I’ve not had a lot of problems, but some. One was that my USB 2.0 device refused to work with Karmic. The solution was to stop using EHCI (yow!) but that could not be done because the kernel for Karmic has EHCI builtin, and EHCI could not be disabled. Another was bzflag, which died with a segmentation fault in Karmic and refuses to run in Lucid.

For my part, I would not only make the same recommendations as Caitlyn Martin, but would add one more: test on as many different kinds of machines as possible, specifically including older machines and strange machines as well. With better testing, most of the hardware related problems could be eliminated. This includes testing with add-on hardware as well.

I’m probably going to reacquaint myself with OpenSUSE again – though Debian does have the best LISP support on the planet… but then, trying different distributions is part of the fun of it.

Living with Linux is definitely possible; working with Linux is only slightly harder – but it can be done, and is worth it.