I got word through twitter a few days ago that Telerik is making available to MSDN subscribrers their WPF controls for FREE!  Go and get them!  I consider Telerik controls the easiest to use and this is just great to get a perpetual license.

The word I got said this is limited until the end of July, and that you have an MSDN account.  When downloading I did not see a need to enter MSDN subscriber information (which I am a member), so try getting them while you can.

I heard Scott Ambler talking about the "Generalizing Specialist" on DNR 460.  He was stressing that this is the best type of person to have on your project team as they are more effective in practice, and I agree with him.

So what is a GS?  It is a person that is deep in one or more specialties (such as programming skills, DB skills, management skills, ...), but also has knowledge of other specialties, and is willing to learn more about the areas of which they are not specialists.

The challenges with specialists are several fold:

1. Do their jobs no matter what needs to be done.  For example a data modeler may just do data modeling, even if you don't need it.
2. They have problems interacting with other specialists.
3. Specialists hand off work to other specialists when they are done their work, leading to critical path and sequential project tasks (instead of in parallel)
4. The project is only as good as the weakest point in the chain of experts
   
5. A lot of extra work gets done all of which may not be needed

On the flip side of this is the generalist.  In this case, no one has the skills to get anything done.

The gist of this is that you want to:

1. Provide your expertise where needed
2. Learn where not a specialist in case you are needed at a later time
3. Provide different perspectives to other specialists to open their thought process
4. Be able to communicate so as to be able to complete work in parallel, and with higher quality.
   

.NET Rocks episode 460 had Scott Ambler talking about his APMM.  Here's the link to his blog entry on APMM, and I also repost some of that content here.

The Agile Process Maturity Model (APMM)

The goal of the Agile Process Maturity Model (APMM) is to provide a framework which provides context for the plethora of agile methodologies and practices out there today. The APMM defines three levels, each of which build upon each other, for agile processes and practices. At IBM we’ve found that many customers find the agile message confusing, in part because of the multitude of voices within the agile community but moreso because the agile rhetoric often seems to ignore or gloss over many important issues which our customers face on a daily basis. Hence the need for something like APMM to provide badly needed context for agile methods and practices


APMM Level 1: Core Agile Development
Level 1 agile processes address a portion of the system life cycle (SDLC). Examples of Level 1 agile processes include:

• Scrum. The focus of Scrum is project leadership and requirements management. Scrum proponents claim that it is a process framework, but if so then it is a sparse and incomplete one at best and very clearly every other process in existence could also make this marketing claim. A more accurate description is that it is a high-level lifecycle for construction iterations (what Scrum calls “sprints”) and several practices such as daily stand-up “Scrum” meeting, product owner, product backlog, iteration/sprint planning, and potentially shippable software.
  
• Extreme Programming (XP). XP is a collection of practices for software construction, include refactoring, test-first design, pair programming, on-site-customer, continuous integration, whole team, and collective ownership. XP is very close to being a APMM Level 2 process but it is unfortunately missing (currently at least) explicit practices for project initiation and release the system into production.
  
• Agile Modeling (AM). AM is a collection of practices for light-weight modeling and documentation, including requirements envisioning, executable specifications, active stakeholder participation, prioritized requirements, and prove it with code.
  
• Agile Data (AD). AD is a collection of practices for database development, including agile data modeling, database testing, database refactoring, and continuous database integration.
  

APMM Level 2: Disciplined Agile Delivery
Level 2 agile processes extend Level 1 to address the full system delivery life cycle (SDLC). As the
criteria for disciplined agile development suggests they also tend to “dial up” certain aspects of agile development, such as testing, measurement, and process improvement. Furthermore, they include explicit mechanisms to support effective (ideally lean) governance. Examples of Level 2 agile processes include:

• Hybrid Processes. A common strategy is for organizations to cobble together a Level 2 process on their own, often around the Scrum "process framework" and XP with ideas either brought in or reinvented from AM and sometimes AD. This strategy is perfectly fine in theory, although in practice a lot of project teams seem to spend a lot of time in trial-and-error experimentation to figure it out for themselves. They invariably have some "learning experiences" which could have been avoided if they'd only started with a Level 2 process to begin with.
  
• Rational Unified Process (RUP). RUP is a comprehensive process framework for iterative software delivery which can be instantiated anywhere from a very agile form to a very traditional form as your situation warrants. RUP practices include risk-value lifecycle, whole team, test-driven development (TDD), business process sketching, and continuous integration.
  
• Open Unified Process (OpenUP).
  OpenUP, the definition of which is available via open source, which combines and extends practices from Scrum, XP, AM and RUP for co-located agile teams which are building business applications. OpenUP practices include whole team, daily standup meeting, prioritized work items, risk-driven lifecycle, TDD, active stakeholder participation, and continuous integration.
  
• Harmony ESW. Harmony ESW is an agile software process for embedded software (ESW) systems.
  
• Dynamic System Development Method (DSDM). DSDM is an agile delivery process originally based on Rapid Application Development (RAD) which is often used to developer user interface intensive application. DSDM practices include prototyping, test throughout the lifecycle, reversible changes, and feasibility study.
  

APMM Level 3: Agility at Scale
In the early days of agile, the applications where agile development was applied were smaller in scope and relatively straightforward. Today, the picture has changed significantly and organizations want to apply agile development to a broader set of projects. Agile hence needs to adapt to deal with the many business, organization, and technical complexities today’s software development organizations are facing. This is what Level 3 of the APMM is all about – explicitly addressing the complexities which disciplined agile delivery teams face in the real world.

The scaling factors which an agile team may face to a lesser or greater extent includes team size, physical distribution, organizational distribution, regulatory compliance, cultural or organizational entrenchment, system complexity, and enterprise disciplines (such as enterprise architecture, strategic reuse, and portfolio management). Each factor has a range of complexities, and each team will have a different combination and therefore will need a process, team structure, and tooling environment tailored to meet their unique situation.

Unfortunately, the term “maturity” is a loaded one within the software process realm, not the least because of the Software Engineering Institute (SEI)’s Capability Maturity Model Integrated (CMMI). A lot of good work has been done to show that agile and CMMI can be applied together, and I look forward to seeing that strategy come to fruition. However, where the goal of the CMMI is to provide a framework for software process improvement the goal of the APMM is much more modest – it merely strives to define a framework which can be used to put the myriad agile processes into context. In short, the APMM and CMMI are orthogonal to one another, and in future blog postings I’ll discuss how CMMI and APMM fit together.

Over the past few days I have been reviewing references for user interface design and thought I'd drop them here for my (and your future reference)...

• User Interface Design: A Software Engineering Perspective

This is probably my favorite text at this time.  I really like it because of many things, but worth noting now is the process of prototyping and iterative design, and particularly using paper prototypes.  I think I'll come back with another post to just explain why I think that is important.

• About Face 3: The Essentials of Interaction Design

This is considered a classic.

• Paper Prototyping: The Fast and Easy Way to Define and Refine User Interfaces

A good follow up to Soren's "User Interface Design: ..."

• Designing Visual Interfaces: Communication Oriented Techniques

• Designing Interfaces: Patterns for Effective Interaction Design

• Designing Gestural Interfaces

• Designing Social Interfaces

Listening to Hanselminutes "The Art of Unit Testing with Roy Osherove" and there are a few definitions being discussed that I think are useful to know...

• Fake

Fakes are objects that look like something but are fake, and can be stubs or mocks depending upon the usage.

• Stub

Stubs help a test execute, and typically contain "fake" data, used to get a test to run.

• Mock

Mocks are asserted against to determine if a test has passed.  Basically it is a fake object used to make a test to execute.  Typically a mock also has behavior instead of just data.

More is discussed in Roy's book "The Art of Unit Testing", which I have, but have not read yet.

Last night I was porting some of my TweetZenn project over to VS2010 and came across this error in the build. It took quite a bit of googling to figure out what caused this as well as how to solve it, and many of the answers I found where also not related to the type of solution I was building (most seemed related to Azure development), so that made it a bit complicated also. But I have reduced this to a very simple scenario and solution, which I'll show here for everyone.

The problem can be reproduced very simply. Take this scenario:

1) Create a new Silverlight solution in 2010. Call it anything, but in this expositionI will call it OutputPathTest.
2) Add a C# windows library to the solution. I calle it "ALibrary" Now build the solution. Everything works fine.
3) Now add a reference to "ALibrary" in your web project and build (not that you didn't even need to add any classes to ALibrary). You now get the OutputPath error message:



4) Remove the reference to ALibrary and build, and it builds properly.

So, this problem seems to be related to the reference to ALibrary causing the problem. But how to solve this?

Well, it appears you need to manually edit the .csproj for ALibrary. Open the file in your favorite text editor; I'm using notepad2, and the following shows the culprits identified with red arrows:



The project is set to target x86 while the web solution is set to AnyCPU. To fix the problem, it is needed to change the mentions of x86 to AnyCPU. Do that, rebuild the solution, and everything will work perfectly.