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.

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

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) -

1. Yes
2. No
3. 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:

1. List options early, and keep looking for new options
2. Determine what the true last possible time an option is still viable, and regularly assess if these change due to other decisions
3. 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.

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.

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 -

1. 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.
2. 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.
3. 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.
4. 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)
5. Calibrate the scorecard by testing on existing systems. Agree and alter the specific factor "Weightings" until you gain confidence in the scorecard
6. 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.

I started out in the electronics engineering field, and moved into the software side of electronics design automation business shortly after that. Back in the early 1990's a lot of effort was being put into Design for Manufacturing. This was in the recognition that very small decisions made early by an isolated engineer, could have massive consequences down the road impacting costs. There were a few leaders and advocates in the field, mainly from HP and IBM at the time.

One incident recalled by Happy Holder, a HP engineer at that time was the reduction in cost of the HP Laserjet III printers. By altering the size of the main printed circuit board size by a few inches one way, they were able to double the production yield of that assembly, halving the raw material cost of the PCB. Happy Holden and IBM's Tucker Garrison at the time came up with a few simple methods for evaluating designs and allocating a report card. The most complex part of the process was getting the right people in the room to agree on the right criteria to measure, and to weight those measurements in the right way.

Manufacturing optimization comes down to improving production yield (reducing waste) and speeding up the process (reducing touch time); These principles are well known to all those proponents of Lean Manufacturing and Theory of Constraints. This book is a good start - Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results (The Coad Series).

Is software yield (throughput) equivalent to DFM for Electronics "Speeding up the process"? The aforementioned books clearly describes the process of improving throughput by reducing the waste and understanding the current blocking issues. But I cannot find a process that brings focus of the cost of decisions back to the earliest possible decision point, when it is relatively simple to move many directions.

It seems obvious there is room for innovation here. Provide a framework (what DFM calls report cards) that developers and architects can use to assess possible solutions and designs for a requirement. I plan over the next few weeks to explain how the Electronics DFM process worked, and suggest a few techniques that might improve our up-front decision making process.

Troy.

Due to the amount of spam I was getting (300 odd comments a day) on Community Server - I've decided to move to a simpler blogging engine in the hope I can keep current with new versions, being .NET Blog Engine. Unfortunately, my version of Community Server was so old that I was unable to successfully export the previous posts. I'll move them manually, but it means that this won't happen overnight!

Anyway, bear with me. I promise to restore order as quickly as I can.

Troy.

The company I work hosts a decent size data center to support its business (a website hitting around 1.5Mil hits a day, and countless business applications to keep the company in business). Around the end of last year our backup-power (UPS') and air-conditioning were hitting the alarming 90% level (this is understated!).

The issue wasn't the number of production servers, but rather the pre-production servers for Development, Testing and Staging. Replicating the rather large interconnected complex environment took hundreds of servers, all at 5% CPU utilization most times during the month!

Our Savior: Server virtualization

Just by converting as many pre-production servers to virtual instances and hosting these on decent machines, we saw a reduction to below 45% capacity. The additional benefit is that many of these machines were hosted on poor, unstable hardware previously - virtualized, these are running on solid hardware and in many cases perform better than they did.

If every company house that has software development and testing server resources virtualized their pre-production environments imagine how much less power our server rooms would consume. That has got to be better for the financial operating cost and also better for the environment in general!

Troy.