Top postings of 2007

In the last 12 months (to be precise, from last December 28, the day after the Top postings of 2006 entry through December 26, 2007), you have chosen ten top postings on Making Sense With Facilitated Systems as ranked by unique pageviews in Google Analytics.

As I noted last year, there are potential statistical problems with this list. Those who read my blog every day using the main URL don't get counted; both last year's and this year's tallies were made from those who landed on specific URLs as reported by Google Analytics (but excluding visits I may have made). That may be okay; those who linked to specific pages may have cared more about them. Recent entries have a more difficult hurdle, as they haven't been around as long to be viewed. The dates don't quite line up with the calendar year, although I suspect that makes little difference in the results. If you know of a better way, let me know.

10. For some time now, I've been using an open source simulator for my system dynamics work because it seems to help me think more effectively. That doesn't mean I've given up on commercial tools; I still use iThink for creating interactive environments, and I will be teaching IMT 586 at the University of Washington using Vensim PLE (and I may be using it in professional applications, as well). Last April, I combined my interest in the arts with my interest in this new approach to system dynamics in a public article about marketing program for symphony orchestras. You selected TAFTO 2007, the pointer to that article, as number ten on the list.
    



9. I've written several articles about data and numbers. Making more sense with numbers part 3 offered an easy process to plot data you receive in email or reports.
   



8. The words we use can be vitally important in helping us think productively about key business, organizational, and social challenges. In A systems language for business, number eight on the list, I described one team's evolution towards a better language for discussing business issues, thanks to a course they took from me in system dynamics modeling and simulation.
   



7. Good data helps us ground our thinking in reality. Still more on data, a pointer to several online sources of data, captured the number seven spot.
   



6. Growth can create problems (witness any of the bubbles that have occurred over history), but where are good examples of successful companies that intentionally don't grow? Number four on the list is Small Giants: the American Mittelstand?, pointing to a book that answers that question.
   



5. Sometimes old technology still has utility; sometimes it still attracts interest. At number five, Technology comes full circle, a description of my continuing use of a slide rule in my work, certainly fits that description. For those who are interested, it points to a source for new slide rules.
   



4. When I first started work as an engineer, PERT charts were done using mainframe computers or hand-drawn charts. Today, project management has become a profession with a certification process, and automated tools with graphical user interfaces have long since replaced tables of numbers and dates. Your sixth-most-popular entry was Critical chains: a decade later, my revisiting of Eliyahu Goldratt's critical chain theory that linked to Tom von Alten's revisiting of his views on the approach.
   



3. Productivity is obviously important to you. Your third most popular posting of the year was a surprise to me: If you can say it, it's done, an entry about the array programming language J.
   



2. Barry Richmond has a deserved place as an educator and thinker on system dynamics and systems thinking. I posted a link to an article he wrote about systems thinking and followed up with "Scientific thinking" the modern way, a differing view on the application of modern scientific thinking in system dynamics. That was your second favorite posting from 2007.
   



1. The 2007 posting you viewed the most was the series Making musical sense by email, showcasing a conversation between music critic, composer, author, professor, and consultant Greg Sandow and me that used a system dynamics model to explore the aging of audiences for symphony orchestra concerts in the USA. Now I'm curious: was its popularity because of the topic (music), the approach (a somewhat novel approach to using system dynamics), or the fact it was a real conversation between two people? Let me know.
   

All of those postings were made in 2007. It wouldn't be fair to finish this list without noting that some postings from prior years did rank higher than some of these. Here's the all-time top ten list of postings from Making Sense With Facilitated Systems as measured by your viewings in the last twelve months:

15. TAFTO 2007 (2007)



14. Making more sense with numbers part 3 (2007)
    



13. A systems language for business (2007)
    



12. Still more on data (2007)
    



11. Small Giants: the American Mittelstand? (2007)
    



10. Technology comes full circle (2007)
    



9. System Dynamics for Cheapskates (November 2006)
   



8. Critical chains: a decade later (2007)
   



7. If you can say it, it's done (2007)
   



6. "Scientific thinking" the modern way (2007)
   



5. Making musical sense by email (2007)
   



4. System dynamics with MCSim (November 2006)
   



3. In praise of the lazy employee (April 2005)
   



2. System dynamics and program evaluation (June 2005)
   



1. Making sense with numbers (November 2006)
   

That list includes the top ten postings written in 2007 plus the five entries written in prior years that were at least as popular as the top ten 2007 postings.

As 2007 draws to a close, I want to thank you who read Making Sense With Facilitated Systems and to invite you to continue with me in 2008. If you have suggestions or feedback for this blog, contact me.

I would be honored to be of service to you or your organization in 2008. If you're trying to make sense of tough business or organizational challenges, curious how I might be able to help, or just want to talk about some of the issues you face or that I write about, get in touch.

High-performance organizations

Do you want your organization to perform dramatically better than it does today? What's holding it back? What's holding you back?

Ralph Sink has an idea, based in his experience, and he describes it in My Unfashionable Legacy in strategy+business. I've led that sort of organization before, and I found it amazing what such an approach can accomplish.

Thanks to Fred Nickols for bringing this to my attention via the ODnet mailing list.

Finding a consultant - remotely

In less than a month, Facilitated Systems will have been in business for eight years. I've worked with people in Asia-Pacific, Europe, and the Americas, and yet I've rarely seen a client, for I work mostly from my office.

In today's world, that has distinct advantages. For those of you not used to working remotely with a consultant, I'll list a few:

Responsiveness

If I came to your site to work, I'd likely save up tasks until I had half a day, a full day, or perhaps several days of work at once (depending upon how far away you are), because it's more economical. That's a delay for you.

If I work remotely, you can get my attention in the size chunks you need: minutes, hours, days, weeks, or months. The delay from asking a question to getting an answer drops; if I'm available when you call, you'll start getting help immediately. If you do have to wait, the wait will likely be shorter.

Speed

You can get my help now, without waiting for me to fly, drive, or take a train. If I'm working on someone else's tasks, you need to wait for me to finish those. That's where responsiveness kicks in: if it's appropriate, you may well get some of my time starting today, rather than having to wait until I have full days available.

Lean

If I'm traveling, I'm not working for you. Sure, I try to work on planes when I can, but there is much to the travel experience that represents pure muda. Moving me to you is the essence of transportation and waiting waste.

Cost

If there's no travel, you don't pay for travel. Simple.

Carbon friendly

If I'm not traveling, I'm not generating as much CO₂.

Petroleum friendly

If I'm not traveling, I'm using less petroleum.

Congestion friendly

If I'm not traveling, I don't add to traffic congestion.

Resources

If you need a team, assembling a remote, distributed team from my contacts world-wide to help you brings all these benefits in spades.

How did I discover this? You folks taught me. When I started out, I expected to spend significant time in a car or on a plane, even as I expected to do some of my work remotely using the phone, email, and other online tools. With rare exceptions, you who hired me were quite happy to have me sit here and work there. As times have changed over the last eight years, your insights seem wisely prescient.

Some tasks do require a consultant at your site. I've done that, I will do it again, and I do enjoy working together with you in person. So call if you think that's what you need.

I have also discovered that it's possible to share ideas, build trust, work on problems, and make a joint contribution without being there in person. If that's what you seek, call me, too.

Which serves you best?

Multitasking

I recently saw a television advertisement promoting someone's smart phone that could make you more productive by helping you multitask more.

In light of what I'm reading elsewhere about the risks of multitasking, I thought it worthwhile reflecting on what multitasking does.

In the old days, computers did one thing at a time. That was efficient for them, but it wasn't always great for us. We humans began to see the advantages to us of their doing more than one thing at a time. That is, I benefit if I can be printing a document, updating software, and reading my email, all at the same time. In that case, I'm only doing one thing: reading email. I told the computer to print the document, and I'll pick it up later when I walk by the printer. I told the computer to get the latest version of a certain application; I don't have to do anything else, and it will be ready for me when I next use it. I can now read my email without waiting on the other tasks to finish. In addition, the computer may be doing other useful things (for example, getting new email) without me having to even ask. That can be very good for me.

From the computer's standpoint, that can be a problem. The computer has to do more work multitasking than if it were only doing one thing at a time. The good news is that computers have gotten faster, and they've gotten features that help them multitask more efficiently, so they have the capability to keep up with our demands (at least most of the time).

So when someone talks about productivity and multitasking in the same sentence, make sure you know whose productivity they're talking about. If this multitasking stuff works as it has in the past, your multitasking may enhance someone else's productivity, but it makes you work harder. That can only work if you have the excess capacity (time) to get all your work done and manage to switch between tasks efficiently. Did you get that quad core brain implant last week?

Critical chains: a decade later

I first read Eliyahu Goldratt's Critical Chain : A Business Novel in 1998. I was sufficiently intrigued by the critical chain approach to project management that I summarized my notes for an internal Web page at my company in March 1998. Tom von Alten worked for the same company and also wrote up his thoughts on critical chains; we cross-linked our pages to give people two somewhat differing views of the approach.

It's now almost a decade later, and Tom and I have been discussing project management again. We decided to post slightly edited and reformatted versions of our original pages to let you see what we were thinking back then and to provide a reference for those of you who might want to know more. I've integrated my three pages into one long post so that it's easier to find as a whole.

---

Project Management Revisited: The Theory of Constraints

Eliyahu M. Goldratt's book, Critical Chain, applies the theory of constraints to project management. He implies ~25% improvements in project duration are possible the first time it is applied.

The basic steps

1. Draw the project plan in PERT chart form; make sure each activity has a time estimate. Assign resources to the steps, and shuffle steps in time until no resource conflicts (i.e., two steps needing to be done at the same time by the same resource) occur. Identify the critical chain (the longest chain of dependent steps, including path and resource dependencies).
   
   
2. Cut the time estimates of each step in the critical path in half (this approximates the median step duration). Add a project buffer at the end of the critical path equal to half the time you cut from the critical path.
   
   
3. For each path which feeds into the critical path (so-called feeding paths), cut the times of the individual tasks in half and place a feeding buffer just before that path feeds into the critical path.
   
   
4. When a person or group is a week away from entering the critical path, send them a reminder. Repeat that reminder at 3 days and 1 day prior to their projected entering of the critical path. When the time comes for them to start a step on the critical path, they are expected to drop whatever else they are doing to focus on the critical path step (this provides a resource buffer by ensuring that the critical path won't have to wait for them to come free).
   
   
5. Set up a daily (one colleague suggested that weekly might be more appropriate) metrics collection and reporting program.
   
   
   
   
   • For each step in the critical path, capture the number of days until that step hands off to the next step.
     
     
   • If that number increases by x, remove x days from the project buffer. If it decreases by x, add x days to the project buffer.
     
     
   • Do the same things for each feeding path.
     
     
   • Report those numbers daily (weekly), prioritized by those steps which are decreasing the project buffer and then by those which are decreasing a feeding buffer.
     
   
   

This cuts ~25% off the current plan without a change in work content or resources. Future improvements are possible and expected; see the next section for more details.

The five steps of the theory of constraints

These steps restate the above process with more focus on TOC terminology. Any book or paper on the theory of constraints will reference these five steps using Goldratt's unique terminology.

1. Identify the system's constraint.
   
   For project management, the constraint is, to a first order approximation, the critical path from the PERT chart. By incorporating resource needs, one arrives at the critical chain, the precise constraint.
   
   
2. Decide how to exploit the system's constraint.
   
   Make sure it stays busy. First, remove time buffers from the individual steps by using 50%, not 80% or 90%, confidence values for expected durations. Cutting traditionally estimated times in half is the suggested heuristic.
   
   Next, install feeding buffers to ensure lateness in a non-critical chain step won't impact the critical chain and resource buffers to ensure that resources are available when their contribution is needed to the critical chain. The suggested length of such a resource buffer is half the amount that was removed from the path it's protecting, thus giving a 25% savings on each feeding path.
   
   Finally, because there is variation (uncertainty) in the estimates for the durations of critical chain steps, install a single project buffer at the end of the project to buffer the scheduled completion date (and the customer) from that uncertainty. Use the same algorithm as for feeding buffers, giving a 25% savings on the overall project duration.
   
   
3. Subordinate everything else to the above decision.
   
   Don't work on something just because you think you have to keep busy or be more efficient or productive. Ensure you have excess capacity in all the feeding paths to keep the constraint (the critical chain) busy and to catch up from any delays in the feeding path steps.
   
   
4. Elevate the system's constraint.
   
   Increase its capacity. Add resources in ways that shorten the critical chain; improve processes along the critical chain.
   
   
5. Repeat the process.
   
   If the constraint has been elevated successfully, it may very well no longer be the real constraint. When the constraint has been elevated, re-assess the current critical chain, which may lead to repositioning and redimensioning buffers.
   

A change in work philosophy

In the traditional way of managing projects, people are expected to stay busy, and departments are expected to avoid wasting money by eliminating excess capacity. This presumes that having uniformly busy people contributes directly to faster project completion and better business results.

The TOC approach calls for a focus on the system's constraint (the critical chain). The parts of the organization on the critical chain should be running at capacity.

The difference is how one treats work off the critical chain. Those areas should be running explicitly at less than full capacity, because they need reserve capacity to make up for the unavoidable slips which occur due to activations of Murphy's Law.

A change in metrics

The fundamental changes are to stop measuring what percentage of the total work is done, how busy everyone is (area capacity utilizations), and when individual steps should be and are completed.

The fundamental and perhaps only measure becomes how much of the various buffers (project buffer first, then feeder buffers) remains. Changes which reduce those buffers are warning signs; changes which increase them increase the likelihood of completing the project by the scheduled date.

Assumptions

I have listed the assumptions which seem to underlie the critical chain approach to project management here for people to attempt to disconfirm them. Lack of success at such disconfirmation attempts would seem to indicate strength in this approach. I've tried to list them as major points with underlying corollaries capable of being derived from those major points.

• Traditional business philosophy says improving any parts of the whole provides equivalent benefits to the whole; in reality, a very few parts have an overwhelming contribution to the performance of the whole (much more concentrated even than the "80-20" rule).
  
  
  
  
  
  • Monitoring the percentage of work completed causes a focus on tasks which works against on-time completion of the project.
    
    
  • Focusing on ensuring that each step completes on time will not ensure the project completes on time.
    
    
    
  • You don't protect the integrity of the project schedule by protecting the integrity of the schedule of each step (by adding safety factors at each step); you must protect the goal of the project schedule by putting in safety factors (time buffers) just in front of the customer (at the end of the project) and just in front of the project's constraint (the critical chain) (i.e., putting feeding buffers where any path in the PERT feeds into the critical chain or where any resource constrain threatens the critical chain).
    
    
  
  
  
• There is excess time in most project schedules (analogous to excess inventory on most production floors) which can be removed by proper focus.
  
  
  
  
  • We inflate our normal task (step) estimates to
    
    
    
    • account for interruptions and multi-tasking, and to
      
    • give ourselves an 80% or 90% chance of completing the task on time.
      
      
      
      
      
      • Given the skewed right nature of the probability distribution of most task duration estimates, this easily translates into about a 200% inflation in time when compared to the median of the distribution.
        
        
      
      
      
    
    
    
  • We often waste safety buffers we give ourselves by
    
    
    
    
    • not starting a task until any such buffer has gone by (procrastination),
      
      
      
      
      • Since we don't know until we're well into a task whether there are unfortunate surprises ahead, by waiting to the last minute to start, any surprises we find affect the completion date directly.
        
      
      
      
    • trying to do multiple tasks simultaneously (multi-tasking), and
      
      
    • allowing dependencies between tasks to accumulate delays and waste advances.
      
    
    
    
  
  
  
  
• Local efficiencies and productivities don't count.
  
  
  
  
  
  • People don't have to stay busy all the time.
    
    
  • People shouldn't stay busy all the time, because then you don't have the excess capacity you need to protect the system constraint.
    
    
    
    
    
    • If you don't protect the system constraint (in project management, the critical chain), your overall goal will suffer, even if your metrics at individual steps appear in order.
      
      
      
      
      • Measuring individual steps, unless they are a part of the constraint, is likely to lead you to do exactly the wrong thing.
        
      
      
      
    • There is a new work philosophy:
      
      
      
      
      • If it's too early to start a step (on the PERT chart), do nothing.
        
      • If it's not too early, work as fast as possible on that step.
        
        
        
        
        • By having removed the safety from each step, you have nominally only a 50% chance of completing the step on time.
          
          
        
        
      
      
      
    
    
  
  
  
• Conflicts are a clear indication that someone has made a faulty assumption and not a signal to compromise. (This is a lesson Goldratt claims to have taken from the scientific world into the business and sociological world.)
  
  
  

To find out more

The original article listed several references. I've already listed Critical Chain and some of the others elsewhere. I once pointed to a Robert Newbold article I can no longer find, but there is a long list of papers he and others have written on the subject.

For Tom Tom von Alten's insights on the critical chain approach, see his book review of Critical Chain, which includes snippets of PERT charts showing this more graphically.

---

That's what I thought almost a decade ago, and you can find out what Tom thought back then, too.

I'm curious: have any of you tried critical chains in your organizations? What have you learned?

What moves us forward?

What moves us forward? According to a recent article in the NY Times, The Unsung Heroes Who Move Products Forward, it's the creation of innovative processes and infrastructure.

Thanks to the TP! Wire Service for the tip.

Technology comes full circle

This goes in the category of a small productivity hint to those of you who have to manage or moderate presentations from time to time. One of the challenges is to keep to a schedule; in the midst of presenting, presenters can wax eloquent and use more words (and thus time) than they intended. Assuming you can signal them somehow, how do you figure out whether you're in time trouble or not?

I moderate online meetings from time to time, and I've tried different approaches. For some time now, I've been using a circular slide rule. It's fast, it's easy, it's small (inconspicuous, if you're working in front of others), and the circular slide rule ensures you never have to re-orient the rule. If you'd like to try this approach but don't have a slide rule sitting around, check out Concise. They make a variety of circular slide rules. I'm using a smaller, pocket-sized model they no longer make, but I'd be interested in their 300 today. For this work, though, the 27N or 28N would do quite nicely.

If you're not ready to buy one, consider a home-made version.

Do you manage people who program?

Do you manage programmers or software engineers, people who write code for a living? If you do, check out Paul Graham's Holding a Program in One's Head. It explains the importance of getting a program into a programmer's working memory ("head") and the damage to results and productivity that can be created by distractions. I think the same applies to certain other fields, too. I know that modeling and simulation work quite resembles programming in that regard; perhaps you can list other fields where it takes significant time to get all the pertinent information into our heads before we start real work.

As an aside, Graham recommends succinct languages for more powerful results. J is one language that's quite succinct and quite powerful. It's easy for many of us to use as aids in our current work; that's why I recommend it for managers and knowledge workers, not because we're dense but because our primary contribution isn't programming, and I find J augments my capability without making me a programmer. I also recommend J for serious programming work, for I've seen what true J experts can do, and it's both impressive and leverageable.

Making more sense with numbers, part 4

Now that you've got an easy way to capture numbers out of emails and documents, how do you get numbers back into emails?

Graphs are great, but perhaps you don't want to use attachments? Check out Gnuplot's dumb terminal mode as a way to create plain text graphics. If you keep it simple, you can convey decent graphical information with plain text (as long as your recipients use a non-proportional font in their email client for plain text emails—a very good idea, anyway). I tested this approach in a public discussion and found some liked it and some didn't.

Perhaps you really do want to include a table of numbers or numbers and words. If you're working in J, it's pretty straightforward to create the table you want and then use J's clipfmt and wdclipwrite verbs to create something you can simply paste into your email or other document.

If you're using J, you can create your (text or other) graphics in Gnuplot, if you prefer, or you can create them in J directly.

Incidentally, this note and its predecessor have addressed specific cases of the more general problem of getting data into and out of J, a problem I think lots of newcomers to J discover early on. It's easy to do powerful calculations in J, but manually transcribing the data from another window into J or from J into another document loses all the benefits. The J Wiki has a page called Interfaces that might help. I've found the Text Files page quite helpful in getting data out of plain text files. Any statisticians reading this might find the interface to R useful.

Working together at a distance and across platforms

Solveig Haugland recently asked what tools she might use to share her desktop with others. One constraint: it had to work on a Linux platform.

Some of you might benefit from the answers. Even if you don't use Linux, perhaps some of those with whom you work (or want to work) do.

If you've got other suggestions, I suggest you post them on Solveig's blog; then we'll all have one spot to reference. Of course, if you want to comment here, too, you're always welcome to.

Moving to Linux

I don't think moving to Linux is for everyone.

For one thing, part of the reason we have as much malware as we do may be that there's one predominant operating system, so it pays to figure out ways to exploit it. Sure, some operating systems seem more bullet-proof than others, but having one main target for malware writers, no matter whether it's Linux, Mac's OS X, or Windows, seems like risky business. Spreading people more uniformly around the major operating systems and then providing data interchangeability (e.g., exchanging data through adhered-to standards for XML or plain text) seems like a more robust solution.

For another, you may have certain programs you need to run that only run on one or the other operating system. I can think of one or two major programs I need to run that require Windows.

Still, if you've been using one operating system for a while, you may not know what exists elsewhere. That's why it's good to see LinuxLinks' list of Linux alternatives to popular Windows programs. While it's missing major programs I use (most of which are available on all three major operating systems), it may help some of you. Thanks to RootPrompt.org for the tip.

Making more sense with numbers, part 3

One of the early mantras one hears in statistics is "Plot the data." When I first heard it, it was followed by "by hand"; I suspect that part gets elided these days. Still, the advice is good. It's often easier to make sense of a list of numbers if you can visualize them.

Most of the time, that takes time we don't have. When we get an email or a report with a table of numbers, we know that plotting the numbers means grabbing a piece of graph paper (does your office supply cabinet even stock graph paper anymore?) or opening up your favorite spreadsheet, copying numbers, and drawing a graph. I rarely take the time.

Last week, I got yet another email with a table of numbers showing how something had changed over time. I was curious, so I wrote a short J script (now edited into a one line script) to turn the clipboard into data and another to plot the data.

Voilá! Now I had an easy and quick way to grab and plot data. I tried grabbing data out of an OpenOffice.org Writer document, and it worked, too. Grabbing data out of a Writer table was almost as good; my script lost the shape of the table, but that's easy to fix.

What's more, when you've got it in J, you can also apply various J statistical routines to the data, or you can pass it to R for more advanced statistical processing.

Yet another simple productivity tool, yet another reason to learn J as a tool for thinking and doing, yet another way to make sense with numbers.

I don't really care if you use J or some other tool; just pay appropriate attention to the data you handle. I just happen to think J is a powerful tool for this task (and for many other tasks). If you're learning J, check out the J lab called "An Introductory Course in J" by Henry Rich (thanks to Kip Murray of the University of Houston for pointing that out recently on the J Programming forum. Kip notes that Henry's lab covers a lot of territory very clearly but with a steep learning curve. If you are just seeing J for the first time, check out the J Primer.).

Interested readers might also be interested in tables2graphs.com and Using Graphs Instead of Tables.

So, if you have a table in email that looks like

Year Amount
2000 150
2001 200
2002 250
2003 225
2004 260
2005 254

and you'd like to graph it, one J program is

require 'format misc files plot'
sd=: > @: (". each ) @: |: @: clipunfmt @: wdclipread

Just copy the numbers, and type

plot ;/ sd''

to see your graph. I'll let you figure out how to add options and how to deal with multi-column data tables (it's easy).

Why is this part 3? Because there already has been a first and a second making sense with numbers, of course.

Which OS for your business?

CIO Magazine has been looking over the shoulder of CareGroup CIO John Halamka as he tests various operating systems for deployment in his organization. See the final series as he tests Ubuntu, along with his decision. It may not be what you think. (If you like this article, you might also like this.)

If you can say it, it's done

Even in this day and age, computing is a problem. How many of you us take the time to do some of the calculations mentioned here when faced with business or economic data, and how many of you us just read the analyst's summary and take the analyst's advice?

To some degree, that's because it takes time and effort to double-check such work, and that only gets worse if the subject is complex. It's also because the tools we have aren't always set up to help us do such things on the fly, and we're often on the fly (or in meetings, which can be as challenging).

That's one reason I've encouraged some of you who are interested to learn alternative approaches.

At least one APLer, Randy MacDonnell, has written about APL, "If you can say it, it's done." The same is true, of course, about J, its descendant. I had occasion recently to write a program to calculate whether a certain Monte Carlo simulation was done. I found a quotation by Andrew Gelman describing the Gelman - Rubin statistic:

For any given parameter, R-hat is the estimated posterior variance of the parameter, based on the mixture of all the simulated sequences, divided by the average of the variances within each sequence.

That looked easy enough, so I just wrote it down:

R=: var @: , % mean @: var

In English, that's "the variance of the entire set of data" (var @: ,)
"divided by" (%) "the mean of the variance of each data sequence" (mean @: var).

"If you can say it, it's done."

And you thought this was a blog about business, not programming, right? You were right. While J is a language that can be used by programmers, it's also a language that can be used by you and me to express quantitative ideas more powerfully and concisely than a spreadsheet. If you're ever interested in numerical answers from a spreadsheet, you could be interested in J. Perhaps, for some of you, it's worth downloading and trying out. Much as in learning a foreign (human) language, you won't be able to do much at first, but, eventually, you might be surprised what you can do. In a way, it's as much about thinking than about computing, and yet you can process some pretty large data sets with pretty concise "programs," too.

Thanks to Randy and Andrew for the quotations. For those of you interested in the Gelman-Rubin statistic, Andrew has pointed me to two papers giving more information: his Inference from Iterative Simulation Using Multiple Sequences with Donald Rubin and his General Methods for Monitoring Convergence of Iterative Simulations with Steve Brooks.

Better than a spreadsheet

So you're a manager, and you have numbers to calculate. How do you do that? Most likely, you fire up your favorite office suite and create a spreadsheet.

With the problems people have highlighted about spreadsheet usage, I find that I've been using a spreadsheet less and less. Most of the time that I open a spreadsheet these days, it's for a legacy application. I tend to use J.

I've written about J elsewhere. I was tempted to give a short introduction here, but I realized I'd be duplicating what others have said, and their attempts are, no doubt, better.

What prompted me to write this morning was my experience of yesterday. I needed to track some data, and so I set out to create a simple database. I have PostgreSQL available, but that seemed excessively powerful. I really should update my PostgreSQL installation, and I didn't want to take the time for that. I thought about Base; then I could pick whether I wanted to use PostgreSQL, its internal database, or something else.

When I realized that I'd likely want to analyze the data with J, I remembered that J has an SQLite addon, thanks to Oleg Kobchenko. I installed it (it's tiny), and I was up and running with a relational database in minutes. Now I just need to brush up on my SQL.

So, check out J. It's free, and it runs on most systems.

Installing Ubuntu

From time to time, I mention that some of you may find one of the Linux distributions a good operating system for your use. The prospect of installing a new operating system can seem daunting, though. RootPrompt.org points to Falko Timme's The Perfect Desktop - Ubuntu 7.04 Feisty Fawn, which walks through the process with plenty of screen shots. That should give you plenty of information, if you've been considering this move.

Creating text productively

Most of us spend a fair amount of time creating or dealing with text: email, reports, evaluations, proposals, and the like. Over the years, I've found one tool that consistently has helped me to be more productive at generating text in any format: Emacs (check out their quick guided tour—I learned something new there). It may look like an editor for software engineers, but it's really much more general than that.

I'm not interested in starting an "editor war" with those who prefer other editors (or word processors, for that matter), for it's to some degree a matter of personal fit. I did want to point out that IBM has a tutorial on learning Emacs, for those starting out. So does Emacs, for that matter (it starts automatically the first time you run Emacs); the IBM version has the potential advantage that you can read through it before you install the software, although you will learn more by actually using it.

For those of you who would like to walk through the IBM tutorial (it requires free registration), check out these, or search on their site for more specialized material:

1. Living in Emacs
   
2. Learn the basics of Emacs
   
3. Learn the essential modes and editing features of Emacs
   
4. Advanced Emacs text operations
   

Emacs does run on pretty much any computer platform you might have.

For those of you saying, "But I want nicely formatted documents, not pure text," see Business writing made easier. And for any of you really into text, check out Antiword as a tool to convert a Word document back into text. It's usually faster to open a document in Antiword than in Word.

Making the move to open source software (don't forget to FLOSS!)

As frequent readers may have detected, I make use of a fair amount of open source software (also called Free/Libre/Open Source Software or FLOSS) in my work. Sure, it's less expensive, but I tend to do it because of other advantages it provides.

You might get the impression that I think switching to open source (or, for that matter, switching to any new software) is easy, and you might be concerned that it's harder than I let on.

You'd be right to be concerned. Solveig Haugland has just published a good article called A very important post for decision-makers considering OpenOffice.org. Read it if you're even considering moving your company to a new system. (If you're only moving yourself, it's a lot easier; you become both the pilot test and the implementation, and you can control the speed and extent of your transition.)

If you'd like to dig more deeply into the economic impacts of FLOSS, you might be interested in Study on the: Economic impact of open source software on innovation and the competitiveness of the Information and Communication Technologies (ICT) sector in the EU, prepared for the European Commission's ICT Task-Force. The final report was published November 20, 2006. I can't get that report to load successfully this morning, but a September 26, 2006 draft of the executive summary does work.

I've not read the entire 287 pages, but I have read the executive summary. I'd like to highlight one point on page 12 of the report:

Avoid lifelong vendor lock-in in educational systems by teaching students skills, not specific applications...

Whether you're a fan of open source software or not, I think that's incredibly important advice. Some software, some products, some processes, and some technologies have incredibly long lives (I'm using an editor that traces its heritage back to the 1970s), but others come and go. It's much better when we, our employees, and our new hires understand general principles and then can apply those principles in specific cases than when we only understand specific cases and have to start all over when we face a new specific case. Think about that as you hire, as you train people, as you learn yourself, and as you consider what gets taught in the educational system where you live.

Ethics

We all bear responsibility for our own ethical behavior. Period.

That said, when we are in positions to direct others' behavior and when our actions can be shown to lead to less ethical behavior, we have a signal to act. I've written before about the challenges long hours at work can make and about the benefits of having a few lazy employees. Professor Sandy Piderit has written about it.

Now Deloitte & Touche USA LLP has published Deloitte & Touche USA LLP Survey Finds Strong Relationship Between Work-Life Balance and Ethical Behavior.

Is it as simple as having everyone in your company work 40 or perhaps 37 or 35 hours a week? No, it's clearly not that simple. Customers deserve the goods and services they paid for. Employees and the community need jobs, and we can't provide secure jobs if we sacrifice all our productivity gains and more to shorter hours. Unforeseen, short-term crises do arise. Besides, the length of the workweek clearly isn't the only factor affecting ethics in the workplace. As I said before, that's ultimately up to each of us.

But it does mean that there's yet another factor to put on the side of the scale that weighs against longer hours. It does mean that decisions aren't as simple as the calculation that "if 40 hours a week are good, then 80 must be twice as good." We as managers and consultants do bear responsibility for thinking about such things and for balanced decisions that take these factors responsibly into account.

Part of thinking responsibly is thinking skeptically, so I encourage you to provide any disconfirming evidence you might have. I'm not looking for anecdotes ("Sam only worked 30 hours a week, yet he stole more paperclips last year than you could believe!"), for I'm sure they exist. I'm looking for valid studies and good, statistical reasoning.

Thanks to Chief Learning Officer magazine for pointing this out.

Improving Firefox OS

I just discovered Fullerscreen today, which would seem to work especially nicely for those trying Firefox OS.

It doesn't come with much documentation. Look in the status bar at the bottom of your browser window to see the new Full Screen options icon. Use F11 to toggle between normal and full-screen mode. Move your mouse to the top of the screen to reactivate tabs temporarily to select another tab, or use Ctrl-tab to select the next tab in order.

Could your hard drive be obsolete?

Firefox OS: Why My Hard Drive & Software are Obsolete.

I'm not there—I do too much in Emacs—but I see his point.

Be careful out there

See Alert: Critical Windows Attack Underway and Virus Disguised as IE 7 Download.

Assuming you have the option, this sounds like a very good time to use a browser other than IE, to read emails in plain text instead of HTML, to avoid clicking on links you aren't sure of, and to be generally careful. Currently just over 50% of you who visit Facilitated Systems use IE.

By the way, when I send long URLs by email, I sometimes use TinyURL.com to shorten the link. I always use the Preview Feature in creating those links so you can see where you're going before you go there. In case you get a link where that's not enabled, you can apparently set it for your computer, too.

Inverted KM

I'm certainly no knowledge-management (KM) expert, but I had occasion to recall Connex, an old Hewlett-Packard KM system today. As I understand KM systems, they generally attempt to capture isolated organizational knowledge and make it more broadly available throughout the organization.

Connex worked the other way. Instead of capturing knowledge, it captured information about experts. If you needed information about subjects X and subject Y, and you had reason to need it from someone who spoke German, you could query Connex and find the name and contact information of any experts who fit that profile.

That seemed easier for the experts, for they didn't have to take the time to write up their expertise without knowing whether it would ever be used. They didn't have to work to make their tacit knowledge explicit, either.

It seemed advantageous for the people needing knowledge, too, for, instead of getting a canned response that might not precisely fit their situation, they'd be able to discuss the matter with the expert and, hopefully, tailor a solution to their particular problem.

What I found really attractive was the social dynamic upon which it was founded. In a KM system, experts might feel as if they were passing along to others what made them unique and valuable. Instead, by listing their profiles with Connex, they enhanced their reputations while benefiting others in the company.

With a bit of searching, I discovered that Connex is not necessarily unique; Motorola has its Compass program, and IBM has its Blue Pages Plus.

You are even less alone ...

... if you're thinking of storing all of your office files in ODF. Now Texas and Minnesota seem to be moving in that direction.

Whether you like OpenOffice.org, Microsoft Office, KOffice, or something else, I think it's very much a positive step to adopt a standard format such as ODF.

Is ODF perfect? No, it seems not. For example, I can't see any reason to abandon the TeX format for typeseting mathematical formulæ. Then again, if I'm typesetting a document, I'll likely use LaTeX. With the prevalence of files created with office suites, I still think it's important to start with a standard file format and then help it evolve and improve.

While such a format could be led by a company, I've seen "standards" in the past. Think of Pascal, if you programmed computers in the 1980s, in which many companies made incompatible extensions to try to lock people in to their versions. Sure, you could program in Standard Pascal, but they hoped you'd make use of their attractive, special features and then become locked into their platforms.

Let's have a standard, open, and publicly-agreed-upon file format that vendors really stick with, and let the competition reign in software to produce and read those files. We'll all win.

A commuting fantasy

Yesterday, I had occasion to drive to the airport and back. That's at least a 40-mile trip each way. With local traffic, the trip can take quite a while, no matter what time of day (except, perhaps, around 3-4 in the morning).

Two nights ago, though, we had a snowstorm that wreaked havoc with the evening commute, and we were being told yesterday that we should stay home unless we had to venture out. People seemed to listen, traffic was light, and driving to the airport, even with occasional slick spots in the roadway, was a dream. It was if we had turned the clock back 20 years as far as traffic goes.

As someone who does most of his work remotely, using phone, email, Web conferencing, and the like, I had a fantasy. What if people really didn't need to drive to work each and every day? What if we could keep the roads available for the times we really need them? We wouldn't have to spend as much on roads. Companies wouldn't have to spend as much on office buildings. We wouldn't have to spend as much on fuel. We wouldn't have to spend as much on cars. We wouldn't emit as much in the way of greenhouse gases. When we did drive, we'd have a more pleasant experience. When we didn't drive, we'd have more time for family, friends, and leisure. We'd injure or kill fewer people on the roads.

Could we do it? Really?

You are not alone ...

... if you're thinking of switching to GNU/Linux.