With the release of version 3.1, FlowBreeze now includes Value Stream Mapping tools. FlowBreeze has two tools that simplify creating Value Stream Maps – the VSM Template Generator and the VSM Symbols task pane. The VSM tools augment the existing text-to-flowchart capabilities of FlowBreeze, and are an added feature for no extra cost – an extremely good value. Plus, FlowBreeze is a Microsoft Excel add-in, so the resulting diagrams can be viewed by and shared with anyone who uses Excel.

VSM Template Generator

The template generator is a way to kick start diagrams by allowing you to make re-usable Excel template files with the base outline on a value stream map. You can set a standard title bar, and add base elements, including supplier, customer, production control, process blocks, and data timelines. Below is an example of a value stream mapping outline created with the template generator.

basic VSM template

VSM Symbols Task Pane

The task pane, shown below, allows you to add symbols two ways: 1) Selecting the symbol, entering shape-specific data, then clicking Add Shape, or 2) by simply doubling-clicking the symbol. Symbols are added to the worksheet in the currently selected cell.

VSM task pane

Available Value Stream Mapping Symbols

  • Process
  • U-Cell
  • Operator
  • Factory (Customer / Supplier)
  • Production Control
  • Schedule
  • Go See
  • Shipment Arrow
  • Push Arrow
  • Manual Information Arrow
  • Electronic Information
  • FIFO lane
  • Load Leveling
  • Kaizen Burst
  • Production Kanban
  • Batch Production Kanban
  • Withdrawal Kanban
  • Batch Withdrawal Kanban
  • Kanban Post
  • Supermarket
  • Buffer
  • Inventory
  • Signal Kanban
  • Physical Pull
  • Sequenced Pull
  • Pull Arrow 1
  • Pull Arrow 2
  • Pull Arrow 3
  • Pull Arrow 4
  • Truck
  • Forklift
  • Airplane
  • Boat
  • Non Value-Added Time
  • Value Added Time
  • Timeline Total
  • Data Table

For more information, visit the FlowBreeze Value Stream Mapping product page. Or, you can go to the product page and download a free trial today.

During the development of FlowBreeze 3.0, I wasted a lot of time mucking around with different approaches to emulating the RefEdit control from C#. If you’re not familiar with it, the RefEdit control looks something like this on a typical Excel form:

(btw, this is actually the after image. the range address would not be present until after the step in the next image.)

Clicking it, you can then select the range with your mouse, as such:

Looking around the net, I found two viable options that would work in C#. One was Gabhan Berry’s article How to code a .NET RefEdit Control. This is a nicely done control, but unfortunately it had two major drawbacks. First, it relied upon a DLL he had created to make working with Excel easier. Second, it was written from the perspective of someone working with Excel externally, whereas I was building a COM add-in. I try to avoid distributing third party libraries where possible – especially if I have to read through the license terms and make sure that I am allowed to distribute the library with a commercial application. The second issue isn’t a show stopper, but it was going to take a decent amount of code re-writing to get it to work with my application.

The other control I came across was RefEdit Emulation for .NET on Code Project. Like Gabhan’s control, this provides a range selector with a small footprint. The major down side, though, was that it only works for non-modal parent forms. This control may be usable on a modal form with a little more work, but by this time I had spent way more time trying to create a range selector then I had originally planned.

Application.InputBox to the Rescue

The old standby alternative to the RefEdit control has been the Application.InputBox() method. In this case, Application refers to the Excel application reference. Instead of the RefEdit range selector with the small footprint, you get a larger forms that looks like this:

The other drawback to the InputBox is that the parent control doesn’t automatically minimize. If you hide the parent before calling InputBox(), the range selector will not become the topmost form and receive focus. In order to activate the range selector, the user would have to notice the flashing menu item on their task bar. The same problem exists if you try to set the parent form’s window state to minimized.

In order to deal with this, I created a little utility function to resize the parent form to the minimum window size, and then “hide” the parent at the base of the Excel window, looking something like this:

Here is the sample code, including a calling button click event, the utility functions to return either the Excel.Range or the range address, as well as an all-purpose method to release COM objects. Due to the general suckiness of this blog format, you will probably need to copy and paste this into an editor to see the full width of the code.

#region ---- Select range ----------------------------------------

private void btnSelectRange_Click(object sender, EventArgs e)
{
    string prompt = "Select the range";
    string title = "Select Range";
    try
    {
        string address = Utilities.PromptForRangeAddress(this, title, prompt);
        if (!String.IsNullOrEmpty(address))
        {
            txtBaseShapeCell.Text = address;
        }
    }
    catch
    {
        MessageBox.Show("An error occurred when selecting the range.", "Range Error");
    }
}

#endregion



#region ---- static utility methods ----------------------------------------
// Requires:
// using System.Runtime.InteropServices;
// using System.Windows.Forms;


DllImport("user32.dll")]
[return: MarshalAs(UnmanagedType.Bool)]
private static extern bool GetWindowRect(IntPtr hWnd, out RECT lpRect);

[StructLayout(LayoutKind.Sequential)]
private struct RECT
{
    public int Left;
    public int Top;
    public int Right;
    public int Bottom;
}


public static string PromptForRangeAddress(Form form, string title, string prompt)
{
    Size windowSize = form.Size;
    form.Size = SystemInformation.MinimumWindowSize;
    Point location = form.Location;
    SetFormPositionForInputBox(form);

    string rangeAddress = string.Empty;
    Excel.Range range = null;
    try
    {
        range = XL.App.InputBox(prompt, title, Type.Missing, Type.Missing, 
                                Type.Missing, Type.Missing, Type.Missing, 8 ) as Excel.Range;
        if (range != null)
            rangeAddress = range.get_AddressLocal(Office.MsoTriState.msoFalse, 
                                                  Office.MsoTriState.msoFalse, 
                                                  Excel.XlReferenceStyle.xlA1, 
                                                  Office.MsoTriState.msoFalse, 
                                                  Type.Missing);
    }
    catch
    {
        throw new Exception("An error occured when selecting the range.");
    }
    finally
    {
        form.Location = location;
        form.Size = windowSize;
        MRCO(range);
    }
    return rangeAddress;
}


public static Excel.Range PromptForRange(Form form, string title, string prompt)
{
    Size windowSize = form.Size;
    Point location = form.Location;
    form.Size = SystemInformation.MinimumWindowSize;
    SetFormPositionForInputBox(form);

    Excel.Range range = null;
    try
    {
        range = XL.App.InputBox(prompt, title, Type.Missing, Type.Missing, 
                                Type.Missing, Type.Missing, Type.Missing, 8  ) as Excel.Range;
    }
    catch
    {
        throw new Exception("An error occured when selecting the range.");
    }
    finally
    {
        form.Location = location;
        form.Size = windowSize;
    }

    return range;
}


public static void SetFormPositionForInputBox(Form form)
{
    int x = form.Location.X;
    bool isSet = false;
    try
    {
        System.Diagnostics.Process[] processes = System.Diagnostics.Process.GetProcessesByName("Excel");
        if (processes != null && processes.Length > 0 && processes[0] != null)
        {
            RECT rect;
            IntPtr ptrXL = processes[0].MainWindowHandle;
            if (!ptrXL.Equals(IntPtr.Zero) && GetWindowRect(ptrXL, out rect))
            {
                form.Location = new Point(x, rect.Bottom - SystemInformation.MinimumWindowSize.Height);
                isSet = true;
            }
        }
    }
    finally
    {
        if (!isSet)
        {
            form.Location = new Point(x, 0);
        }
    }
}


public static void MRCO(object obj)
{
    if (obj == null) { return; }
    try
    {
        System.Runtime.InteropServices.Marshal.ReleaseComObject(obj);
    }
    catch
    {
        // ignore, cf: http://support.microsoft.com/default.aspx/kb/317109
    }
    finally
    {
        obj = null;
    }
}

#endregion

BreezeTree is happy to announce the release of FlowBreeze 3.0 – flowchart add-in for Microsoft Excel. A full list of the changes is as follows.

New Features

  • Added support for 64-bit versions of Excel.
  • Added Connectors task pane to simplifyy connector additions.
  • Added Shapes task pane to create shapes by clicking or typing.
  • Added Split Connector tool to split a connector arrow between two shapes into two labeled connector nodes.
  • Added import / export for settings backup and standardizing settings between different computers / users.
  • Added symbol list editor to allow user to specify the actively used set of symbols.
  • Simplified layout and filtering of Shape Selection Tool.
  • Added Export to Web Page (HTML) tool.
  • Added bulk shape dimension editing.
  • Added sorting options for shape selection fields.
  • Added special printing option for flowchart images.
  • Added Straighten Connectors tools to fix jagged lines in Excel 2007 / 2010.
  • Added user-defined spacing between shapes.
  • Improved internal margin settings for non-rectangular shapes (i.e.

Template Generator Improvements

  • Added logo insertion.
  • Added preset header and footer layouts.
  • Added preset swim lane titles.
  • Added SIPOC layout.

Flowchart Wizard

  • Added simple text versus advanced parsing syntax autodetection.
  • Simplified the advanced parsing syntax.
  • Improved the connector routing algorithm.
  • Added ability to overwrite existing worksheet.
  • Input range selection.

Prerequisite

  • The Microsoft .NET 2.0 framework is now a prerequisite for running FlowBreeze.

Time for a periodic update to the BreezeTree Excel version survey. The numbers are below and speak for themselves. The survey data was collected over the last six months, and the target audience was business users. Standard disclaimer: This is not a scientific poll – but without Microsoft publishing these numbers, it’s probably as good as any other estimate.

The data is below. The percentages are based on 1587 data points (otherwise known as people).

  • Excel 2010: 35%
  • Excel 2007: 57%
  • Excel 2003: 6%
  • Excel 2002: <1%
  • Excel 2000: <1%

For comparison, here is the data from the 2009 Excel version survey.

  • Excel 2007: 39%
  • Excel 2003: 46%
  • Excel 2002: 11%
  • Excel 2000: 5%

Commentary

The latest survey shows that Excel 2010 adoption has grown rapidly and 2007 usage has continued to grow (it has probably peaked by now). Meanwhile Excel 2003 usage has fallen dramatically, and Excel 2000 and 2002 (aka, XP) are looking rusty around the bits.

Another way of looking at the data:

  • Ribbon users: 92%
  • Toolbar users: 8%

For the past few years I’ve been running surveys to see what version of Microsoft Excel people are running (and by extension, which version of Office). Before getting to the latest data, the standard disclaimer applies – this polling data is not scientific. The sample sizes are decent but the user base is skewed.  The data is collected from FlowBreeze trial users, which tend to be business-oriented users, and of those, only a small percentage are polled. Also, FlowBreeze runs on Excel 2000 through 2007 on Windows only. So Mac users and Office 97 hold-outs are not represented, nor are users of Open Office and online spreadsheets.

So with that out of the way, let’s get to the data. The graph below of the last six months of 2009 shows that Excel 2007 makes up half the user base. The other half are holding out because they hate the ribbon. (Ha ha, just kidding!)

Excel Version Survey - 2nd half 2009
Excel Version Survey - 2nd half 2009

What’s striking about the most recent trend is the drop off of Excel 2000 and 2002 (XP). In the last two years, they fell from a combined 20% of users to less than 5% , and a big portion of that drop off was in the last six months. On the eve of Excel 2007′s release, Martin Green did a survey that showed Excel 2003 with just over 50% of the market, with Excel 2000 and XP making up most of the remainder. The early 2008 data points below show that Excel 2003 held the same market share after Excel 2007′s release, indicating that XL 2007 adopters had leapfrogged versions.

Excel Version Trend 2008-2009
Excel Version Trend 2008-2009

If history is a guide, after Excel 2010 is released a small portion of adopters will be Excel 2000 and XP users upgrading older PC’s, another small portion will be Excel 2007 users who like to stay on the cutting edge, but the majority should be Excel 2003 users leapfrogging versions. I say “should” because it’s hard to make a prediction. On one hand, Excel 2003 is still a great piece of software, it doesn’t look dated, and a lot of people do not like the ribbon. On the other hand, users of older versions will face increasing pressure to be able to read the new file formats (esp. those w/o the Office 2007 compatibility pack). I wouldn’t be surprised if Excel 2010 had a slow adoption rate, but it will be interesting to see.

Just a quick update to the earlier data on Microsoft Excel / Office user data (see Office Market Share by Version – 2008 Data for reference). For the first six months of 2009, the survey has collected 594 more data points (for a half-year total of 898), with the breakdown as follows:

  • Excel 2000: 4.7%
  • Excel 2002: 10.6%
  • Excel 2003: 46.0%
  • Excel 2007: 38.8%

And, for those of you who prefer visual data, here is the graph:

Commentary

The most stable group of users over the last year and a half has been the Excel XP (2002) users. The recent data indicates that Excel 2007 is cannibalizing market share from Excel 2003 and Excel 2000.

If I have one pet peeve about newspapers, it’s how they represent data. So let’s do a pop quiz. Which graph in the image below shows the worse looking trend?

The truth is, they are three representations of the same trend.

Graph A is the most realistic. The Y-axis scale goes from 0 to 480 and the aperture is roughly square.

Graph B distorts the data to look worse than it really is by using a Y-axis scale from 340 to 480. This is a common trick that was used by tobacco companies to show the nicotine levels in their cigarettes versus competitors. Their cigarettes weren’t really much better than the competitors. They just made sure to have the Y-axis cross the X-axis at a point just below their nicotine level, giving the appearance that it was close to nothing.

Graph C has the opposite effect of Graph B. It distorts the data to make the trend look better than it really is. By elongating the X-axis, the downward slope isn’t as steep.

Of course, the Oregonian published one similar to Graph B this morning, showing the last 13 months of factory orders, per U.S. Census Bureau data. Every time I see a graph like that, I think the reading public is getting bamboozled. The data is accurate, but it’s been sensationalized. (And don’t get me started on the one-data-point trends they see in school test scores.)

[Note: new data added under Updates section below.]

I’ve decided to share some Excel user survey data in hopes that others find it useful. Trying to find data for the market share of the various versions of Microsoft Office products is hard. Microsoft doesn’t publish it, and the only references I find online are typically in articles about the just-around-the-corner ascendancy of open source alternatives. So I decided to run my own survey. For the past year, a random sample of FlowBreeze users has been polled to determine which version of Microsoft Excel they are using. What the data is:

  • Microsoft Excel versions 2000, 2002 (XP), 2003, and 2007.
  • FlowBreeze trial users.
  • Windows only.
  • Can be extrapolated to Microsoft Office versions, since Excel is typically sold as part of the Office suite.
  • Represents primarily business users.

What the data isn’t:

  • A survey of Microsoft Office vs. other office suits such as OOo or Google Docs. (FlowBreeze is an Excel add-in.)
  • It does not include Microsoft Office Sharepoint.
  • It does not include Mac Office. (FlowBreeze is Windows only.)
  • It is not scientific.

(See notes after the graphs.)

Microsoft Office Version Stats - Graph 1
Microsoft Office Version Stats - Graph 1

The graph below is the same data as above but in a stacked column.

Microsoft Office Version Stats - Graph 1
Microsoft Office Version Stats - Graph 2

I didn’t create a raw data tabulation for publishing, but the following table shows the monthly percentages by version. (The total sample count is 1373 users.)

Microsoft Office Versions - Data Table
Microsoft Office Versions - % Data Table

Notes

  • Total sample count: 1373.
  • It is impossible to say whether the early trending is due to the migration toward Office 2007 or the non-scientific data gathering method.
  • The adoption of Excel 2007 seems to have leveled off. One interpretation of this could be that business users that migrate, tend to migrate early.

Conclusions
The most salient point to me as an Office developer is seen in Graph 2. The user share for Excel 2000 is still roughly 10%. The world of Office development has been moving toward .NET (C# or VB.NET) for some time, but Managed COM Add-ins for Excel 2000 are not officially supported by Microsoft. Even developing Managed COM Add-ins that support Excel 2002 forward can be problematic, raising the hurdle to 20% of the Excel market.

Martin Green did a survey in 2006, showing the market share for Excel 2000, 2002, and 2003 to be 18%, 21%, and 54% respectively. His survey included pre-2000 versions as well as Office Mac, so the numbers don’t correlate exactly. But taking those figures as a rough benchmark versus the data above, it suggests that Office 2007 users leapfrogged from previous versions of Excel more than from Excel 2003.

Updates

This section will contain monthly updates to the data, as time permits.

January 2009 – sample size = 147

  • Excel 2000: 4%
  • Excel 2002: 11%
  • Excel 2003: 54%
  • Excel 2007: 31%

February 2009 – sample size = 157

  • Excel 2000: 4%
  • Excel 2002: 15%
  • Excel 2003: 42%
  • Excel 2007: 39%

Neil Davidson has an interesting post questioning the logic of trimming the fat in economic downturns. His isn’t the first blog post I’ve seen recently on the applicability of Lean to software development. As someone with an Industrial / Manufacturing Engineering background who now does programming, I bristle when I see production line concepts applied to software development, so I thought I would chime in on the topic.

There has been a push in recent years (mostly by consultants) to extend concepts from Lean and Six Sigma to service-based industries, but for the most part it doesn’t make sense. Production is deterministic. Work orders are scheduled, raw materials are pulled from stock and production workers have a standardized set of instructions for manufacturing a sub-component or finished good.

The typical work flow for a knowledge worker is not deterministic. You can’t pull a programmer’s brain from stock, run it through a 1-ton arbor press, and squeeze out code to fill an empty software kanban. And even in manufacturing there is a difference between high-volume, low-mix assembly and low-volume, high-mix assembly. Many of the techniques used in Lean, such as value stream mapping, don’t apply well to low-volume, high-mix production, let alone to non-manufacturing.

Another problem is the misuse of ‘Lean’, ‘Six Sigma’, and the combined ‘Lean Six Sigma’.

Lean is an offshoot of the Toyota Production System, created by Taiichi Ohno. He boiled it down to shortening the time between getting an order and getting cash by eliminating the seven common causes of waste in the process. This has been misinterpreted as cutting staff, as in “running a lean operation”. They’re not the same thing. The next time you see a CEO announcing that they are going to cut jobs as part of their Lean Six Sigma adoption, you can be pretty sure they have no clue what they are talking about.

I’ve seen other piss poor analogies of Lean applied to software as well. To give one example, some claim that rarely used features or commented out code are wastes of over-production. In manufacturing, when a new product is introduced, first it gets designed by an engineer. If it is a high-volume, low-mix environment, there’s typically a pre-production run to iron out the kinks. If it is a low-volume, high-mix environment, it often gets prototyped by one or more technicians, assembly workers, and engineers. If you have waste in a process, the prototyping stage is where you want to discover it – before production is ramped up – so it can be identified and eliminated. The problem with the software / Lean-waste analogy is that most code development is more like the prototyping stage than the manufacturing stage. You don’t write code once, then create the exact same code over and over again.

Six Sigma is a collection of tools for problem solving and quality improvement. Central to it’s theme is DMAIC – define, measure, analyze, improve, and control, and it relies heavily on statistical analysis. While it has been applied successfully to service based organizations where the procedures are very standardized, such as healthcare, it’s bit of a stretch to apply it to software development.