Get them here.

I could relay the yadda-yadda on the virtues of applying the SPs, but I figure that’s being done to death out there already by more capable folks.  Ok, I’ll toss this bit of verbiage in:

1. SP1 advances the art of application development

The new ADO.NET Entity Framework feature in SP1 offers developers a model-based paradigm and a rich, standards-based framework for creating data-oriented applications shared across multiple applications and platforms. The separation of presentation, data, and business logic used in concert with a single data model will enable developers to spend less time writing plumbing code and more time refining business logic.

2. SP1 makes data-driven programming easier

SP1 offers developers support for ASP.NET Dynamic Data, which provides a rich scaffolding framework that enables rapid data-driven development. Since ASP.NET takes care of creating the presentation layer, a fully functional Website is output and ready for customization without the developer writing a single line of code. Furthermore, with ADO.NET Data Services, Web developers can create RESTful Web 2.0-style applications that have better server scalability and improved caching support.

3. SP1 is the fastest and easiest way to deploy Windows applications

With the .NET Framework Client Profile, a small subset of the Framework that powers client applications, developers can offer their end users a dramatically streamlined and rapid application download experience. In addition, improvements in SP1 result in dramatic reductions in cold start times, allowing developers to serve a broader set of customers with varying hardware profiles.

Just came across this rather interesting post by “morgan” on the blog PHP vs. .NET in the oft-used “Top x Tools to do Y” format (always popular in the dev community).  Despite being common, I think Morgan’s list is a good compilation of resources that should be in your kit if you’re developing ASP.NET solutions, including SharePoint:

1. Code Profiling – RedGate ANTS – Personally, I use AQTime because it works well with both ASP.NET and SharePoint 2003/2007 instances.
2. App Stress Tool – NeoLoad – Never used it myself, as I’ve preferred to use Visual Studio Team System’s web test projects for this purpose.
3. Performance Monitoring – perfmon – But of course!  You can also hook up VSTS to track performance counters and record results – this feature has been available in Visual Studio since 2005, and offers a better way of visualizing this critical operational data.  Mind you, if you are on a server and just need to see what’s what, perfmon is still the standard.  Looks even better on 2008!
4. HTTP Recorder – Fiddler 2 – No arguments here.
5. Interface Manipulation – FireBug – Definitely one of the best browser add-ons;  I use it interchangeably with the IE Developer Toolbar.
6. Debugger -Windbg – This is a given;  if you’ve never used it, give it a whirl:  It’s a great tool.
7. FX-Cop – For policing the standards to keep the code clean;  it’s worthwhile, even if you’re a one-man show.
8. ViewState Decoder – A good idea for ASP.NET and SharePoint apps – Sometimes ya gotta see what’s going on in that mess of stateful info on your page.
9. Text Editor – UltraEdit/Notepad2 – I prefer the latter – to each their own.  I definitely like being able to bring up a lightweight editor with syntax highlighting, regex patterns, hotkeys and shortcuts, etc.

Morgan also offers up the venerable .NET Reflector by Lutz Roeder – a staple if you’re developing against the SharePoint API since the documentation can be at odds with reality.  It’s great to be able to crack open Microsoft.Sharepoint, find your object and see how it works in disassembled C# or VB.NET or any other .NET language.

As promised to the attendees (all 10 or so of them…!) to my riveting and speculative session at the Agile 2008 conference yesterday, below is the link to my slide deck in PowerPoint 97–2003 format:

Agile 2008 – Who’s Teaching Best Practices?

I’ll write more on the feedback I received – it was definitely an engaging conversation that was lively and went a half-hour over the “official” closeout time.  The majority (all?) of attendees were either professors or masters/phD students who worked with professors at institutions from across Canada, the US and Europe.  Basically things broke down into two broad categories:

a) Methodology – I hung a lantern on this one:  Yes, looking at course catalogs or calendars is highly speculative and not “scientific”.  What was more interesting, however, were comments that suggested that descriptions are deliberately and intentionally vague in many institutions so as to afford instructors and professors flexibility to teach topics not specifically outlined.  It was also mentioned that the process for changing course descriptions was so difficult (read: bureaucratic) that it was best to go with the most bland and inoffensive wording so as to avoid dealing with the gatekeepers.

b) Role of the University as Developer of Leaders not Technique Instructors – This one caught me completely off-guard as I didn’t expect it from folks who are idenitifying as “pro-agile”.  There were a lot of comments in this area which essentially distill to “it’s not our job to prepare graduates for working with a specific technology or technique – we teach them how to think and lead”.  The corollary to this is that this is what colleges and “practical” technical institutes should do.

Although I understand where this is coming from, I’ve got a few issues with this response, as I am sure many readers might:  There were no apologies made for the elitist tone.  While I agree there is a need for CS/SE students to be able to learn how to think in abstractions (Joel Spolsky writes on this in his blog), there is also a compatible reality that students should be able to apply the abstract to some concrete tasks – very much what agile/iterative/lean processes do and their corresponding best practices.

I found it completely foreign to hear that there was absolutely no interest in teaching courses specific to best practices.  They could be taught as a component of a course, but it was felt that to add this on to the typical coursework would be unworkable.

Time to think things through…

I acknowledged that my methods were imperfect, my conclusions very rough – however, my personal experiences with university grads as interns suggested to me that there was a potentially interesting connection between what students were learning and what was actually expected of them in the real world.

Attendees posited to me that if industry wants this to change, they need to pony up more cash and reinstate or bolster their own internal training courses.  In effect, the responsibility for teaching agile/iterative/lean SDLC and best practices like refactoring code so that it’s readable and of value is not in the domain of the university.  Never should be, never will be.

Despite this reaction, I’ve been given a lot of good feedback, and I have to take time to process it and begin to address some points more thoroughly, perhaps in a future posting.

Food for thought from Google:

Today, Google downloads the web continuously, collecting updated page information and re-processing the entire web-link graph several times per day. This graph of one trillion URLs is similar to a map made up of one trillion intersections. So multiple times every day, we do the computational equivalent of fully exploring every intersection of every road in the United States. Except it'd be a map about 50,000 times as big as the U.S., with 50,000 times as many roads and intersections.

Whoa.

Earlier today, while reading a posting on an internal Microsoft DL dedicated to agile shop talk, I found a link to an Engineering Excellence wiki dedicated to Scrum.  Whoa!  It appears that my favourite agile/lean/iterative process has roots going back at least to 2004 within the company and that folks were seriously discussing its merits as a delivery model.

One section of the wiki dealing with the Theory of Constraints as applied within Scrum immediately caught my attention:  Within it was a link to a page detailing The Five Orders of Ignorance.  This sounded very Zen to me.  It also conjured up images of kung-fu warriors trying to attain enlightenment from their master as they ascended the steps of their craft.

But that’s just me.

In reality, the Five Orders describe how much we do or do not know about a problem, with the understanding that different processes are more or less appropriate fro addressing problems with differing degrees of uncertainty.  At first glance, this seems quite in simpatico with Boehm/McConnell’s observations with the Cone of Uncertainty around problem domains and when it is most appropriate to estimate a task.

The Five Orders of Ignorance were written eight years ago by Philip G. Armour in an article he wrote for The Communications of the ACM (Association for Computing Machinery) by the same name.  In it, he defines them as:

The 0th Order: Lack of Ignorance

• When you know something and can demonstrate your lack of ignorance through some tangible form.

The 1^st Order: Lack of Knowledge

• When you do not know something and can readily identify the fact.

The 2^nd Order: Lack of Awareness

• When you do not know that you do not know something.  In other words, you’re not only ignorant of something, but you are also unaware of the fact.

The 3^rd Order: Lack of Process

• When you do not know a suitably efficient way to discover that you are unaware of something.

The 4^th Order: Meta Ignorance

• When you do not know about the Five Orders of Ignorance.  This is very Douglas Adams, as having just read this bullet, you now know that there are Five Orders of Ignorance.  Don’t panic.

So now I know what I should know, but didn’t know and in some cases can’t know since I didn’t know I didn’t know in the first place.  Now what?

Using the Five Orders, we can begin to classify the unknowns and uncertainties and how we manage them within the context of a project.  A few years back, the press and late night personalities had a hay-day with a comment that Donald Rumsfeld made with respect to the activities of insurgents in Iraq and Afghanistan:

Reports that say that something hasn't happened are always interesting to me, because as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns -- the ones we don't know we don't know.

After hearing the preceding sentences, the last one sounded positively hilarious:  How on Earth could there be unknown unknowns?  Bwa-hahahaha.  However, in reality this is just an expression of the 2^nd Order of Ignorance.  Note that this doesn’t mean “ignorant” in the pejorative sense – this is about the recognition that more information is needed and that we’re operating within the context of low-knowledge.

Gee.  Sounds an awful lot like most software/IT projects, doesn’t it?

The anti-pattern to 2OI is when we choose to do nothing about it, which takes us to the 3^rd Order of Ignorance – this is probably best expressed in BDUF/waterfall projects where we make an explicit statement about not knowing the unknowns and really have no plan for addressing them because we actively deny the existence of unknown unknowables through rigid project phases.  The project plan is the plan.  And it is all-knowing.  The plan is the Holiest of artifacts and must never be questioned, etc., etc., etc.

But it gets worse: If an unknown unknowable should legitimately come our way and intrude on our carefully-crafted MS Project Plan, we treat it like a bugblatter beast of Traal and promptly wrap a towel around our head in the belief that if we can’t see it, it can’t see us.

And so the madness goes ever on – the condition of low-knowledge persists, paradoxically in the face of the very things that could dispel the “ignorance” and take us closer down the ladder to the 0th Order. 

The Five Orders of Ignorance provide us with an indication of how we address wicked projects and their inherent problems:  Knowing that we can’t know everything about a problem domain and that we need an adequate process to manage this “ignorance” is the key to successful delivery.  This is a fundamental underpinning for all agile/lean/iterative processes:  Ignorance isn’t viewed as a contractual failing (ie. “what do you mean schedule/cost is slipping because you didn’t realize ‘x’ – you should have known ‘x’ !) but rather as an expected opportunity for gathering new knowledge about the domain.