The new Architecture Explorer enables individuals to create a visual representation of existing code assets.

From MSDN (with added commentary….)

Modeling that Works with Code

For most businesses only about 20% of the code being written today is for new applications;

(DDN: Not true 100% however that is about right for budgets which is likely what they meant anyway).

the majority of work is being done on existing code bases. A typical issue encountered when working on existing code is not having good tools to help the architect or developer understand the system.

(DDN: Uh.. How about no regression tests? How about no mandate for reuse, framework API quality, etc. etc.? Sure lets not talk about the why, just the ways we can profit from it)

This can make it challenging to not only understand what needs to be done to make the required changes, but it makes it equally challenging to understand the broader impact of the changes. Often it isn’t until much later that an unexpected bug is discovered as a result of a change.

Our modeling tools have tight integration into the actual code of the application. This means that a developer or architect can use models to explore existing code assets.

Ugh.. Rational Round Trip UML nightmare but this should be part of your world at a minimum from code to view.

The new Architecture Explorer in Visual Studio Team System gives developers and architects the capability of creating a full architectural picture of existing code; understanding how they fit together; understanding how they “work.” This leads to better information about how to use, re-use, or even whether or not to discard existing code. The Architecture Explorer provides architects and developers a mechanism for visualizing code assets in a number of ways including graphs, stacked diagrams and dependency matrices.

DDN: OK now I am officially getting scared… I can see all the developers saying ‘look ma! I’m an architect!’

The introduction of the Architecture Layer Diagram means that a developer or architect can use models to enforce constraints on code as well. The Architecture Layer Diagram can be coupled to code making it an active diagram that can be used for validation.

For example, when an architect designs a system where the presentation layer should not talk to the data layer, you want to be able to enforce that model at check-in.

DDN: Oh my god was that last sentence serious? As if that would be a real interesting case?

VSTS 2010 can do that. These capabilities delivered in VSTS 2010 are part of the Microsoft’s overall modeling story.

Learn more about modeling by watching the Trends in Software Modeling webcast featuring Jeffrey Hammond (Forrester Research), Cameron Skinner (Microsoft, Visual Studio Team System), and Clemens Reijnen (Sogeti).

Related Posts

This content assumes you have an introductory knowledge of C# 3.0 language features in .NET 3.5 and mastery of legacy C# 2.0 Generics, Generic Type Constraints, Anonymous Delegates and related material.

I use a ‘pair programming’ approach with continued refactoring as this is how I would discuss it if you were coding with me, with an unfortunate one-way delivery.

The Brief Strategic View

Microsoft has slowly been moving C# in a very productive direction (this is not new, as these features existed in 2.0 although not nearly as well integrated) to provide ‘Functional Language’ features. If you don’t know or care about language semantics, just know that Linq and especially Lambada Expressions are about empowering you to use executable code like a variable, aka to leverage the power of functional programming. For more on this, read this MSDN article by Joel Pobar (former CLR Team) or read the next set of posts (part 2 onward) as I will go into the depths of this.

Painless Intro

I’ll start with a fairly trivial, yet important example (I use it every day). Many times when comparing Strings I want to ignore case and culture (the InvariantCulture). This is provided by an overload as such as you likely know:

[Test,Category("BaselineCore")]
public void shouldAsserStringCloneInvokeEqual() {

var baselineString = “This is a TEST CASE to IgnOrE Casing”;

var stringUpper = baselineString.ToUpperInvariant();

Assert.IsTrue(baselineString.Equals(stringUpper,
StringComparison.InvariantCultureIgnoreCase));

The test results are shown above. Pass. Ok so I really like short, concise code that is understandable at a glance. Also it’s a pain to always (even with ReSharper) use this (and I have seen people use RegEx for this! RegEx is awesome but overkill for this issue).

Refactoring

• Create an extension method on String
• Decide on a good name for the method (this is SO important and for most an afterthought!)

I’ve settled on calling this new method on String ‘EqualsCore’ as that is what we are doing, making the conditions for a match ’simpler’ and seeing ‘just the core values’ are the same (anyway it makes sense to me)., I suppose this could be ‘EqualsRelaxed’ or whatever..

Here is the test case (no code yet):

[Test, Category("BaselineCore")]
public void shouldAsserStringsEqualUsingExtension() {
var baselineString = “This is a TEST CASE to IgnOrE Casing”;
Assert.IsTrue(baselineString. EqualsSimple(baselineString.ToUpperInvariant())); }

Now we write the code. Here is the container for the extension method:

public static class StringExtensions {

public static bool EqualsSimple(this string sTarget, string compare) {

return sTarget.Equals(compare, StringComparison.InvariantCultureIgnoreCase); }

}

Indeed they both pass:

Since every type inherits from Object, and Equals is defined on Object, all instances should support this approach, and I could be early bound by using Generics…. Hmm…

I tried this (note: I gave it a new new ‘EqualsThis’ to separate them.

public static bool EqualsThis<TTarget>(this TTarget sTarget, TTarget compare){

return sTarget.Equals(compare);

}

Functionally not that interesting at all, but a test. So I typed in the following and wow… It works from Intellisense’s view… Ok it compiled! Wait…..FAIL! But why:?

OK here is the new test:

[Test, Category("BaselineCore")]

public void shouldAsserANYTHINGEqualUsingExtension() {

const String baselineString =”This is a TEST CASE to IgnOrE Casing”;

var sb = new StringBuilder(baselineString);

Assert.IsTrue(sb.EqualsThis(new StringBuilder(sb.ToString())));

}

Interesting…

Here is the documentation for what Equals means by default from Microsoft:

So our code fails using the extension yet this returns true:

[Test] public void shouldAssertStringBuilderExplicit() {

const String baselineString = “This is a TEST CASE to IgnOrE Casing”;

var sb = new StringBuilder(baselineString);

var sb2 = new StringBuilder(baselineString); Assert.IsTrue(sb.Equals(sb2));

}

So Reflector to the rescue once again. I could see in Reflector what I believed the issue was. Indeed the StringBuilder class has an overloaded Equals, and even making the extension method cast to the generic type directly was a no go.

This exposes one of the dangers that we must be incredibly careful with. It has always been poor design in my opinion to encourage developers to override common methods such as ToString() and Equals(object X) with their own behaviors as you force consumers of the API to understand IMPLEMENTATION. You cannot ensure your OK simply from a contract. This is known to be evil….

Of course this is a legacy style and will be slowly phased out.

Spin up reflector and look at the code for the OVERLOAD that StringBuilder has:

 How do we get people to commit to something when everyone has a different perspective based on role or even political leanings for larger companies” “Our stakeholders are petrified to commit to a final stake in the ground for fear they will not be able to modify it based on I.T.’s inflexibility and inability to change”

I though perhaps these were problems we had overcome in our industry, as the solutions are fairly well understood. I was wrong. What is the bottom line break-down between I.T. and the Business? That is a long and colorful debate. However I offer this:

• 
  
  Most organizations punish those who are bad at PREDICTING THE FUTURE in software engineering. Of course these are smart people but they continue to demand clairvoyance with a lack of statistics.


• 
  
  What happens? Padding of the schedule and bitter fights for every last month, when nobody has any idea what the effort is, not can they quantify the quality, and more importantly maintainability requirements around a software initiative.


• 
  
  The fact is you cannot know at a micro level about a project until you are well into building it. This is something I have never met a receptive audience for, however it proves itself time and time again.


• 
  
  “How do we give people the freedom to change their minds, yet deliver concrete estimates on time and cost to our managers?”


• 
  
  “How much will this cost us and how can we estimate it knowing we will likely change our minds during the project based on previous projects, and how can we get early and consistent involvement in the development process?”


• 
  
  “How can we ensure that necessary quality is met when we always enter risk mode at the end and quality goes out the window? Can’t we manage with quality at every single stage, even every day?!”

Whatever you do (in my opinion anyway) Don’t say Agile…Nobody on the business side cares. In fact for whatever reason, software causes perfectly rational people to loose their mind (I cannot really blame them).

What I have to say on the matter is accompanied by deep battle-scars. What I have to say is definitely not what most want to hear, and even the technologists want to argue that they CAN come close to prediction. However what I say has the ‘added moral quality of being true’. This is hard to argue in light of the facts. That still often changes nothing, as companies firmly plant their head in the sand again and hope for the best with no real way of knowing what will happen and no practical way of really tracking in real time how their exposure to risk is changing.

I know… I know… Agile is 100% about that but not in the way (typically) this group wants to hear, no that is why a knockout one-two punch is as follows (to be insanely overly simplistic):

1) Heavy Statistical Metrics for the ‘Planning’ View Inclined

2) Of course, Agile Practices to Provide the Inputs to (1) and to Optimize your Chances on the Execution Side

This article is about some detail around (1) that far too many miss in my opinion and why it doesn’t serve you to mix the terminology of these two groups (one of the only occurrences where I recommend that as I am typically the one pushing everyone into ‘one common Domain Driven language’)

The Four Critical Dimensions

When addressing the concerns of a new custom software project these are the four key elements that must always be addressed (there are others such as security, scalability, etc. but those are included in ‘Scope’ as functional and non-functional requirements):

• 
  
  Time (cannot be made)


• 
  
  Scope/Features (you cannot know it until your done, so now what?


• 
  
  Quality (not typically discussed, as who wants ‘bad or sort of low’ quality)


• 
  
  Cost (Since you have almost nothing to go on here, what to do? Your agile consultant says the system is ‘done when it is done, not when some arbitrary date is set’ and he is 100% correct. However the business gets to decide when it is ‘done enough’ not I.T. (with exceptions of course)

As Quality is not usually debated (I have never had a client say that the software could be poor quality), that leaves Time, Scope and Cost as the main moving parts to work with.

The diagram above is where many stop. That is missing the entire point, as the DRIVERS that facilitate your ability to do well are missing. For example:

1) A lack of a continuous integration environment with regression tests will severely hurt your ability to achieve quality (all things being equal)

2) A bad process / culture kills just about all of it

3) Bad team morale is the same coin, different side.

4) A process that cannot manage the inevitable change in scope as we ‘discover’ what the project is all about, will kill just about all of it.

5) A team lacking in solid design skills (design for change) such as a mastery of the important design patterns (Strategy Pattern Anyone?) as well as a lack of a Dependency Injection Container (there is just no good reason not to use one)

6) Lack of an Object to Relational Mapping Abstraction Layer. Deal Breaker as of today (perhaps not a year ago).

There is no real doubt by anyone (except for a few people who also are not so sure on the whole evolution thing) that Agile practices provide the common sense way to address the same concerns most of us have around software.

You know it, I know it, we all know it. However they don’t care (and really have likely heard some bad things about it).

My assumption is you are a person on the software side in a managerial capacity of some sort. I made this mistake for you many times. Resist the urge to ‘set them straight’ or to explain the wonders of Agile when asked these questions (or even when not) and instead… I’ll be getting to that….

Anyway, they would probably just think ‘how 2004’ and ask about SOA or something….

There are some real deal-breaker assumptions around project planning with or without Agile execution (and without agile is very well might be an execution.. OK enough biased injection for one article).

There is often an unspoken (and unrecognized) characteristic that you should be able to ‘tell the future’. And many will think that the worse you are at it, the more likely it is you just might be lazy and/or stupid. I’ve seen it over and over and over. Those who spin, those who pad, those who create fluff to buy time win. Those who really try and don’t play games get nailed to the wall.

Count me in the ‘dumb and lazy’ group because I am terrible at predicting the future.

In high school I was certain this really cute cheerleader would accept my invitation to the prom. I was also certain a few years ago that a system could be built for W dollars, in X months with Y people and Z quality. After all, that is all I could get from the customer as they were taking no input from vendors. Sure it was aggressive but we were so smart! We could do anything!

Both had similar endings.

“In order to succeed in complex software planning, just like in Agile, you have to give up. You have to completely accept the fact that you cannot possible know what you are really doing until you are already well into a solution, at least not at any detailed level”

Sound familiar? But you know you need these Agile ideas on the ‘other side’ and you also know it would be self-defeating to wave that flag..

Nobody wants to admit they lack power, especially in areas they have devoted their life to mastering. But why does this not only empower you, but create the bedrock of extreme competence and success? Is this like the alcoholic finally admitting he is powerless over the bottle? Only then can things get better? I doubt it. This is only software.

·

The Monetary Stakeholders

And for they people either funding and/or profiting from this exercise the concerns can be quite different.

“How can we ensure profitability on our work when we know change will occur? (For internal IT they may be managed and accountable for profitability if they are run like a profit center). If not profitability then “How can we possibly commit to a date and cost when we know this will be a moving target as we evolve the solution?”

“We have an abysmal record of missed deadlines, cost over-runs, quality problems and our users not being happy with our delivered systems. What can we do to improve this?”

“How do we manage the scope changes and ‘feature creep’ placed on us by the business people/stakeholders? This is what typically destroys our profits and/or time commitments and cost commitments, often resulting is a severe quality issues as well. How can we give people what they want but manage this change?”

This article is about bring these two groups together and keeping them just apart enough. This article is targeted to the people who must deliver software to their clients (be it internal IT or an outside Agile consulting firm doing the work). I assume these concepts would work in a non-Agile Process environment but I have cannot remember much luck (or for anyone I knew) in those days without resorting to what I call ‘white tricks’ so I will not comment.

A Framework for Project Statistical Success Optimization

We know that these two very distinct groups will need to work closely together in an Agile environment if we want to optimize our chances. The days of separating the business experts from IT is long gone. In fact, for an Agile project to succeed it is typical to actually have a business domain expert on the development team as a fully fledged member.

‘High Ceremony’ software processes may work (it is really dependent on who is doing the work as an amazing team will almost always succeed – see Peopleware by DeMarco and Lister) but at a large opportunity cost in almost all cases.

Any assigned domain expert should have the reach to get answers to questions quickly outside their domain knowledge when required. For a non-trivial project it will likely cover many domains and it may not be possible for that individual to have a mastery of all of them, however this person should be able to expeditiously get answers from others when required, This is a critical success factor to any Agile project.

I have evolved over many years this approach to software profitability and risk management in a very well tested and disciplined way. It has evolved since 1998 when I was CTO of a niche financial services software firm, which was sold in 2004. I then started the firm agilefactor and significantly evolved these ideas further as I still do literally almost every day! It’s 2007 and there are many war wounds.

If any of this content seems like ‘academia’ or ‘theory’ I can assure you these are all proven real-world strategies, having been applied by myself and many others for years and years.

At the most basic, one could say everything eventually comes down these four critical dimensions…

It is CRITICAL you never let a client box you in on all of the three of these items if it can be avoided or you may have to ‘walk away’ from a project (many in internal IT do not have that luxury but at least this article will show you how to push back in a way that is hard to be disputed by the forces trying to box you in to possible assured failure).

Your client gets to drive only two of the three items at most (such as Time and Cost), while you driven the third (Scope in this example) or the remaining items you control (you must always have at least one that the client explicitly gives you control over).

This is critical to profitable software sales both for commercial and custom one-off development but many fail in this area in their eagerness to close deals (this is especially a problem with salespeople who are not put in check on what they can promise the client, and will promise you right into a massive loss – a lesson I learned firsthand early in my career).

For example, if a client says:

· We are allowing vendors to work until October 1st to achieve these 120 individual scope items in the attached 600 page scope document we have assembled (the first major sign of trouble).

· Vendors have $1,900,000 to build this system. This is non-negotiable and the software must be extreme production quality, with severe contractual penalties for down-time, with scaling up to 10000 concurrent sessions per machine with an average response time of one second or less “

Do we walk away? My initial reaction is absolutely..

This violates the principle described above as you are not in control of any of the four critical elements. The answer is sometime you must walk away!

I will describe here a way to help determine if you should and how you can effectively push back on this, as we know there will be significant deltas on that scope document (both academically from studies and practically from our experience).

We really have no idea if we should accept these terms. There are ways however where we can at least assess the risk and possible accept the terms when we learn these tools.

We all know it is an agile imperative deliver a working build to your stakeholders for each iteration that is ‘real production’ although a subset most of the time

The client drives at most two dimensions, and you must drive the third (again ignoring the Quality variable) or you risk a disaster for everyone.

And after all, THEY are deviating from ‘the plan’ they committed to with confident assurances that there would be little to no need for ‘change orders’ (this is a common occurrence in my experience with a correlation to the larger the company the most convinced they are the scope will not change.

Establish Risk Tolerance Before Defining the Time, Scope and Cost Constraints

Based on the extensive research and project database built by the industry luminaries and incredibly esteemed experts Tom DeMarco and Tim Lister, we now know what the probability distribution curve is for new custom software projects. It is lognormal with a high peak and a long curve to the right. This is absolutely critical for everyone to understand and I highly recommend you read the book “Waltzing with Bears” for a detailed discussion (see the end of this chapter for more information).

This is the probability distribution curve we must embrace:

You establish the client’s willingness to accept the unavoidable possibility of failure across any of the four dimensions (we cannot predict the future) and then find that point on the curve moving up from the X axis point you have for the client (the X axis is probability of success) and take the area to the left of that point.

The total area under the curve is 100% so the farthest right point would indicate 100% confidence (again basically impossible to achieve where most organizations assume 100% by default, something that must change if our industry will ever ‘grow up’. As we cannot control the future, we can only manage it and the risks, we must know how ‘risky’ the client wants to be (again by asking them or inferring it ourselves – often manifested in a ‘public’ date and an ‘internal’ date which is past the public date if we know the client will not cancel the project or penalize us tangibly for missing the public date).

It is a typical ‘risk/reward’ situation. If the customer takes on more risk we might save them money, or deliver early. If they want less risk, we must significantly increase our cumulative resources attached to a project with the knowledge that ‘adding people to a late project makes it later’. This we know as fact so adding people is really only an option in the early phases. This has a large impact on early project planning.

· We need to understand if a customer is OK assuming a 15% risk of failure for example.

· After all, don’t all future events have unknown outcomes?

· Is the client willing to as much as double their budget for a say 10% increase to 95% probability of future success across all dimensions?

A 95% success promise is not only near reckless to offer, it is an incredible shifting of risk anyone should demand a rich reward for taking on.

Studies are behind me on this as well with the well established fact that the best developers are as much as 28 x more productive then the worst). It quite literally is often a 100% increase in total resources allocated for a project to move from 85% to 95% even though it is a 10% gain in probability, hence the very long tail. The highest I have ever had a client go is 90% and we actually had two teams in two locations for redundancy (they didn’t know about each other). One team almost failed but delivered a solution, however the other team’s solution was superior so that is what we went with. This gave us our high probability due to the redundancy and the client paid dearly for this safety.

For example, the development team may say:

“We had a terrible two weeks. Our lead Cryptography expert was sick so we moved those features into the next iteration and we severely underestimated the complexity of the mainframe integration and User Profile Customization.

Therefore we could only achieve 50% of what we had planned for this iteration. I would say from our agreed upon 85% confidence we are now closer to 75%. We can see if we make it up in the next iteration or we can take measures A, B and C to get back to 85%. What do you want to do?”

A better question I have for you is, would you rather not know this? Almost all organizations are nowhere near this level of integrated risk assessment, quantitative measurement and adjusting action execution.

This is typically a decision for a high level individual (typically the project manager with the optional input of the customer) and hopefully with input from as many people as possible covering all dimensions.

Adding people will typically hurt you, not help you. You should already have done the obvious things like have moved the team into a ‘war room’ setting (almost always a sure way to improve productivity) or many other solutions, so if you missed any do it now as these techniques are proven and it is much more painful to fail.

As for the client, they can also be blissfully unaware of how we manage the process of our internal development, but this well established process makes it incredibly hard to fail.

Here is an example with risk tolerance. Based on negotiations with the client they have agreed to a risk tolerance of 85% (a 15% risk of failure). Based on this, you can now estimate knowing your margin for error. The customer has scope requirements, and cost requirements but is fairly open to time.

You come back to the client and say:

“Based on an 85% confidence we feel we can deliver your scope at the cost you describe at some point between April 1 2006 and July 1 2006’”. The client may protest, saying (for the first time) they were hoping for a March 1 delivery. You confer with your colleagues and respond that this would be possible at a 70% Confidence (30% chance of failure). And so the negotiations follow…But at least now you have very concrete ‘dials to turn’ and it is hard for the customer to argue with the fact base supporting you.

I assert that custom software is a ‘wicked problem’ (to see a great definition of ‘wicked problem’ see http://www.cognexus.org/id42.htm or the text at the end of this article.

Conclusion

To help ensure a positive outcome for your client and for your development effort it is critical to consider first the Risk Tolerance of your client, and then negotiate the one dimension you typically have control over after the client informs you of the two (two from Time, Scope and Cost). In some cases you must walk away and this article should help you determine when that is the case.

For a much more detailed discussion of these topics and what this author considers critical:

“Waltzing with Bears”, Dorset House Publishing Company, Incorporated (March, 2003), ISBN: 0932633609

Supplemental Material: Wicked Problems

A wicked problem is one for which each attempt to create a solution changes the understanding of the problem. Wicked problems cannot be solved in a traditional linear fashion, because the problem definition evolves as new possible solutions are considered and/or implemented. The term was originally coined by Horst Rittel.

Wicked problems always occur in a social context — the wickedness of the problem reflects the diversity among the stakeholders in the problem.

Most projects in organizations — and virtually all technology-related projects these days — are about wicked problems. Indeed, it is the social complexity of these problems, not their technical complexity, that overwhelms most current problem solving and project management approaches. (See graphic of wicked problem solving process below.)

Some specific aspects of problem wickedness include:

1. You don’t understand the problem until you have developed a solution. Indeed, there is no definitive statement of “The Problem.” The problem is ill-structured, an evolving set of interlocking issues and constraints.

2. Wicked problems have no stopping rule. Since there is no definitive “The Problem”, there is also no definitive “The Solution.” The problem solving process ends when you run out of resources.

3. Solutions to wicked problems are not right or wrong, simply “better,” “worse,” “good enough,” or “not good enough.”

4. Every wicked problem is essentially unique and novel. There are so many factors and conditions, all embedded in a dynamic social context, that no two wicked problems are alike, and the solutions to them will always be custom designed and fitted.

5. Every solution to a wicked problem is a “one-shot operation,” every attempt has consequences. As Rittel says, “One cannot build a freeway to see how it works.” This is the “Catch 22″ about wicked problems: you can’t learn about the problem without trying solutions, but every solution you try is expensive and has lasting unintended consequences which are likely to spawn new wicked problems.

6. Wicked problems have no given alternative solutions. There may be no solutions, or there may be a host of potential solutions that are devised, and another host that are never even thought of.

(from Rittel and Webber, 1973)

This is fantastic stuff coming from one of my all-time favorite companies, JetBrains. Here is a start:

Framework-usage pattern in MPS

Cyril Konopko, Konstantin Solomatov

Introduction

Language Oriented Programming or LOP is a software development approach which employs domain specific languages, or DSLs for short. A domain specific language, in contrast to general purpose languages, is a language which is designed to deal with one specific kind of tasks or with several related task kinds within a specific domain. For example, SQL is a DSL in a domain of database queries. LOP solves your main problem by dividing it into several subproblems in different domains, then each subproblem is solved using an appropriate DSL. In rather big projects, LOP can reduce singificantly the amount of work which has to be done.

In this article we will speak about JetBrains MPS, being developed by JetBrains, Inc., which is a so-called “language workbench”, i.e. a tool that helps you to use LOP in practice. You can read more about language workbenches on Martin Fowler’s site and about LOP in Sergey Dmitriev’s article.

A lot of people who heard about MPS don’t realize how it’s possible to take advantage of it. The current state of MPS is far from the point where you can throw away your Java or C# IDE and start writing everything in MPS with LOP, however it’s possible to use LOP and simplify some tasks significantly today. Actually, you probably use in your current project some kind of poor man’s LOP, techniques which make it possible to create small sublanguages in the program written on a language like Java, C#, or Ruby (Martin Fowler called such sublanguages Internal DSLs). This article explains the pattern that can employ MPS in its current state, describes prevalent poor man’s LOP tricks and presents several examples of it.

….

Seriously, check this out. Download the EAP, start using…..

Thanks,

Damon

This is known by many who have been doing VSX for a while, but I ran into it again recently and thought since many are no getting into this fresh, more sources are good.

“Unhandled Exception: System.IO.FileNotFoundException: Error while loading file ‘EnvDTE, Version=7.0.3300.0″

<configuration>

<runtime>

<assemblyBinding xmlns="urn:schemas-microsoft- com:asm.v1"

appliesTo="v2.0.50318">

<dependentAssembly>

<assemblyIdentity name="EnvDTE" publicKeyToken= "b03f5f7f11d50a3a"/>

<bindingRedirect oldVersion="7.0.3300.0" newVersion="8.0.0.0"/>

</dependentAssembly>

</assemblyBinding>

</runtime>

</configuration>

I will soon be posting a new article which (in my opinion) could be far more useful to everyone then this article ever was as it:

• Has far greater scope and use as Is a ‘domain collection’ engine and I believe the first solution to something I have been struggling with for years: The pain of building clean, quick web views in the world of Ajax, controls that expect datasets, and programmers not understanding ORM. It so far works with NHIbernate (and ActiveRecord) and I am finalizing Linq to Entity support
• Leverages advanced .NET intrinsic’s (CustomTypeDescriptors, etc…) that are leveraged by the third-part component community

• Support any ‘domain projection/entity set’ operation – the same engine backs both bindable sets and non-bindable sets.. You just pass the HQL into the user control in VS 2005/2008

Also stop by the new global repository I am bringing up with some others around ‘best practices’ for domain driven (obsessed) work. This has a .NET 3.5 focus (as we will deeply discuss linq I am planning) however it is an architects site, so we will cover mono, java, and likely 50% of the content will be platform agnostic.More to come!

Not to be a terrible bore, but brush up on your Wittgenstein lately?! Ok don’t go that far just yet…(grin).

 First, a Pattern Language (P.L.) is not some academic concept, although many would like you to believe that.

	‘Software as a Service – The Pattern Language Approach’
	‘Software as a Service – The Pattern Language Approach’
	‘Software as a Service – The Pattern Language Approach’

NOTE: I take issue with the word design below… It should be far more broad in most cases, but it often gets boxed into the design aspect of a problem. I would say ‘best practices’ which brings up its own semantic mess…

A pattern language is a structured method of describing [best] good design practices within a field of expertise. It is characterized by

1. Noticing and naming the common problems [and positively executed solutions proven over time] in a field of interest [domain in my words]
2. Describing the key characteristics of effective solutions for meeting [one or more] some stated goal[s], [Often patterns are combined and are multi-faceted]
3. Helping the designer [domain stakeholder] move from problem to problem [and challenge to challenge] in a logical way, [in an attempt to reduce and even eliminate ambiguity] and allowing for many different paths through the design process.

- Wikipedia 

1. This ties in perfectly with my claim that complex software engineering is a ‘wicked problem’. If you disagree then you can stop reading, as none of my assumptions will work. However, I would love to hear your arguments since only around 20-30% of all software projects ’succeed’…. There is no doubt there is dreadful crisis which I know you know about so enough said.

If the fundamental issue here is NOT that people cannot/will not see software engineering for what it is, then what?!

Wicked Problem

FYI: This is also why your pretty much nuts to not be Agile at this point, with some critical exceptions.

OK just to get you started chew on these 10 basic characteristics and tell me how any of them and the failure of senior stakeholders to understand that indeed software fits these characteristics is likely a key systemic disaster which we see and live every day in this industry. Click here for more.

 Before I was able to ‘take this deck on the road’ which I have done now with success (and why I am revisiting this post to offer insights), I had to get the audience (I hate to call them that… The collaborators is better) knowing (for example) that SOA was not a damn bunch of web services! I had to get people understanding exactly how distributed objects and components ARE NOT THE SAME but are similar. etc. etc.

That ASMX pages in .NET are not even close to what you want to be doing, even with WSE 3.0 and ‘Contract First’ techniques (most notably the WSCF add-in from the always amazing thinktecture).

There is nothing more necessary than truth, and in comparison with it everything else has only secondary value.
This absolute will to truth: what is it? Is it the will to not allow ourselves to be deceived? Is it the will not to deceive?
One does not want to be deceived, under the supposition that it is injurious, dangerous, or fatal to be deceived.

Friedrich Nietzsche, 1890

Thanks Herr Nietzsche… None of us want that. So “Listen for the speakers intended meaning, not your perceived definition”.

In this rather philosophical vein, I offer you here an attempt at the beginnings of a unified P.L. covering many best practices we have evolved in the SOA/SaaS space.

As stated, this presentation is born from necessity as it has become almost impossible to have a meaningful conversation on many topics in this domain due to ‘definition overloading’.

This presentation not only attacks that issue, it also brings together into a cohesive pattern language Object Orientation, Distributed Objects, Components and Services while being careful to not make overly broad generalizations that would harm any SaaS initiative.

For example, it is a best practice to evolve a Domain Driven API which is (at a minimum) the core APU which your services will use to fulfil their contracts.

The presentation is here and feedback is encouraged. This also assumes you have embraced either the SCA environment (for Java development) or WCF for .NET. These are (in our guidance to clients) the only relevant implementation frameworks for strategic large scale organizational transformations to SaaS.

Otherwise in real-world terms there are not resources (developers, or the dramatically increased effort with very little benefit) available to support other approaches. Many ‘purists to the extreme’ might attempt a hand-crafted ‘build it all over again’ approach with hand-crafted contracts (typically XSDs).

As these environments support full extensibility, indeed it is incredibly rare that one of these environments will not completely address your needs. Of course there are always exceptions, but this is addresses to 95% of the market.

Due to the immaturity of this space, it is alarming how many companies believe they are not part of that 95%!! Typically they are being driven by parties (internal or external) that have motivations not in line with the business drivers.

we are customizing this for SilverLight

Stay tuned..

UPDATE!

5/14/2008 (it’s been up for a while however)

This was hard to find for a while but here it is…..

ModelingPowerToys release on CodePlex

http://www.codeplex.com/modeling

Project Description

This set of add-ins augments existing functionality in the Visual Studio Class Designer and the Distributed Systems Designers. It now supports Visual Studio 2005, Visual Studio 2008. The Design Tools Enhancements add-in provides a common set of features that can be used by both the Class Designer and the Distributed System Designers, such as pan/zoom window and rich formatting commands. The Class Designer Enhancements add-in provides additional functionality for the Visual Studio Class Designer, such as HTML export and nested type creation commands. This download includes all necessary source code and a Visual Studio project template for creating your own add-ins for the Visual Studiodesigners. The Class Designer is a developer productivity tool available in Visual Studio Standard Edition and above, which allows developers to easily visualize, design, refactor, and document their code. The Distributed System Designers enable software architects, operations managers, and developers to visually design service-oriented solutions and validate them at design time against their operational environments. The Distributed System Designers are a core component of Visual Studio Team Edition for Software Architects and the Visual Studio Team System.

Here is a list of features provided by the add-ins (you can find more detailed description in the documentation installed by the download):

Design Tools Enhancements
- Diagram Search
- Formatting Commands
- Floating Property Grid
- Pan/Zoom Window
- Design Surface Scrolling Improvements
- Create Comments with Double-Click
- Design Surface Grid

Class Designer Enhancements
- Export Diagrams for Web
- Display Xml Comment Command
- Documentation Tool Window
- Filtering Appearance
- Filtering Lines
- Filtering Members
- MSDN Help on System Types
- Fast Navigation
- Interface Lollipop Labels Commands
- Inheritance Visualization Commands
- Show Type Command
- Association and Inheritance Line Dongles
- Create Tests Command
- Type Creation Commands
- Add Member Commands
- Synchronization with Code Definition Window
- View Class Diagram Command Improvements
- Creating Custom Add-ins

It appears code is even available under the project: modeling.

Damon

Microsoft had executed so well with Linq but to counter that, it’s now apparent EVEN WITHIN MICROSOFT that what will be shipped in the only ‘real ORM’ sense they might offer will fundamentally be a non-starter (at least as the people who care about ORM are concerned).

Even Microsoft key staff agree. I was shocked to see this:

ADO .NET Entity Framework Vote of No Confidence

The signatories of this letter are unanimous in expressing concern for the welfare of software projects undertaken in the Microsoft customer community that will make use of the forthcoming ADO .NET Entity Framework.
Over the past year, Microsoft and the Entity Framework team have received a tremendous amount of feedback from experts in entity-based applications and software architectures on the .NET platform. While Microsoft’s announcement of its intention to provide framework support for entity architectures was received with enthusiasm, the Entity Framework itself has consistently proved to be cause for significant concern.

And they are right on the money. There is no point is doing things well from a design perspective with ORM using the entity framework as is would counteract any benefit.

I hoped we could have a valid alternative as that could only benefit all of us, but we will not, at least for version 1.0

Long story short?

To do quality ‘large scale enterprise’ software of the type say the Java community for example has been delivering, the use of the Entity Framework would  harm your ability to adapt to change to the point of near uselessness.,

That being said here is my information set of links:

NHibernate – Release Version 1.2.1 GA

with optional Castle ActiveRecord – RC3 (stable and OK for production use in my opinion – wrapper on NHibernate)

NHibernate – Pre Release 2.0.X

SVN Trunk is: https://nhibernate.svn.sourceforge.net/svnroot/nhibernate

Castle ActiveRecord Trunk (evolving with NHIbernate 2.0.X)

Microsoft Linq to Entities – Pre Release

Make sure you understand what Linq is and is not. For example, here is one Microsoft clarification:

Linq to SQL, released with the Visual Studio 2008, is designed to provide strongly-typed LINQ access for rapidly developed applications across the Microsoft SQL Server family of databases. Linq to Entities, to be released in an update to Visual Studio 2008 in the first half of 2008, is designed to provide strongly-typed LINQ access for applications requiring a more flexible Object Relational mapping, across Microsoft SQL Server and third-party databases.Here I only discuss Linq to Entities

In 4/5 options NHIbernate is involved, however I LOVE LINQ and it would be fantastic if today we had a way to FULLY leverage it (we can use it to enumerate data as a full set of course). There is a very compelling effort to provide Linq to NHibernate which I have reviewed extensively, and this just provides more incentive to use a pre-release NHIbernate (not sure if it works on 1.2, will check however).

So the decision is further refined to:

Decision Point: How will you leverage Linq?

Use Linq ‘persistence optimized’ expressions

Linq to Entities – Pre Release using a Provider for your DB

NHIbernate Combined with Evolving Linq to NHIbernate Provider

Linq as Linq to Objects / Non-intelligent provider

Linq to Entities

This is a big unknown for now. Sure Linq is fantastic but this is completely a new area for Microsoft and don’t make the common mistake of thinking Linq = ORM. THEY ARE TOTALLY DIFFERENT however Linq is a nice platform to build ORM on top of (as stated people have done).