Utah Open Source Planet

Part I:

Use the formula P@40-to-70, in which P stands for the probability of success and the numbers indicate the percentage of information obtained.

Part II:

Once the information is in the 40 to 70 range, go with your gut.  Don’t take action if you have only enough information to give you less than a 40 percent chance of being right, but don’t wait until you have enough facts to be 100 percent sure, because by then it is almost always too late.

Today, excessive delays in the name of information-gathering breeds “analysis paralysis.”  Procrastination in the name of reducing risk actually increases risk.

Visually, what Colin Powell is describing is the Law of Diminishing Returns where, over time, the value of information diminishes.  Perhaps that relationship might look like this:

(click image for a larger picture)

The circle represents an inflection point at which for each marginal unit of information gathered, the value starts to go down or the cost-effort-benefit tradeoff for the next marginal unit of information is less than the cost to obtain it.

Instinct in Product Development

In product development — any type of product, software, material, or otherwise — there is often a discovery process at the outset.  The trap that most companies fall into is excessive market research, thinking that the more we know, the less risk we’ll face.  As General Colin Powell points out, that type of thinking is flawed.  The truth is that the more delays there are, the risk just increases: knowing more doesn’t translate to less risk or higher probability of success.

Big-Design-Up-Front Design is the poster child for Analysis Paralysis in product development.  In product development, that typically takes the form of “Requirements Gathering Ad-Infinitum” — which is a term I use to indicate incessant requirements gathering with the aim of exhaustively gathering customer requirements, but the activity itself takes a form of its own and — often — it leads to documenting a lot of stuff, but nothing tangible has been produced that brings value to the customer.

Little’s Law is your Friend

A queueing system is a model with the following structure: customers arrive and join a queue to wait for service given by n servers. After receiving service, the customer exits the system. A fundamental result of queueing theory is little’s law.

Theorem: for a queueing system in steady state, the average length of the queue is equivalent to the average arrival rate multiplied by the average waiting time. in other words,

L = λW

Little’s Law is a fundamental principle in business, mathematics, and has applications to many real-world problems. One of those real-world problems is in product development.

First, a definition:

WIP/TIP: Work-in-process of Things-in-process. For the purposes of this article, they are synonymous. Being “in-process” means the work or things have entered a state-of-affairs but have not yet exited. The “work” can be anything: materials, components, sales orders, software code, software testing, projects, customer inquiries, checks, phone calls to return reports suppliers to qualify, repair orders, or emails waiting to be answered, etc.

For product development, we can use a transformation of Little’s Law, like the following:

[(Throughput) = (Things-in-Process) / (Average Completion Rate)]

What this equation tells us and what experience has shown time-after-time, is that the number one driver of Product Development Cycle Time are the “things-in-process”. There is no quicker way to reduce the cycle time by which your company can get a product from concept-to-delivery than through first prioritizing all the projects or products and focusing on the ones that make strategic and tactical sense, and killing the lower priority projects.

You might be thinking: “True, but couldn’t we also increase the average completion rate”? You’re right, but the impact of doing that is much lower than reducing the TIP — that is, influencing the average completion rate is rather difficult and is often a function of available resources, scope creep, market demands and changes, etc. Here’s the bottom line: the number one driver for shipping products quicker is by focusing on the important ones and killing the unimportant ones.

How Batchy Are You?

From a Lean Thinking perspective, Powell is really advocating for a less batchy approach and one that obeys the one-piece flow principle.  Gathering a lot market research and a lot of data is really a batchy approach, whereas the one-piece flow approach from Lean is one for which Colin Powell is arguing.

Specifically, Powell — whether he knew it or not — is really arguing for “What is the right batch size?”  In the case of information, Powell is arguing for ~40% to 70% relative to success as the batch size.  Since one-piece flow is not possible in some cases, then asking the right batch size is the better approach.  An approach that looked at the right batch size and also followed an iterative model — that would be an approach that is more customer-facing and will have a higher likelihood of success (or lower likelihood of failure).

Little’s Law, The Law of Diminishing Marginal Returns & Powell’s Law of Instinct

There are several principles at play: Little’s Law is true — as Work-in-Process grows and the Cycle Time to complete each unit increases, Throughput decreases.  The end result is that products aren’t shipped on-time or at all and the customer loses.

The Law of Diminishing Marginal Returns teaches us that there is a point at which obtaininig the next marginal unit — of any type of unit — might not be worth the cost to obtain it.

Colin Powell’s Law of Instinct teaches us how to reconcile the Little’s Law and the Law of Diminishing Marginal Returns.  He advocates that we rely on hunch, gut, and instinct.  Once we have enough information to be within the probability of success of 40% to 70%, then go with your gut.

Related Posts:

1. Little’s Law for Product Development This post is part of a series on Queueing Theory....
2. Multi-Tasking Leads to Lower Productivity There is a predisposition for firms and people to think...
3. queueing theory: part 1 This post is part of a series on Queueing Theory....
4. queueing theory: part 2+ This post is part of a series on Queueing Theory....
5. Shmula Goes Camping: Drum-Buffer-Rope My family and I went camping with my brother-in-law and...

OS reinstallation would be much easier with a plugin that could dump your entire list of Firefox plugins and reload them later.

Does anybody know of a plugin like that?  I’ve used screenshots to remember which plugins I’d installed, then reinstalled them one at a time, but that’s a remarkably sucky way to go.

What do you use to avoid having to find and reinstall your favorite plugins one at a time? Anything?

The new Ubuntu is out. Download it here if you haven’t already.

For my non-technical readers:

Ubuntu is a flavor of Linux, an operating system that can replace Windows. Linux is open sourced, meaning you can look at the code and see how it works. It’s also free to download and includes a ton of world-class open-source software: Firefox for web browsing, OpenOffice for office software, Gimp for photo editing, and much more.

Ubuntu is easy to use, and it’s a great way to familiarize yourself with Linux. Plus it can save you a lot of money if you’re buying a PC that doesn’t come with Windows. (Or, if you’re currently pirating Windows –you know who you are– switching to Linux can help you get legal.)

There is a ton of help online. There are also lots of local user groups like Ubuntu Utah that can help you get it installed and answer any questions you have along the way.

Anyway, give Linux a try; you’ll probably like it. I for one, am never going back to Windows.

Here’s a quick example of weighted round robin in php.

//weighted round robin
 
define("START_WEIGHT", 1);
class printer
{
  private $name;
  private $weight;
  private $normalizedWeight;
  public function printer($name,$weight=START_WEIGHT)
  {
    $this->name=$name;
    $this->weight=$weight;
  }
  public function getName() { return $this->name; }
  public function getWeight() { return $this->weight; }
  public function setWeight($weight) { $this->weight=$weight; }
  public function getNormalizedWeight(){ return $this->normalizedWeight; }
  public function setNormalizedWeight($weight) { $this->normalizedWeight=$weight; }
 
}
 
$printerList=array();
$printerList[]=new printer("printer1",1);
$printerList[]=new printer("printer2",2);
$printerList[]=new printer("printer3",4);
$printerList[]=new printer("printer4",1);
 
$jobList=array(‘job1′,‘job2′,‘job3′,‘job4′,‘job5′,‘job6′,‘job7′,‘job8′,‘job9′,‘job10′,‘job11′,‘job12′,‘job13′,‘job14′,‘job15′,‘job16′);
 
$min=2147483647; //a large number
foreach($printerList as $printer)
{
  $min=($printer->getWeight()<$min)?$printer->getWeight():$min;
}
foreach($printerList as $printer)
{
  $printer->setNormalizedWeight($printer->getWeight()/$min);
}
 
$jobCount=count($jobList);
while($jobCount>0)
{
  foreach($printerList as $printer)
  {
    $jobCount=count($jobList);
    if ($jobCount>0)
    {
      $jobList=jobPush($printer,$jobList,$jobCount);
    }
  }
}
 
function jobPush($printer,$jobList,$jobCount)
{
  for($x=0;$x<$printer->getNormalizedWeight();$x++)
  {
    if ($jobCount>0)
    {
      $job=array_shift($jobList);
      $jobCount–;
      echo($printer->getName()." getting ".$job."n");
    }
  }
  echo("n");
  return $jobList;
}

I've been doing a lot of looking at the git subtree merge strategy for tracking remote projects. Ideally, our remote projects would be tracked with submodules. The issue is, we are developing our own libraries for use in our own internal projects. We commonly do major development on the libraries and the [...]

A protocol is nothing if never used. Well, okay, maybe it can be a joke. Maybe. Okay, so that's not really a protocol. Evil Bit jokes are still positive net karma, right?

Likewise, IPv6 is pretty much useless if it is never used. I can assign the addresses all I please but ultimately if all I do is ping my desktop that sits "behind NAT" with it then for the most part the effort was wasted.

My server runs CentOS 5.2, my desktop runs Gentoo, my laptop Debian, my router Debian, my windows desktop Vista (dual boot Server 2008), and the Vista box also has three instances of OpenBSD running within VMWare.

I've got a pretty good testbed to see just what does/doesn't support IPv6, in terms of everything general web browsing to random system daemons to whatever end user programs you have a desire to run. So, I put together a small bit of info concerning what handles IPv6 perfectly, what is kind of broken, and what just looks at it with a mystified look on its face.

So to start:

Operating Systems

Windows
As far as I know, the first IPv6 stack was available for Windows 2000 via a separate download. XP bundled it by default, but left it uninstalled. Vista has the IPv6 stack enabled by default.

Linux
Got a pretty new IPv6 stack with 2.6. Had a working stack in 2.4. I'm pretty sure 2.2 had a functional stack too, as did 2.0. Don't quote me on that.

OpenBSD
Has supported IPv6 since 2.7.


Services/Servers

Apache
Apache has support IPv6 ever since the 2.0 release. Every component of apache that I tested supported IPv6 just fine, from general web page serving to SSL to proxies. Considering how much of the web is still on 1.3, all of those hosts will have to be upgraded to 2.0+ before a much wider IPv6 web base is available.

IIS
IIS (the Microsoft webserver) has supported IPv6 from their 6.0 release, also known as Server 2003. Most places use at least 2003 on their servers, the era of Win2k webservers kind of died out with Code Red and all of those other worms.

MySQL
Just kind of sits and looks at IPv6 like it has no clue what it is. Which is actually entirely true. Boo.

PostgreSQL
Talks happily with IPv6. At least I think. I'm too lazy to start my local copy and check. Their page on the matter isn't what one would call descriptive. No clue when this support was added.

MSSQL
Supported since their 2005 release.

Oracle
Offically supported as of 2006.

Samba
Supported as of the 3.2 release, which was actually just on June 1st of this year.

Windows SMB/CIFS
Supported with XP and onward. Probably Win2000 too.


So the servers are looking pretty good. Unless you run MySQL, which is pretty much everyone. Boo.

At a minimum, we can serve any content over HTTP just fine, and we can access most database just fine too, unless your name starts with a "My" and ends with a "SQL."



End-user programs

Mozilla Suite (and Firefox, Thunderbird, Seamonkey and friends)
Native IPv6 support, ever since the year 2000. Still has some work to be done according to the meta bug, but pretty much all of those bugs are on random operating systems that don't adversely change your ability to connect to IPv6 enabled sites.

Internet Explorer
Supported IPv6 ever since 4.0, once you applied a patch from their research division. Likewise real native support was probably with 5.0, if not it was by 6.0.

Outlook
Supported as of Outlook 2007.

Kopete
Supported. The KDE project has traces of IPv6 development starting around 1999. As far as I can tell, IPv6 is natively supported in every program in 3.5.

Pidgin
Supported. Not clue as of when due to the GAIM --> Pidgin name change, and I'm far too lazy to figure that out.

MSN Messenger, AIM, ICQ and friends
Who cares? (Likely not supported, though I doubt the client is the blocker in these cases.)

PuTTY
Supported since '04.

OpenSSH(d)
Supported. Probably since forever. Go OpenSSH.

irssi
Supported!

mIRC
Not supported without loading a third-party DLL. mIRC sucks anyway.

X-Chat
Supported.... on Windows since '03, *nix and friends likely even earlier.



I could go on and on and on. I won't, because I have no desire to list hundreds of thousands of software packages and their relative IPv6 states. Plus I'm getting tired and this entire post was spontaneous. Not too bad for 30 minutes of google.

But for the most part, we've got a great picture. Every operating system, browser, and web server supports IPv6 and supports it fantastically well. Nearly every program on *nix supports IPv6 and has for quite some time, and most of the big name Windows programs support IPv6 as well.

Not mentioned here was DNS, but the protocol has had support for it since (just about) forever and now that we have AAAA records for the root servers in the public DNS, DNS is good to go with IPv6 from start to finish.

Now we just have to work on the ISPs and home grade routers...

Footnote: one of the comments I got on my initial IPv6 entry was someone reporting success in integrating their LAN with IPv6. While I'm glad to hear it, I'm even more glad that when I got the "unapproved comment has been posted" notification e-mail, the corresponding IP address was a v6 address. The second I had IPv6 up and running on my server, I threw in AAAA records for pretty much everything. If I had to guess, they didn't even know they were using IPv6 to view this blog and post the comment - which is exactly the goal.

Google just released their new browser, Chrome. You can read all about it, comic-style, on Google Books.

I just downloaded it. I’ll let you know how it goes

Craig Burton has written a nice essay on why software infrastructure behaves differently, economically speaking, than other products and why that upsets the natural inclination most people have relative to protectionism. That, of course, is what the whole net neutrality debate is about.

As Craig says, artificially disrupting the "run to ubiquity" in the software infrastructure on which we all depend, disrupts all players: all

So here is my point about the inverted supply and demand model; today's core software infrastructure is made up of a core set of services. Roughly, file, print, web, database, directory, security, and the Internet protocol suite. Anything that artificially restricts the growth of this infrastructure compounds growth limitation on almost all technology across the board.

From Ruminations of a Software Man
Referenced Fri Aug 15 2008 09:48:23 GMT-0600 (MDT)

Tags: net+neutrality internet software infrastructure

Team size can make a big difference in the success of your service or product. What is counterintuitive for most people is that the larger the team size, the lower the likelihood of success for your service or product.  Why? Entropy can set in and large teams are inherently bad vehicles for communication. More insipid, however, is that the larger the team, there is a higher likelihood of accountability and responsibility being diffused across the team.

When accountability and responsibility is massively diffused, then the mantra holds: if everyone is charge, then nobody is in charge.  In this article, I quantitatively show the inverse relationship between team size and productivity & how team size does impact the effectiveness of communication and accountability & the eventual success of the service or product.

I’ve written about efficient teams before here and here. When I was at Amazon, teams were organized into small, delta teams called “2-pizza teams”: no team should be larger than 2 pizzas can feed. It’s a great approach to team size. In my short career, I’ve learned how true that rule is. Here’s another thing I’ve learned –

• 2 people are smarter than one
• 3, 4, 5, 6, 7, 8 people are smarter than 2
• a team larger than 9 people is just a big dumb gelatinous blob (acronym: BDGB)

Okay, that’s not true at a wholesale level, but it sure feels like it. A small team with highly smart and capable team members can do much more than 10 mediocre team members. The Wisdom of Crowds mentality doesn’t work that well when it comes to efficiency in teams.

A more quantitative explanation is as follows:

One of the root causes of failure in projects is communication — either a lack thereof, miscommunication, or hand-off’s.  Large teams are inherently vehicles for bad communication. This is basic combinatorics — for a given project, suppose there are persons A and B. In this scenario there is only 1 communication link. Add person C, now we have 3 communication links, A-B, B-C, C-A. Add person D, then we have 6; Add person E, then we have 10 communication links. Inductively, as team size grows, the raw combinatoric communication link counts grows geometrically, not linearly. To demonstrate this, we use basic statistics of the form n-choose-r, where !, such as n!, is equivalent to n factorial, to arrive at the formula for how many pairs we can choose from n items:

For the number of pairs, we can reduce the above formula to the following:

Visually, as team size grows, the communication links grows non-linearly, but exponentially:

A Rejoinder

Do not let the above dissuade you from large teams; if the product requires a large team, then that is what is needed. Caution, is what I am arguing here. The facts are that the larger the team, the more communication channels there are and the entire process then becomes more error-prone. If the product requires a large team, then expect the above challenge and manage it.

A Conclusion

There is wisdom in Bezos’ notion of the 2-Pizza Team. Small teams — provided you have the right people — work incredibly well. Also, there is wisdom in Toyota’s usage of Obeya or “The Big Room” as a way to mitigate defects caused by large teams. A combining of the two will most likely make for a great team and a successful product.

Articles on Ethnography and Design:

1. Feature? What Feature?
   
2. Simplify The Product
3. Ask Aza Raskin
4. Aza Raskin on Poka-Yoke & The Humane Interface
5. Aza Raskin on Quasimodal Design and The ATM
6. Aza on Feature-Bloat and Site Clutter
7. Aza on Google Search Results Page
8. Aza on Cooperation and Team Size
9. Design Thinking in Medicine
10. On Designing a Watering Can for Little Hands
11. Queueing Theory and Visual Management
12. An Interview with the Inventor of “Clocky”
13. Bad Breath but Good Design
14. What is Ethnography

Articles on Leadership:

1. Overmanaged and Underled
2. Colin Powell on Leadership
3. Team or Staff?
4. Tipping-Point Leadership
5. Abraham Lincoln on Leadership
6. How to transform an Organization: Chime-in Before Buy-in

Articles on Queueing Theory:

• Queueing Theory: Part 1
• Queueing Theory: Part 2
• Queueing Theory: Part 3
• Queueing Theory: Part 4
• What is Waste?
• On Time-Traps and Waste
• Call Centers as Queueing Systems
• Travel Time & Waste
• Little’s Law for Product Development
• YouTube’s Queueing Properties
• Psychology of Queueing and Disneyland
• Queueing, Disneyland, and FastPass
• Multi-Tasking Leads to Lower Productivity
• Queueing Theory and Terrorism
• On Queueing Theory and Elevator Mirrors
• Psychology of Queueing, Haunted Houses, and Halloween
• The Variability Tree
• Attitude and the Psychology of Waiting - The Psychology of Queueing

Articles on Operations, lean and six sigma:

• Managing Constraints Under Peak Volumes
• Order Pipeline of Events
• On Game Theory
• Applied Regression Analysis
• 5S
• Click-to-Ship Processes
• Kanban Sizing and “Pull”
• Lean at Krispy Kreme
• Theory of Constraints and Camping
• Lean for Software Development
• Don’t Waste the Customer’s Time
• Featuritis and the Focus on the Customer

Time to check the disk free space in GB and percentage on a server volume...

WMIC(Windows Management Instrumentation Command-line) makes another appearance!

Thanks to Tipsmark for this syntax (Response number 17 in this post). I added the /node switch and some error handling / usage to have this batch file work on remote machines.

@ECHO OFF
IF "%~1"=="" goto help
IF "%~2"=="" goto help

@SETLOCAL ENABLEEXTENSIONS
@SETLOCAL ENABLEDELAYEDEXPANSION

@FOR /F "tokens=1-3" %%n IN ('"WMIC /node:"%1" LOGICALDISK GET Name,Size,FreeSpace | find /i "%2""') DO @SET FreeBytes=%%n & @SET TotalBytes=%%p

@SET /A TotalSpace=!TotalBytes:~0,-9!
@SET /A FreeSpace=!FreeBytes:~0,-10!
@SET /A TotalUsed=%TotalSpace% - %FreeSpace%
@SET /A PercentUsed=(!TotalUsed!*100)/!TotalSpace!
@SET /A PercentFree=100-!PercentUsed!

IF %TotalSpace% LSS 0 goto error

@ECHO Total space: %TotalSpace%GB
@ECHO Free space: %FreeSpace%GB
@ECHO Used space: %TotalUsed%GB
@ECHO Percent Used: %PercentUsed%%%
@ECHO Percent Free: %PercentFree%%%

@SET TotalSpace=
@SET FreeSpace=
@SET TotalUsed=
@SET PercentUsed=
@SET PercentFree=
goto end

:error
echo.
echo *** Invalid server or drive specified ***
echo.
goto help

:help
echo.
echo diskfree.cmd
echo.
echo Queries remote server for free disk space.
echo Specify a MACHINENAME and a drive letter to be queried
echo.
echo Example:   diskfree.cmd MACHINENAME c:
echo.
goto end


:end

I'm at the Utah Technology Council's CTO P2P forum this morning. Nate Bowler, a former collegue at Excite@Home and CTO of @Task is speaking about SaaS, software as a service.

Nate says that his number one take-away from this talk is: Pick a market that is underserved or could benefit from the improved delivery model of a SaaS platform and serve it in a non-trivial manner. Emphasis on "non-trivial." Often companies dumb down their SaaS offering. Nate stresses the importance of using the same technology stack for on-premise and on-demand options.

In order to deliver SaaS, you have to be able to support billing, provisioning, and back office tools over and above the base level of software functionality. Beyond that you probably also need multi-tenancy.

And, of course, there's the scalability issue. A critical question is how scalability concerns line up with the business model. What are the hardware demands per customer? Per user? This information needs to be fed back into the product pricing.

Billing can be a big deal. Many people start out with home grown billing systems that limit their flexibility. Most companies start off with a single "this is how we're going to price things" plan, but clients have different ideas. Are you going to pass up a client because they want to pay in a way that you're billing system doesn't support? Instead you'll probably end up constantly hacking the billing system.

You need to be able to monitor every component of your application stack: systems, network, and processes; availability; application functionality; and user experience. In addition to monitoring these things, you need to be watching trends to avoid surprises.

Security is obviously a big deal. You need instrusion detecion systems, SAS70 compliance for business processes, and external auditing of security issues like XSS, data partitioning, and software patch levels to protect customer application data. Automated testing needs to be rigorous.

Some thoughts from Nate on pricing:

• You can't offer SaaS level service for traditional pricing (perpetual licensing) and survive. You can get by in the out years with just maintenance dollars (typically 20%).
• Price on-demand and on-premise the same and keep release cycles in lock step.
• You need the discipline to walk away from deals that won't accept a term license.
• Term pricing value to customer breaks down in 2 conditions: when the contract duration is greater than 3 years and when the user count grows beyond 200 users.
• Terpetual pricing is an option: customer pays 180% of annual price in first year and pays 35% in years two and three. The idea is that it's still cheaper than a perpetual license deal for the customer in year one, but is more inline with how they're used to buying software--big upfront fee followed by maintenance.

@Task has had good luck selling on-premise software with term licensing.

One of the ideas Nate brings up that's pretty interesting is implementing a Digg-like feature for your product roadmap and letting your customers vote for features that are important to them.

@Task has found that most customers opt for on-demand rather than on-premise contrary to conventional wisdom. Similarly, they haven't found that a self-sign up with free trial was an effective strategy for generating leads. This may be specific to @Task that has a fairly complex, group-oriented product. The enterprise nature of the activity means that free trials have to be carefully orchestrated.

Tags: software saas licensing

I’ve blogged about this in the past but it seemed to be overlooked.  I blame the poor choice of title.  In any event, I figure it would be worth revisiting as I’ve had a few suggestions on it being a good topic.

note: Your mileage may vary.  I’ve seen these steps suggest a much faster repository and in other cases they can end up being slower.  Perhaps try two or three until you find a good one.

Updating Your Repository Server

Software packages and security updates are made available in Ubuntu by way of a software repository.  These repositories are mirrored all over the world, many times very close to where you live.  I, for example, have three mirrors within 50 miles of my house.  These are generally much faster than the core Ubuntu repositories.

To find a repository near you, or have your system scan for the fastest (which may or may not be local to you), you will need to launch the Software Sources tool.  This can be found in:

System > Administration > Software Sources

This administrative menu will allow you to change the location of your repository, and which items within the repository you want to subscribe to.  You will have the most software available if all boxes are checked.

From here we’ll want to select “Other” from the drop-down menu and we’ll be provided with a list of available servers.

To have your system try and find the fastest server you can select the “Select Best Server” option, which will try to connect to each repository mirror and track the fastest responses.  The location selected when this process is done should be the fastest available mirror at that time.

Remember, repository mirror speeds can fluctuate based on traffic and other factors.  For best results you might try this scan periodically and find which mirrors are consistently the best for your location.  Enjoy!

Other Points of Interest

• How To Create An Ubuntu Repository Mirror on Ubuntu 8.04

A good friend of mine, Nathan Sandland, has written a time tracking applications for the Mac called ChronosX. He says:

I came up with the idea for the project when I switched from being a PC user to a Mac user last year. The one application on the PC I couldn't find a good replacement for on the Mac was my time tracking app. There are many such apps out there for OS X, but none of them was as convenient to use as the one I had on the PC. This new app solves that problem, and also adds some nifty features, such as direct integration with Apple's iCal calendaring application, so you can see your working time logged right alongside your regular calendars.

I really like that it published an iCalendar feed that you can access as a URL. I don't need to track time for projects right now, but seeing Nathan's program almost makes me wish I did!

Tags: osx software

Joel Spolsky, of Joel on Software and Jeff Atwood of Coding Horror have been doing a podcast called StackOverflow for a couple of months. I've been a regular listener for since the first episode and have loved it. Since the first episode, I thought "this would be a great show for IT Conversations."

Today I'm very happy to announce that my wish has come true and the debut episode of StackOverflow on IT Conversation went live today! Take a listen and be sure to let us know what you think with a comment or by leaving a rating.

One note: This is a weekly show that will usually appear on IT Conversations on Wednesdays. We still have lots of great conference material too, so there will be days that we publish more than one show. Make sure your podcatcher is set to capture more than one show a day. This is especially important if you use iTunes to grab IT Conversations since it downloads at most one show per day by default.

Tags: itconversations software

Update: Its really Office 2008...

Microsoft Office 2007 on OS X is a complete pig. I was so looking forward to finally having an Intel native version of Office so I wouldn't have to put up with long start times and the SBOD (spinning beach ball of death). With Office 2007, they're worse! I've rarely been as disappointed in a software product. Office 2004 is a better Office--even in Rosetta. Heck, Office on XP running in Parallels is a better Office. I'm glad BYU has a site license because I'd be really mad if I'd actually paid for this.

Tags: microsoft osx software

So, you're using Latex to compile a paper, article, or book. If you have any type of table of contents, index, or bibliography, you've probably noticed that you have to run latex two (or sometimes 3) times to generate the final document. In addition, you probably have to run a conversion program to [...]

A commenter pointed out on my original post about Apple Mail and Gmail that you can manage multiple Gmail identities by separating each email address with a comma. Here are the steps: If you have already set up your Gmail identities on Gmail, you can go to the next step. You can't use an [...]

1) In Google We Trust - I and my companies are moving everything (emails, blogs, websites) away from commercial domains and shared hosting and onto Google. I am tired of the “give us your credit card and then we keep charging you or dinging your credit report” hell that ISP’s are doing. And with a recession coming, it’s not a bad time to go free. So this domain and blog site will be ending shortly - if, of course, I can get them to stop charging me!

Do I have privacy concerns about having everything on Google? Absolutely. Oh sure there’s the govt. spying and competitors maybe learning something from us. But that will happen anyway and frankly there’s not much to see. I’m actually more afraid of something like woman A doing a google search and finding out about my gmails to woman B. Now that could get me shot.

2) Improve my Spanish - There will be more business opportunities with Mexico and South America so this might help. At least it will make it easier for me to order my favorite bagel sandwich in Park City.

3) Somehow Expand International Exposure and Activities - 50% of the world’s building cranes are now in Dubai. In the US, we will only have the money, at best, to fix what infrastructure is breaking. And selling our highways to the foreign sovereign wealth funds. The real infrastructure action is now elsewhere. If I was in my thirties, I would be overseas. This goal will be the most challenging of all.

4) Expand Learning and Use of Python - The future is here for fast, dynamic computer languages that adapt well to intelligent programming. I just wish the Python community gets a few more SXSW type characters that can put together a lean web framework that us normal people can use.

5) Swear Less - I’ll try, especially about all those fs$k*&g poorly-timed traffic signals, especially in Utah County.

6) Try to attend 2 movies this year - “IOUSA” at Sundance (if you have to ask it’s probably not for you) and the next X-Files movie they keep promising. Fox Mulder lives.

7) Continued Involvement in the Open Source Community - It’s such an incredible group of intelligent, fun, dynamic people - too bad it doesn’t run the country, yet. See you at SCALE!

This month marks the 7 yr anniversary since switching to Linux. What a ride! In the early days it was pretty tough, some of my employees flat out resisted, one kept doing our graphics in Illustrator that none of the rest of us could view. Another quit when she couldn’t use Dreamweaver. A lot of the hardware like our old backup tape drives were not well supported. We lost stuff on Zip drives.

Today, it’s so different, it’s hardly noticeable. A few minutes ago I plugged in our scanner into a Fedora 8 laptop and the printer/scanner was instantly configured and all I had to do was click on the XSane menu item and click the scan button and up popped a perfect scanned image, ready to be saved to file. Oh some things still are troublesome, like the ever changing wireless chips on MacBooks, but all in all, everything now just installs and works.

Using Linux (and Open Source) in business has also taught me many things: agile and lean methods of doing business, the need to collaborate more, switching to the internet and away from phones, and to appreciate the many fine, wonderful people from all over the world, yes my Republican friends, even people from France It has also changed my outlook with time - I’m never quite sure what time it is for the person I’m communicating with. I now don’t even wear a watch (I’m never on time for meetings anyway). In the early days Linux may have been a drag on my businesses, diverting time away from making money - today I consider using Linux and Open Source as a competitive advantage. We now do things faster, better, cheaper. I’m hoping the 8th anniversary finds us using great Linux tablets! Woot!

I usually don’t blog about bad customer experiences since any business can have an outlier event. But it’s just not our bad experience with Yahoo, consider the following:
a) their profits, stock price, and return on equity is significantly down the last 2 years, indicative of problems
b)I saw a large number of negative comments from others having similar poor domain hosting experiences with Yahoo.
c) Even their UI keeps hanging in Firefox (javascript calls don’t seem to work) and their people insist we use Internet Explorer which we don’t use or own - can’t they even write cross browser code ?

Right now Yahoo is holding a domain of one of my companies hostage. Due to an overlooked email address and an old credit card, the domain became suspended and Yahoo is holding it. So we’ve tried to rectify the problem and renew the domain - it should be simple, all our ICANN info is correct. But Yahoo continues to stonewall, waste our time, and refuse to help us. What do they want to do? Sell it off to another company that will try to domain blackmail us? What a way to really piss off revenue customers. Little wonder their profits and stock price are down significantly.

Ironically, Yahoo could have easily used this as an opportunity to upsell us on other small business services for additional revenue and to encourage us to become a YUI or Map partner but instead Yahoo has taken the route of constantly refusing to work with us, waste our time and really piss us off - and that reflects really poor management. So poor that I am now advising my investment friends to sell or stay away from Berkshire Hathaway stock since Warren Buffett recently appointed Susan Decker, Yahoo’s president to the board. Why invest big dollars in a company that is being governed by a director whose management is treating customers poorly, losing profits, and hurting stockholders? And yes, I’m old fashioned and do think the company president is responsible for what happens down in the company trenches and with even us, the small customer. I like to say where there is smoke, there is usually fire. I get much better service at even McDonald’s or Wal-Mart. No Yahooo for this customer.

Today, Mary Poppendieck responds to Corey Ladas‘ question on the relationship between Agile and Lean and what to make of all the methodologies in software engineering.

Corey Ladas said,
November 28, 2007 @ 4:23 pm

Lean would seem to allow for a broader set of ideas and practices than some Agile adherents would find acceptable. For example, SEI Team Software Process seems closer to Lean both in spirit and in pedigree than much of the Agile body of practice, yet many Agilists regard Watts Humphrey as a villain. 

Has Agile become the new orthodoxy? How does Agile add value to Lean? Will the prejudices of the Agile community limit the progress of Lean ideas within software development? When do we get to drop the Lean/Agile qualifier and just be Lean?

MBP >> 

Hi Corey.  I have seen and admire your work in Lean Software Engineering, and I often refer people to your excellent website.  I recently had the opportunity to work with a superb open source team that had a much deeper understanding of top notch software engineering practices than I find in most agile environments.  I observed that “by-the-book” agile practices are hardly the only way to develop great software.  As you know, when the lean principles of pull and flow are combined with good software engineering practices, the results might not fit the agile mold, but they can be quite dramatic.

Agile and lean are just the latest in a series of good software development approaches that I have seen rise in popularity over the years.  They join the ranks of software engineering, structured development, JAD, rapid prototyping, CMM and others….  Every one of these approaches has been used to great effect in some companies, while others adopted it in search of the elusive silver bullet.  It seems that every seven years or so, our industry has to learn one more time that software development is complex, challenging work that takes skill and discipline to do well.  What changes over time are the tools available to do the job well; what never changes is the simple fact that there is no such thing as a silver bullet.

If you are interested, go here for a previous interview with Mary and Tom Poppendieck

Please find originally-written articles on Queueing Theory below:

• Queueing Theory: Part 1
• Queueing Theory: Part 2
• Queueing Theory: Part 3
• Queueing Theory: Part 4
• What is Waste?
• On Time-Traps and Waste
• Call Centers as Queueing Systems
• Travel Time & Waste
• Little’s Law for Product Development
• YouTube’s Queueing Properties
• Psychology of Queueing and Disneyland
• Queueing, Disneyland, and FastPass
• Multi-Tasking Leads to Lower Productivity
• Queueing Theory and Terrorism
• On Queueing Theory and Elevator Mirrors
• Queueing Psychology at the Gas Pump
• Psychology of Queueing, Haunted Houses, and Halloween
• The Variability Tree

For a few articles on Operations, lean and six sigma, please visit the links below:

• The Gemba is the Dojo

• Managing Constraints Under Peak Volumes

• Order Pipeline of Events

• On Game Theory

• Series on Queueing Theory

• Applied Regression Analysis

• 5S

• Click-to-Ship Processes

• Kanban Sizing and "Pull"

• Lean at Krispy Kreme

• Theory of Constraints and Camping

• Lean for Software Development

• Don’t Waste the Customer’s Time

• Featuritis and the Focus on the Customer

Share This

After I set up Apple Mail to use my Gmail account, I had a couple things I was still having to go to the Gmail web interface for. One of those was managing multiple labels for a particular message. Since that time, I did some experimenting and have figured out how to manage [...]

Last week, I invited the readers of shmula to pose questions to Mary and Tom Poppendieck, the authors of Lean Software Development: An Agile Toolkit for Software Development Managers (Paperback), which won the Software Development Productivity Award in 2004 and, the sequel Implementing Lean Software Development: From Concept to Cash (Paperback).  Several questions were submitted and, over the next several weeks, I’ll be posting Mary (MBP) and Tom’s (TDP) responses.

Earlier, Mary and Tom responded to the question of Waste and the Handoff in software development.  Today, they respond to two questions from Ursula Rutherford:

Ursula Rutherford said,
November 16, 2007 @ 3:55 am

The term “Lean” is very little known in the software development and system delivery industries. Do you expect there to be more explicit use of it in the future? 

It seems IS people are treading their own path towards quality management and capability maturity without reference to other industries. Perhaps if Lean were a more well-known term in IS, we could benefit from several decades of experience and from training in lean principles.

MBP >>

I have to agree, there is a lot to be learned from good old “low-tech” industries.  What will drive improvement into software development is competition - in highly competitive industries, there is no alternative but to find the approach that has the least waste, lowest cost, and highest quality.  As software becomes more and more pervasive, those who develop systems wisely will end up at the top of the competitive hill.

TDP >>

Lean looks at the whole value stream from concept to cash or order to payment.  It delivers more value by avoiding sub-optimizing choices and handoffs.

About 1/2 hour later, Ursula poses another question to Mary and Tom Poppendieck:

Ursula Rutherford said,
November 16, 2007 @ 4:22 am

Making a broad generalization, it seems lean initiatives in many industries need top-management support to have a chance of success. In contrast, there are many accounts of agile   programming techniques being adopted at team level with good results.

At what level of organizations do you recommend lean software development be introduced?

Imagine an organization with high-level sponsorship and a generous budget to make software development lean… Should change begin with education or practice; in the development team or the boardroom; slow or fast; a pilot project or ‘for real’; imposed by decree or encouraged by incentives?

MBP >>

Where to start is very dependent on the context and on the location of the biggest constraint.  If the biggest constraint is a huge end-of-cycle test and merge bottleneck, then you can make huge strides by getting stop-the-line testing disciplines in place.  This involves integration of testing with development, but that might be possible at a rather low level.

On the other hand, if the biggest constraint is caused by thrashing because more work is being dumped on the development organization than it can hope to handle, then higher level of management involvement is usually necessary to make a big difference.   If the approval process is insisting that a host of low priority features be developed, you have yet another problem that needs to be addressed from the perspective of a broader organization. 

I generally recommend that you do a rough value stream map in order to find the biggest constraint in your system.  Actually, people probably already know what the biggest constraint is, but are reluctant to confront it, and a value stream map might just help to put difficult issues on the table for discussion.  Once you have found and are ready to confront the biggest constraint in your development process, then you don’t need a value stream map for a while, instead you need a top notch, team-based process improvement process that addresses and gradually removes the key constraint.  Since the constraint generally occurs at organizational boundaries, it usually helps to have senior management involvement at this point.

TDP >>

At its heart, Lean is a management philosophy based on deep respect for people and relentless elimination of waste from the delivery of value to customers to return sustainable prosperity for the organization.  Sustainable deployment of Lean (or Agile) must reach high enough in an organization to control the entire value stream and to control how people are treated.  In some cases, this may only extend to departmental or divisional level management, in other cases, it may need to extend beyond organizational boundaries to an entire supply chain.  How people are measured and rewarded determines how they will behave in the long run.

If you are interested, go here for a previous interview with Mary and Tom Poppendieck

Please find originally-written articles on Queueing Theory below:

• Queueing Theory: Part 1
• Queueing Theory: Part 2
• Queueing Theory: Part 3
• Queueing Theory: Part 4
• What is Waste?
• On Time-Traps and Waste
• Call Centers as Queueing Systems
• Travel Time & Waste
• Little’s Law for Product Development
• YouTube’s Queueing Properties
• Psychology of Queueing and Disneyland
• Queueing, Disneyland, and FastPass
• Multi-Tasking Leads to Lower Productivity
• Queueing Theory and Terrorism
• On Queueing Theory and Elevator Mirrors
• Queueing Psychology at the Gas Pump
• Psychology of Queueing, Haunted Houses, and Halloween
• The Variability Tree

For a few articles on Operations, lean and six sigma, please visit the links below:

• The Gemba is the Dojo

• Managing Constraints Under Peak Volumes

• Order Pipeline of Events

• On Game Theory

• Series on Queueing Theory

• Applied Regression Analysis

• 5S

• Click-to-Ship Processes

• Kanban Sizing and "Pull"

• Lean at Krispy Kreme

• Theory of Constraints and Camping

• Lean for Software Development

• Don’t Waste the Customer’s Time

• Featuritis and the Focus on the Customer

Share This

Last week, I invited the readers of shmula to pose questions to Mary and Tom Poppendieck, the authors of Lean Software Development: An Agile Toolkit for Software Development Managers (Paperback), which won the Software Development Productivity Award in 2004 and, the sequel Implementing Lean Software Development: From Concept to Cash (Paperback).  Several questions were submitted and, over the next several weeks, I’ll be posting Mary and Tom’s responses.

A quick note on convention:

MBP: This is Mary Poppendiek’s response.
TDP: This is Tom Poppendiek’s response.

Below is the first question-and-answer in the series:

John D. Heintz said,
November 15, 2007 @ 1:43 pm

Many Agile methods suggest a division of responsibility between the Customer and development team. The Customer is responsible for understanding and prioritizing the business needs and the dev team is responsible for estimating and implementing solutions.  This business/technology division of labor seems simple, visible and I can understand the daily responsibilities of each side.  The downside to this is (paraphrasing you from the lean development list) a we/they divide leading to local optimizations.  An alternate structure is the “Chief Engineer” who is responsible for the total business success of a product and leading the engineering as well.

My question: How does the division and delegation of responsibility differ when a Chief Engineer is responsible for the business success?  A Chief Engineer must have broad business and technical experience, but this person can’t be responsible for everything, all the time.  The best guess I can think of is to characterize the two styles into:

• Vertical Style: business/technical sides with a communication contract.
• Horizontal Style: A central figure that uses set-based design to constrain the next levels of work.

Interested in your experience and thoughts,

John

MBP >>

I recommend that you check out the book Lean Product and Process Development by Allen Ward (Lean Enterprise Institute, March 2007).  Allen Ward spent years leading studies of Toyota’s product development process.

He claims in the book that the biggest waste in product development is found at hand-offs.  A handoff occurs whenever you separate responsibility (what to do), knowledge (how to do it), action (actually doing it), and feedback (learning from results).  The problem with a we-they relationship between “the business” and “the development team” is that it creates a huge handoff, and embedded in that handoff is significant lost knowledge, and hence serious waste.  The development team should not be separate from the business, it should be a part of the business.  In this book Ward also discusses the role of what he calls the “entrepreneurial systems designer” (ESD), and he gives a good explanation of the role. 

But to address your question directly, in a culture with product champions (as we had at 3M) or Chief Engineers (as at Toyota), the focus of activity is on a specific value stream (product & its support structure), while the focus of knowledge creation is on the horizontal (functional) organization.  This is to say if your company distinguishes itself by being really good at User Interaction Design, or test frameworks for hardware, or highly resilient transaction processing, or whatever, you had better develop and protect an unassailable technical capability in the areas that constitute your competitive advantage.  This technical capability will be applied to products (led by a product champion), but needs to be protected as an organizational core competence (perhaps under the guidance of a functional manager).

TDP >>

When a new engineer joins Toyota, they spend their first six months working in a factory building cars.  They spend the next few months working in a dealership selling cars.  Toyota considers well worthwhile this investment in providing the people who design their products with a deep, first hand understanding of the human consequences of their design decisions.  There are no strictly technical or strictly business decisions.  Each area both enables and constrains the other.  The chief engineer holds the vision of how the customers can be profitably served, and collaborates with the team members to iteratively refine the vision into a collection of features and implementations.  Each team member ensures that from their specific functional perspective the result will deliver sustainable value. Tradeoffs often cross functional boundaries.

If you are interested, go here for a previous interview with Mary and Tom Poppendieck

Please find originally-written articles on Queueing Theory below:

• Queueing Theory: Part 1
• Queueing Theory: Part 2
• Queueing Theory: Part 3
• Queueing Theory: Part 4
• What is Waste?
• On Time-Traps and Waste
• Call Centers as Queueing Systems
• Travel Time & Waste
• Little’s Law for Product Development
• YouTube’s Queueing Properties
• Psychology of Queueing and Disneyland
• Queueing, Disneyland, and FastPass
• Multi-Tasking Leads to Lower Productivity
• Queueing Theory and Terrorism
• On Queueing Theory and Elevator Mirrors
• Queueing Psychology at the Gas Pump
• Psychology of Queueing, Haunted Houses, and Halloween
• The Variability Tree

For a few articles on Operations, lean and six sigma, please visit the links below:

• The Gemba is the Dojo

• Managing Constraints Under Peak Volumes

• Order Pipeline of Events

• On Game Theory

• Series on Queueing Theory

• Applied Regression Analysis

• 5S

• Click-to-Ship Processes

• Kanban Sizing and "Pull"

• Lean at Krispy Kreme

• Theory of Constraints and Camping

• Lean for Software Development

• Don’t Waste the Customer’s Time

• Featuritis and the Focus on the Customer

Share This