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.

Building a Checklist

When you are undertaking an invasive and complicated process, you should have a checklist to go by. This will help you make sure you cover all the bases and don’t forget anything. I’ve written about this before.

However, how do you build a checklist that will be of the most assistance?

First, “build” is the right term: in the days or weeks leading up to your process (system maintenance, for example), come back to the checklist over and over. Review it several days in a row, or better yet, several times a day. You’ll think of new things to add to it, and you’ll be fleshing it out until it is comprehensive and complete. You might want to leave it loaded in your workstation so you can come back to it whenever the mood strikes.

Secondly, break the checklist down into major sections. For example, in patching a system you might have sections for: 1) preparing the system; 2) patching the system; 3) rebooting the system. Other processes will have different major sections. These major sections should be set apart on your checklist, preferably with titles and bars that segregate the checklist into its component parts. I recommend a different color background and a large bold font to set it apart.

Thirdly, there should be a “point of no return” – which should be at a major section break. This is the point where you cannot turn back and return to the way things were. At this point during the process, you have to choose: have things gone smoothly enough that completion is likely – even inevitable – or is the process in such disorder and disarray that a return to the status quo would be better? At that point, one must choose.

With such a checklist, your process will be much smoother, and you won’t have to explain to the boss why you missed something critical. It’ll also document what you did (along with the notes you take).

Disaster recovery planning

Planning for a disaster is not necessarily as easy as it sounds. It helps if you have a rampant imagination. Throughout disaster planning, the dominant question is What if…? Following the planning, testing is required: the best plans are worthless if they don’t work in practice.

Consider an Internet server serving web pages. Let’s assume that downtime is not an option: this is a typical point to start at. The best thing to do is to start with the most specific to the system (the complete environment) and work out:

  • What if… a disk goes bad?
  • What if… the software stops?
  • What if… memory runs out?
  • What if… the power goes out?
  • What if… the kernel panics?
  • What if… the cluster failover fails?
  • What if… the network switch fails?
  • What if… the network firewall fails?
  • What if… the internet link goes down?
  • What if… the internet provider drops off the grid?

Each one of the questions must be answered and the results tested. To test for power outage, pull the power. For a failed network switch, pull the network cable – and so forth.

Most of the answers will include some form of redundancy – clusters, dual facilities (such as power and network and internet providers), and so on. However redundancy is only one solution; there is prevention and alerts as well.

Each risk must be weighed against the cost to mitigate that risk. However, assuming that the risk is minimal does not eliminate the risk; the biggest problem is not accounting for a risk that eventually happens. There is nothing like downtime of a critical server to get an unforeseen risk taken care of; better to handle the risk before it happens.

It also does not matter if the plans have not been tested. If tests are not done, then the actual event will be the first time things have been put to the test – and what if something was missed and the system goes down? During a test, preventive measures can be taken to make sure that things work as they should – during an unexpected event, it is not possible to back out or prepare; if things go down they go hard. Don’t let that happen to you!

And disaster planning is not limited to servers (or virtual servers) – what about the possibility of a server hosting multiple virtual servers going down? What if your server is hacked into? What about your monitoring system failing? What about getting paged? Have you planned contingencies for all of these events?

Plan, then test, test, test – and you will make it.

Planning for a system outage: 8 ways to make it easy

When I worked for a cabinetmaker for a number of months, I asked him about the various tools available and about which ones he used. One thing he said a lot was “that brand is okay, but in a production environment it won’t last.” That is, the cabinetmaking shop would go through the lightweight tools quickly and was different than a home woodworker.

So it is in system administration. When you have users counting on a system to be up, even a planned system outage is going to be extremely unpleasant and costly. Add up the cost of every worker not being productive, projects delayed, overtime paid, and so on. If the planned outage then becomes even longer than expected, you can see the costs begin to add up.

Thus, there are a number of things to keep in mind that would not matter in a non-production environment – an environment where a system outage means you don’t get to play Marble Blast Gold for a couple of hours. The details of planning an outage of a production system can make up an entire book, but here are some things to keep in mind:

  1. Communicate benefits. Set up meetings and show the users the benefit they will receive from the system outage. Don’t tell them that they’ll get more memory: tell them the system will be faster and respond quicker. Don’t tell them there’ll be more disk space: tell them they’ll be able to store more data.
  2. Plan for failure. Think of this as disaster recovery planning for the project – or as welcoming Murphy into your plans. Anything that can go wrong will – so plan ahead as to what you will do when it does.
  3. Minimize downtime. In whatever ways you can minimize downtime means cost savings to the company – cost savings that they can pass on to your or the customer. It also makes the higher-ups happy, which is always a good thing.
  4. Test – then test some more – then test again. Make trial runs and see if it works. Make detailed plans of what to do and what might happen. Test to see if things worked properly – then test again.
  5. Make backups! Backup the system just before the major change (just in case) and then back it up again just afterwards. Set aside these tapes – and in the meantime, keep the regular daily backup rotation going. Then if you have to roll back, you can.
  6. Make checklists. Sure, you didn’t miss anything the first time – but what about the second time? Can you replicate every step all the way through, without missing any and without doing anything different? Did you test everything or did you miss one? Make checklists – as David Allen would say, “Get it out of your mind!” (he’s right).
  7. Organize a schedule. When will the system be down? Let everybody know and discuss how long. Agree on a specific day and time.
  8. Decide on a pass-fail point. This could be thought of as a “point of no return” – if things are not going well or are not going according to schedule, what is the last moment (or last step) that you can successfully turn back and restore services as planned? Have one of these and stick to it. When that point is reached, determine whether there is room for error and whether everything is going well – or whether you must turn back.