LINQed IN

Zip - New LINQ to Objects .NET 4.0 Operator

troy.nospam@nospam.aspiring-technology.com (t_magennis) — Mon, 05 Jan 2009 05:56:43 -1300

When looking through the .NET 4.0 framework bits given out at the recent Microsoft PDC conference, I discovered a new operator - Zip

Zip combines the elements from two sequences, by making available the element at the same index position in each sequence. The sequence stops as soon as one of the sequences exhausts its elements; ideally, the sequences are identical in length. The merging happens in the func function. It takes two arguments (the element from foe first source, and the element from the second source) and lets you return a combined type.

The extension method signature is:

public static IEnumerable<TResult> Zip<TFirst, TSecond, TResult>(
  this IEnumerable<TFirst> first, 
  IEnumerable<TSecond> second, 
  Func<TFirst, TSecond, TResult> func);

Sample usage:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace ZipTest
{
    class Program
    {
        static void Main(string[] args)
        {
            string[] s1 = new string[] { "a", "b", "c" };
            int[] s2 = new int[] { 1, 2, 3 };

            var q = s1.Zip(s2, (a, b) => a + b);

            foreach (var e in q)
                Console.WriteLine(e);

            /* Output:
             * a1
             * b2
             * c3
             * 
             */
        }
    }
}

Troy.

Google Chrome: about:stats Diagnostic Page/Easter Egg

troy.nospam@nospam.aspiring-technology.com (t_magennis) — Tue, 02 Sep 2008 10:53:50 -1300

If you are trying out Google Chrome, type about:stats into the address bar and hit enter. You get:

In a previous post I wrote how adding features to a product to assist in debugging issues pays dividends; its great to see others also using this technique. This page/feature is obviously for determining and optimizing memory issues and performance stats. I wonder how many other "address-lets" like this there are built in?

Troy.

Google Chrome - First Thoughts

troy.nospam@nospam.aspiring-technology.com (t_magennis) — Tue, 02 Sep 2008 07:52:00 -1300

Google announced and released their Chrome browser today.

This post is from Chrome, and it does seem to work on most sites i've looked at - however, there are many rendering issues that aren't issues in Firefox or IE. Some examples can be seen on my LINQ Wiki site (Hooked on LINQ) where the spacing between adjacent span's seems squashed, and the order of table cells seems to be incorrect (OK, different) than the current popular browsers. It is a beta after all, but google have said the rendering engine is closest to Apple's API, and I must admit, my sites are less tested on Safari (in fact, not really at all).

This brings up an interesting Product Management challenge. If peoples first impression is that sites they frequent are "broken" in Chrome - will users persist with that product. Gmail is still in "Beta" which is a bit farsicle given its time in the market, so understanding what Google actually means by "Beta" is difficult to judge - But - Chrome is definately BETA!

What works

- I like the "common pages" layout of a New Tab. Rather than just a blank tab, you get previews of common sites you frequent

- I like the developer javascript and page analysis built-in features (think Developer Toolbar)

What Doesn't Work

- Rendering issues on many sites that I find work in Firefox and IE

- I'm sure this wasn't a high-priority item for Google, but I struggled to get a Silverlight app to run. I went to Hardrock Cafe, and it almost ran (showed images, but couldn't zoom, pan, etc). I think Silverlight was installed OK (no mention of anything being downloaded), but in general - no luck here.

I'm most interested to see how Google will leverage this browser as a runtime for applications. They spend some time saying how they want applications running in Chrome to be more "Desktop Like" - my point would be, why not make them Desktop Apps! Solve the deployment problem, and write well coded Smart Client interfaces.

Troy.

Building in support features to applications

troy.nospam@nospam.aspiring-technology.com (t_magennis) — Tue, 02 Sep 2008 07:40:00 -1300

Some business rules are complex to capture, and codify into an application. Some examples are when there is company policy that is interpreted (hopefully minimally) slightly differently by different parties, or requires complex analysis when the new system "gets it wrong!".

One example I came across was the logic surrounding whether or not a banking loan application falls within an automated decision process or whether it has to be manually assessed. We took three releases to satisfy all the different business stakeholders. Our issue wasn't so much the actual rule coding, but the actual individual circumstance that swayed the rules engine one way or the other given individual interpretation. Our output of true or false didn't give us any understanding (or the end-user) as to why a certain decision was made.

In the second release, I added a right-click menu item to the "Calculate…" button. This menu allows the user (normally under the direction of the help-desk) to perform the calculation AND populate the Windows Clipboard with a small text based diagnostic report detailing the following aspects –

1.   The data it is ACTUALLY using for the decision – in many cases we were incorrectly gathering this data, making our result difficult to predict
2.   A step-by-step progress – Step 1 (Parties over 18 years old) : PASSED, Step 2 … etc…
3.   The date, time and user logged-in
4.   The version numbers of all assemblies and rules loaded

The end-user would then email this to our team as part of an "In My Opinion – You Got it Wrong" bug report. These reports allowed our Business Analysts to quickly isolate an issue, or more commonly a mis-understanding by the end-user as to actual bank policy! We quickly took a major unstable area and by the next version reports were almost zero (at least a 95% decrease in one release).

The key takeaways for me were –

1.   When a feature has many stakeholders, or the feature might be complex to remotely diagnose – consider adding some features to support the help-desk gathering the information you need to improve that feature over time
2.   Building diagnostic reports into the Clipboard was a very low impact way of getting data from end-users, and was easy for the helpdesk to explain
3.   Make the features obscure (although easy for the help-desk staff to tutor end-users). You don't want these features negatively impacting the user experience for normal cases
4.   Consider privacy issues. Only expose underlying data that you actually need. No personally identifiable medical results :-)

Troy.

Google Chart API

troy.nospam@nospam.aspiring-technology.com (t_magennis) — Mon, 04 Aug 2008 15:18:00 -1300

Old news to many, but Google has a Charting API that allows the creation of numerous chart types via a formatted URL string. The Google Chart API returns a .PNG file which is easily embedded in an image tag. If you want to embed charts into your web applications, this chart API might help get you to market quicker.

The idea is simple enough - create an API which returns an image given a specially formed URL. Values can be specified in-line, or encoded to make them more manageable. There are too many chart types and options to document here, but Google's documentation for this API is pretty extensive. I'm impressed with the approach and simplicity. I'm also impressed with the breadth of chart types and the number of options available. In general - they just look plain cool!

Although the API is pretty easy to drive natively, there is also a .NET Helper Library called ngchart which simplifies the API's from native .NET code.

Enough talk - some examples -

http://chart.apis.google.com/chart?cht=p3&chd=s:Uf9a&chs=250x100&chl=January|February|March|April

http://chart.apis.google.com/chart?cht=v&chs=200x100&chd=t:100,80,60,30,30,30,10

http://chart.apis.google.com/chart?chs=225x125&cht=gom&chd=t:70&chl=Hello

http://chart.apis.google.com/chart?cht=lxy&chs=200x125&chd=t:0,30,60,70,90,95,100|20,30,40,50,60,70,80|10,30,40,45,52|100,90,40,20,10|-1|5,33,50,55,7&chco=3072F3,ff0000,00aaaa&chls=2,4,1&chm=s,FF0000,0,-1,5|s,0000ff,1,-1,5|s,00aa00,2,-1,5

http://chart.apis.google.com/chart?chco=f5f5f5,edf0d4,6c9642,365e24,13390a&chd=s:fSGBDQBQBBAGABCBDAKLCDGFCLBBEBBEPASDKJBDD9BHHEAACAC&chf=bg,s,eaf7fe&chtm=usa&chld=NYPATNWVNVNJNHVAHIVTNMNCNDNELASDDCDEFLWAKSWIORKYMEOHIAIDCTWYUTINILAKTXCOMDMAALMOMNCAOKMIGAAZMTMSSCRIAR&chs=440x220&cht=t

DfM for Software (Part 3) - Building and Measuring the List of Factors

troy.nospam@nospam.aspiring-technology.com (t_magennis) — Tue, 22 Jul 2008 13:05:00 -1300

In the previous articles on dFM, we covered the basic concepts and how to determine the basic factors. This posting explains a simple process for building a matrix from these factors that will allow you to "cost" a scenario. A "scenario" is an option for building and architecting a software application. We then score this scenario using a score-card (described here), to compare the various scenarios.

This is a common weighted scoring system for decision support. Its not a perfect system; the subjective weighting are controlled to a degree by a democratic voting system, but a single factor could still play an unfair pivotal role in a final score for a potential scenario. This technique is shown to spark some ideas, not as a prescriptive technique.

Step 1 - Brainstorm a set of factors that influence - cost, time, performance, security, and reliability.

Step 2 - Group similar factors under a topic heading

Many of the brainstormed factors can and should be measured by one metric. An example might be the number of web servers, and the number of database servers. This can be joined under the single topic heading "Number of Servers Required"

Step 3 - Build the "Scoring Matrix" for each group.

The complexity in this step takes an absolute measurement and maps it to a simple 1 to 5 score. All measures should be 1 being lowest "cost, effort, time, best performance, most secure, most reliable" and 5 being the opposite direction.

(These are just very simple samples. The list and scores are completely fabricated in this picture)

Step 4 - Determine the factor weightings (what is more important than what)

I have three basic approaches for this -

a) You just decide relative importance and allocate weightings subjectively! Great if you can get away with it, but the intention of Design for Manufacturing is to find the "best" design from a balanced set of design objectives. If we just designed software for ease of development, we may not fully consider the operational aspects and the cost of ownership over time.

b) Paired Options (or Pairwise comparison): Get the group of people representing different domains of expertise (operations, development, business, marketing, sales) together again and have them vote A versus B, A versus C, etc. to determine what is more "important" to that person. Take an average measure of the room (more think A is more important than B). Total up the number of votes for each factor, and determine what percentage that total is of the entire selection. % weight = (count / total pairs (15) ) * 100

c) * my preferred* Stack ranking: Get each representative from each domain specialist (operations, developers, business, storage, etc) to stack rank the factors, most important to least important. This will uncover and account for individual biases. It is my preferred method because it also allows people to say "No Impact" for a specific factor on a "perspective" of the factor. Total up the relative ascending score (assign 1 to the lowest row that was a factor, and 2 to the next one up, and so on) and determine what percentage that score is of the total points available. This will look something like this -

Consider doing this for more than one perspective. E.g. As far as Cost, how would you rank importance. As far as time to market, how would you order these factors. What you are looking for is a way to mathematically represent that one factor has a much higher impact on a desired delivery "factor". Some axis of ranking might be:

1. Capital expenditure - Upfront cost

2. Operational Expenditure - Ongoing costs

3. Time to market - How quickly can it initially be developed

4. Performance - hitting agreed service and performance levels

5. Security - what factors make a system more secure

6. Reliability and Stability - what factors make a system able to handle failure more gracefully)

Whatever method you employ, the outcome needs to be a table of the factors, and a weighting multiplier, E.g.

Number of Servers Required - 24%

Bandwidth - 20.6%

Searches / sec - 10.3%

Number of Deployment Items - 17.2%

Number of Third Party Components - 13.7%

Number of Features - 13.7%

Step 5 - Score a Scenario and Multiply By Weights

Break out excel. Use the scoring sheet from Step 3 to score a scenario. Multiply each score by the weights determined in Step 4. Total all of the weighted scores. Do this for other scenarios to compare.

In the next installment of this article series, i'll demonstrate this basic technique with some real examples and prepare a final spreadsheet template you might find useful in doing your own option analysis.

Troy.

ExecuteQuery Tooltip - The worlds longest?

troy.nospam@nospam.aspiring-technology.com (t_magennis) — Tue, 15 Jul 2008 10:46:09 -1300

I had a need to execute a SQL statement using LINQ to SQL. Its a long story, but I couldn't use the LINQ to SQL Designer because I was calling a SQL Server 2005 System View. So, I just decided to use the DataContext.ExecuteQuery method. It was a welcome surprise when the intellisense tooltip filled the screen for the first parameter "elementType" -

Actually, the tooltip really helped. It explains the rules and priority of how the return resultset is mapped to the type you specify. To paraphrase, even though my type doesn't have LINQ to SQL attributes on each property, the system will still attempt to match properties to result columns using a variety of methods.

If a field or property is matched to a specific column name, that column is expected in the result set
If the field or property is not matched, a column is expected with the same name in the result set (first Case Sensitive search, then case in-sensitive search)

It goes onto specify the rules about change tracking, primary keys, etc.

A lot to read, but definitely saved me a having to hunt around for the necessary information. Nice work to whoever spent the extra time going to this detail; it shows they really thought about what someone would need when they used this method for the first time.

It could have been "elementType: The element type." if i'd been writing it :-)

Troy.

Visualizing Code Change Impact and Database Dependencies

troy.nospam@nospam.aspiring-technology.com (t_magennis) — Tue, 15 Jul 2008 10:30:34 -1300

Its often difficult on large projects to keep track of all the additions as a system grows. When a project grows, it gets more difficult to keep all system drawings accurate and correct. If a drawing isn't automatically generated, then you can have little faith that it is absolutely up-to-date.

The alternative is to write tools that examine the code and draw representations of the systems continuously. This can be part of a nightly build, or a tool that can be run on-demand in order to make better decisions, resolve design issues early, and identify impact of changes.

In this instance I was having trouble keeping up with what Web Services we had; What Stored Procedures they relied upon, and what SQL Server tables those Stored Procedures depended upon.

The application we wrote in a couple of days simply hunts through all *.cs files and uses Regular Expressions to find applicable code. It then uses Microsoft Research's Graph Drawing Tool "GLEE" to visually represent it. GLEE is incredibly easy to use and integrate. The following screen-shot (with the sensitive names removed) took less than 15 lines of code to produce (and a few hundred to do the Regular Expression hunting).

A side-benefit of this tool is that it forces the team to conform to the coding standards. If they want their new code to be incorporated into the latest drawings, follow the patterns provided.

Its great to come into work each morning and see what has been added, and to ensure that the cross-coupling even at the database level isn't going to cause use duress later in the project. We can quickly see what a DB schema change will impact. Sleeping much better now....

Troy.

Determining SQL Server Object Dependencies for a Stored Procedure or Other Database Object Name

troy.nospam@nospam.aspiring-technology.com (t_magennis) — Tue, 15 Jul 2008 05:34:49 -1300

Finding what dependencies a Stored Procedure has on underlying tables, views, functions, etc is often necessary when trying to assess the impact of a change. SQL Server has built-in functions that will indicate in most cases a dependency for any object in the database. The system view "sys.sql_dependencies" is viewed with skepticism by some people who have obviously been bitten in the past.

In order to see for myself the results, I wrote a simple helper class, and thought i'd share the boilerplate code to start you off here (I may clean it up and share it as a library, email me if you have difficulty getting it running). Its a rough prototype, but it is returning good results for my purposes.

Note: This code requires Visual Studio 2008. It uses LINQ to SQL in a very loose way due to the LINQ to SQL Designer not listing the System Views and Functions. Its a good example of just how flexible LINQ to SQL is though.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Data.Linq;
using System.Configuration;

namespace DatabaseDependencyCrawler
{
    public class SysDependsResult
    {
        public int referenced_major_id { get; set; }
    }

    public class ObjectInfoResult
    {
        public int id { get; set; }
        public string name { get; set; }
        public string xtype  { get; set; }
        public DateTime crdate { get; set; }
    }

    public class DatabaseDependencyCrawler
    {
        public List<DatabaseDependencyEntity> GetDBObjectDependencies(string connectionString, string name)
        {
            // the system views built-into SQL Server 2005
            string dependsQuery = "select referenced_major_id from sys.sql_dependencies where object_id = object_id('{0}')";
            string objectInfoQuery = "select * from sys.sysobjects where id in ( {0} )";

            List<DatabaseDependencyEntity> result = new List<DatabaseDependencyEntity>();

            // find the list of dependencies based upon a database object's name
            DataContext context = new DataContext(connectionString);

            var dependencies = (IEnumerable<dependencies>)context.ExecuteQuery(
                typeof(SysDependsResult),
                string.Format(dependsQuery, name), 
                new object[] { });

            // build a list of object_is's to we can ask for their name in a second query
            StringBuilder ids = new StringBuilder();
            foreach (SysDependsResult d in dependencies)
            {
                if (ids.Length > 0)
                     ids.Append(",");

                ids.Append(d.referenced_major_id);
            }

            // if any records were found...lookup the names of those id's comma separated
            if (ids.Length > 0)
            {

                IEnumerable<ObjectInfoResult> objects = (IEnumerable<ObjectInfoResult>)context.ExecuteQuery(typeof(ObjectInfoResult),
                    string.Format(objectInfoQuery, ids.ToString()),
                    new object[] { });

                foreach (ObjectInfoResult o in objects)
                {
                    result.Add (
                        new DatabaseDependencyEntity {
                            DatabaseConnectionString = connectionString,
                            SourceObject = name,
                            Dependent = o
                        });
                }
            }
        
            return result;
        }
    }
}

Microsoft SharedView

troy.nospam@nospam.aspiring-technology.com (t_magennis) — Wed, 02 Jul 2008 10:25:05 -1300

Old news to many, but I had a need to share my desktop today for a conference call. I remembered Microsoft had ShareView coming out of beta, so I downloaded it and was up and running in a few minutes. Its well worth your time having installed. For demo'ing a website prototype to external people, it worked great.

Microsoft ShareView download

Microsoft ShareView Connect Page

Overview

Hold more effective meetings and conference calls
Connect with up to 15 people in different locations and get your point across by showing them what's on your screen.
Work together in real time
Share, review, and update documents with multiple people in real time.
Use when and where you want
SharedView is easy to use, from anywhere, at a moment's notice.

I can see this coming in useful for all sorts of ad-hoc collaboration. I'd like to know how it goes as a remote pair-programming platform as well.

Troy.

Project "Velocity" A Distributed In-Memory Application Cache

troy.nospam@nospam.aspiring-technology.com (t_magennis) — Mon, 30 Jun 2008 06:41:33 -1300

I dropped by the ADO.Nets team stands at TechEd 2008 and saw a demo of a new project called "Velocity". It is a distributed caching technology, that allows in-memory caching across a distributed set of machines that is resilient and fast.

Although not on schedule for RTM release until 2009, this technology hold promise for scenarios like distributing reference data, and session state across multiple machines in a server farm.

Anil Nori and Muralidhar Krishnaprasad presented a session on the topic and posted their TechEd slides here. Here is the "What Is slide" -

More resources -

The Velocity team blog

Velocity Project Page

CTP 1 Download

Troy.

Programming Quotes and Wisdom

troy.nospam@nospam.aspiring-technology.com (t_magennis) — Thu, 26 Jun 2008 05:17:00 -1300

I found a good set of programming, and software development quotes. Here is a short-list of my favorites I found at this site. If you know of any other good programming quote websites, leave a comment.

"The Six Phases of a Project:

Enthusiasm
Disillusionment
Panic
Search for the Guilty
Punishment of the Innocent
Praise for non-participants"

Anon

"Theory is when you know something, but it doesn't work. Practice is when something works, but you don't know why - Programmers combine theory and practice: Nothing works and they don't know why."

Anon

"Good judgement comes from experience, and experience comes from bad judgement."

Fred Brooks

"The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time."

Tom Cargill

"Learning is not compulsory. Neither is survival."

W. Edwards Deming

"Two things are infinite: the universe and human stupidity; and I'm not sure about the universe. "

Albert Einstein

"Measuring programming progress by lines of code is like measuring aircraft building progress by weight. "

Bill Gates

"The perfect project plan is possible if one first documents a list of all the unknowns. "

Bill Langley

"There are two ways to write error-free programs; only the third works. "

Alan J. Perlis

"Without requirements or design, programming is the art of adding bugs to an empty text file."

Louis Srygley

"I have always wished that my computer would be as easy to use as my telephone. My wish has come true. I no longer know how to use my telephone."

Bjarne Stroustrup

"There are only two industries that refer to their customers as "users". "

Edward Tufte

"We all agree on the necessity of compromise. We just can't agree on when it's necessary to compromise. "

Larry Wall

"As soon as we started programming, we found to our surprise that it wasn't as easy to get programs right as we had thought. Debugging had to be discovered. I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs."

Maurice Wilkes discovers debugging, 1949

Real Options Underlie Agile Practices

troy.nospam@nospam.aspiring-technology.com (t_magennis) — Tue, 24 Jun 2008 04:00:00 -1300

I've just been reading a well thought out article on Option Theory applied to software - "Real Options" Underlie Agile Practices, posted by Chris Matts and Olav Maassen.

I like the concept, and its common sense approach resonates well with my beliefs. I'll try and summarize, but you should read their article for the full story.

There are three possible decisions when faced with an option (in our case, an approach, an architectural choice, an implementation choice, etc) -

Yes
No
No Decision Yet

The 3rd choice is often overlooked and a decision is made earlier than it needs to be, curtailing any chance that you will learn more information and make a superior choice later on. The authors explain that when listing options, it is important to define when the true "must have a decision point is" for each option, and passing one of those "drop dead" points is actually making a decision "No" for an option.

The key points for me from this article were:

List options early, and keep looking for new options
Determine what the true last possible time an option is still viable, and regularly assess if these change due to other decisions
Make a solid "Yes" decision for an option at the last possible moment - this leaves open the opportunity for newer options to emerge

I came across this article by looking up the speakers at a local upcoming conference in Seattle. The authors are speaking at the APLN Agile Leadership Summit in Seattle (July 17-18).

Troy.

DfM for Software (Part 2) - Determining Factors

troy.nospam@nospam.aspiring-technology.com (t_magennis) — Mon, 23 Jun 2008 10:13:00 -1300

What are factors?

Factors represent an issue, or a requirement that has an impact on the final "cost" of a product. In electronics, a "cost" will either be an increase in monetary value of building an item, or an increase in time to delivery. "Costs" in the software domain might be -

Cost of hardware or hosting monthly fee(s)
Increase in time to develop or deploy
Compensating technology required for security, or risk mitigation

This isn't a complete list, but its a good start. Our ultimate goal is to define a set of "Weighted Factors" that we will use to score a particular design option. But first, lets explore the different types of Design Options, and explore a few examples in the Software engineering domain.

Key Point: Each factor varies in how linearly it will effect the "cost" value. Higher costs are bad, lower costs are good. Costs will be normalized by the weighting scale applied to each factor to ensure one factor doesn't overly control the outcome.

Types of Factors

Binary Decision Factors

Binary factors are those constraints that are an absolute Go or No-Go. Any factor that will clearly eliminate an option should be the first criteria analyzed. If a certain criteria is met (or not met), the highest cost should be assumed - ensuring that this option can never be chosen (not without due negotiation anyway!)

Tipping Point Factors

Some factors have no "cost" impact until they pass a certain threshold. An example might be disk space use. Until your product passes the requirement to need more than 100MB of disk space, there is no cost; After that you pay a premium. These factors need to place the lowest cost on a factor, once the tipping point is reached, the factor must assume the highest cost ensuring this option cannot be chosen, otherwise this factor should be zero and not impact the rest of the decision tree.

Scaled Factors

These are general quantifiable factors. The offer a mechanism to determine (and indicate) how a factor impacts cost. E.g. Adding an extra business service layer will increase the deployment complexity and may need extra servers. We'll discuss how to formulate a scale for these factors in a future article, but in this example you can imagine that adding servers has a cost, and each extra architectural layer increases the cost accordingly.

Determining the Relevant Factors

This is the crux of the story. We need to identify the factors that we will score. There is no master list of factors to draw upon. It is important that each factor fall into a category listed above - Binary, Tipping Point or Scaled.

The basic process is to get all the stakeholders into a room and extract (brainstorm) factors that will in their opinion cause an extra cost. No factor is too small at this stage (we'll filter them later), just keep the crowd focused on identifying issues that can increase/decrease effort, cost, time and risk.

By then end of a session you should have a stack of post-it notes littering a whiteboard. Use post-it notes so that you can join and link duplicate concepts and ideas. If you involve the right people, you should end up with a big list of factors. How many are too many? Impossible to quantify, but once a list of Factors is defined, the weighting process should spotlight those factors that fall below a level that will alter any outcome. These factors can then be dropped.

I've not got a complete list, or even a recommended list at the moment. Hopefully sometime in the future I'll have something more, but for the fact of this article, here are a few I jotted down in three minutes (some overlap, some are duplicate, some can't be measured, and some don't make sense at all - all problems to look at later)-

Bandwidth utilization
Disk space required
Number of Architectural Layers
Database size
Number of Database Objects
Number of different development languages
Number of different technologies
Number of integration points
Number of external partners integration points
Number of config settings, and ease of changing
Production event logging, how much, to where, how often?
Ease of deployment
Number of Servers
Number of third party components
Ease we could host at a co-located facility

In future articles, we'll look at how to take this list and refine it down to a manageable set, and how we would scale and weight each factor.

Troy.

DfM for Software (Part 1) - Design for Manufacturing 101

troy.nospam@nospam.aspiring-technology.com (t_magennis) — Mon, 23 Jun 2008 08:18:00 -1300

In electronics design, many elements can directly impact the cost of manufacturing a product. DfM aimed to move the tradeoff analysis for decisions affecting manufacturing as early as possible in a design phase. I'll attempt to move this into the software architecture realm in a future article, but for now I want to explain how this worked in Electronic Product design.

What design decision matter in Electronics?

In electronic product design, here are a few to start your thought process -

Component Selection - Choosing components from an approved supplier and components that meet requirements but don't exceed specification (giving latitude to safety margins) directly impact cost of an item. Assisting engineers choose preferred part, parts already purchased and in inventory, and offering alternatives can really decrease costs and improve turnaround time.

Printed Circuit Board Size and Shape - Small PCB's aren't made one at a time. They are panelized onto larger sheets, fabricated and even assembled (components positioned and soldered into place) in that form before being broken apart and put into their cases. The more individual boards you can fit to a panel, the less waste and fewer panels need to be moved through auto-assembly equipment.

Printed Circuit Board Technology - If you make the board smaller to fit a certain device, you often need to add 'layers' for interconnecting components. This adds cost; If you make individual features smaller to fit more interconnects onto fewer layers, the manufacturing yield decreases due to mis-registrations. Its a real trade-off and highly dependent on your partners capabilities.

Printed Circuit Board Hole Count and Sizes - For some PCB technologies, drilling holes can be time consuming. Smaller holes needs to be positioned more accurately and these drill bits break more often. Normally, fewer holes of larger sizes is the cheapest way to go; However, some PCB technologies don't incur a cost per hole - which one will you specify?

Component Placement - Where is it safe to put large components? Where will the battery connect? Where are the pushbuttons? All of these decisions need to be considered when the PCB is being designed - BUT they seriously impact the final case design. How can the electronics designers and the mechanical (and brand) designers collaborate to agree on an acceptable design? For extremely high volume designs, placing similar components in the same orientation can reduce the number of machine rotations and component reel changes which reduces the total time of assembly. Saving 1 minute for 1 million pieces is substantial!

Early Focus and Scoring Matrix Definition

Design for Manufacture initiatives aimed to bring focus on the types of decisions made above and allow engineers and designers to perform trade-off analysis as early as possible in the process. The product might have to be smaller than a competitors and that forces a smaller PCB size and shape, which then causes a specific choice of technology - However, the key aim was to understand that early and make informed choices about which remaining options fulfill the global good.

To build a Report Card or Scoring Matrix, the basic process is -

Get together with all of your partners, suppliers, fabricators and designers and brainstorm a set of issues that impact cost. Similar to the list provided above, the idea is to get the 'issues list' on the table.
Group these issues into a sub-set that can actually be measured and scored. E.g. "Number of boards per panel", "Number of holes smaller than 0.5mm", "Number of different components types", etc.
Determine relative weighting for each measurement. Some requirements cannot be broken, other just incur a cost. I'll propose a process for determining this weighting in a future article; for now, just understand they won't all have the same weighting factor.
Build the scoring scale for each factor. This step tries to normalize the different scales of measurements into a smaller linear set (i.e. 1 to 5, rather than 1 to 1 million for one factor, and 1 to 10 for another)
Calibrate the scorecard by testing on existing systems. Agree and alter the specific factor "Weightings" until you gain confidence in the scorecard
Use the scorecard on future design discussions.

Summary

Is it just as simple as substituting "IT Operations" for "Fabricators"; "Usability/Interactive Designers" for "Packaging Designers"; "External Hosting Partners" for "Suppliers"?

In future articles i'll look deeper into -

How to build a weighted score card based on issues relevant to software
Propose some software specific issues and attempt to weight those appropriately
Test our new scorecard and determine if it is achieving the goal we intended.

Be interested in comments as to whether other people agree there might by parity between DfM in Electronics to DfM in Software.

Troy.