Rockford Lhotka

 Thursday, September 28, 2006

A colleague of mine (customer of Magenic) forwarded me a link to Steve Yegge's wonderful blog post about Agile methodologies (good and bad).

I think my favorite bit in the whole thing (and there are a lot of good bits!) is this:

Bad Agile seems for some reason to be embraced by early risers. I think there's some mystical relationship between the personality traits of "wakes up before dawn", "likes static typing but not type inference", "is organized to the point of being anal", "likes team meetings", and "likes Bad Agile". I'm not quite sure what it is, but I see it a lot.

Like Steve, I am not a morning person, and this probably explains my general antipathy towards Agile Methodologies.

This antipathy is something I've struggled with at length.

I am a strong believer in responsibility-driven, behavioral, CRC OO design - and that is very compatible with the concepts of Agile. So how can I believe so firmly in organic OO design, and yet find Agile/XP/SCRUM to be so...wrong...?

I think it is because the idea of taking a set of practices developed by very high-functioning people, and cramming them into a Methodology (notice the capital M!), virtually guarantees mediocrity. That, and some of the Agile practices really are just plain silly in many contexts.

Rigorous unit testing? Slam dunk!
Writing the tests before writing your code? Totally optional.

Pair programming for intense, multi-threaded framework code? Absolutely!
Pair programming to retrieve a DataSet using ADO.NET? Yeah right…

See that’s the thing. Formalize a set of practices into a Methodology and the practices lose their meaning. Each practice in Agile really is good – in a specific place and for a specific purpose. But when wrapped in a Methodology they become “good at all times and in all places” – at least to most practitioners.

This isn’t Agile’s fault by the way. I’m not entirely convinced that Waterfall Methodology isn’t rooted in a set of perfectly good practices, which were subverted and corrupted by becoming a Methodology.

Nah, on second though Waterfall really is just plain bad.

Thursday, September 28, 2006 2:41:01 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, September 26, 2006
Dunn Training continues to ready its official CSLA .NET training course, with plans for a beta of the course to be taught in November.

If you are in need of some classroom training on CSLA .NET, November is your first chance, probably followed by a class in January.
Tuesday, September 26, 2006 8:33:13 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Friday, September 22, 2006
Thanks to a lot of work by Chris Russi, there is now an official CSLA .NET logo graphic:

and a corresponding "Powered by" logo for web sites or applications that are built on CSLA .NET:

Note that the CSLA .NET license does not require any public display of this logo! But if you would like to use it to let people know that your application or site is built using CSLA .NET, that's wonderful! :)

Chris very kindly created a range of different sizes, and you can download the entire set in one zip file.
Friday, September 22, 2006 3:05:34 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
Jason Bock, a colleague of mine at Magenic, is organizing a code camp in the Twin Cities for November 11, 2006. Click here for details.

I'll be speaking at the event, though I haven't decided on a topic yet.
Friday, September 22, 2006 8:51:51 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, September 12, 2006

I just updated the download page ( to make the BETA version of CSLA .NET 2.1 available.

Make sure you read the Change Log document before going too far. I've tried to list all breaking changes as a summary at the top, with my estimate on the likely impact of each one. You can find more details further into the document.

There will be no more functional changes to 2.1, so this download is complete. There obviously could be bugs, but enough people have been helping me find issues with the last couple pre-releases that I think it is pretty stable at this point.

Barring anyone finding a major issue, I am still planning to release 2.1 by the end of September, so if you have any near-term plans to use 2.1 I strongly recommend trying this beta version on a non-production copy of your project over the next 10 days or so. That will allow you to provide me with any bug reports in enough time that I can try and address them.

Tuesday, September 12, 2006 8:18:19 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Thursday, September 7, 2006

I get many questions about CSLA .NET, and whether it is a good fit for various projects and needs. Many times I put the answers on my web site - building a FAQ of sorts. Here are some links to good articles there, and a copy of a Q&A I recently did for a prospective Magenic client.

What is CSLA .NET?

CSLA .NET technical requirements

Why move from CSLA .NET 1.x to 2.x?

CSLA .NET Roadmap

CSLA .NET 2.0 download page (which includes a summary of breaking changes)

CSLA .NET 2.0 change log (detailed list of changes from version 1.5)

Now for the recent Q&A:

What are the drawbacks to using the CSLA?

This question is too vague to be answered directly. No framework is perfect for all types of application, and CSLA .NET is no exception.

It is not particularly useful for creating non-interactive batch processing code - the .NET 3.0 WF technology is a better bet there. (though the activities in a WF can be created using CSLA, and that's a great model that the WF team really likes)

It is also not particularly useful for reporting. A good reporting tool like SQL Reporting Services is the right answer.

CSLA does require the use of good OO design. Where the DataSet works well (best?) when using VB3 style code-in-the-form architecture, CSLA really requires the application of OO design to build a true business layer. For some developers this can be a hurdle, because they are not used to doing OO design.

CSLA also has some technical requirements. Depending on the transaction model you use, the DTC may be required. In all cases CSLA requires FullTrust code access security, so it can't be used in a partial trust environment (like on most commercially hosted web servers).

Where do the CSLA and the Enterprise Library overlap?

They don't. They are complimentary, see this article for details.

What is the roadmap for the CSLA?

CSLA .NET is a framework for creating a reusable, object-oriented business layer for .NET applications. As such, it continues to evolve based on the evolution of the .NET platform. This means its roadmap generally follows Microsoft's lead, with some exceptions around enhancements to CSLA itself. At the moment the roadmap looks like this:

Version 2.0      - available now for .NET 2.0 and VS 2005

Version 2.1      - available Q3-06 with performance and feature enhancements

Version 3.0 (?) - available Q1-07 with full support for .NET 3.0 (WCF, WPF, WF)

Version 3.x      - available Q?-07 with support for .NET 3.5 (LINQ technologies)

Obviously the 3.x schedules are subject to change based on Microsoft's schedule.

(updated road map can be found here)

What is the model for integrating the CSLA with .NET 3.0\Windows Communication Foundation?

I am working closely with the Connected Systems group in Redmond on this, and related technologies. Additionally, when I build CSLA .NET 2.0 I specifically designed it to allow for near-seamless integration of WCF.

Right now you can get an early version of a data portal channel for WCF from here.

This allows existing applications using Remoting, Web Services or Enterprise Services to transition to WCF with NO CODE CHANGES. This is a very compelling feature of CSLA in my view.

Unfortunately that's not the whole story, and that's why a new version of CSLA will be required in the .NET 3.0 timeframe. CSLA uses the BinaryFormatter for some scenarios (n-level undo, cloning). To support the DataContract model, the NetDataContractSerializer is required instead, so the formatter needs to be pluggable. Again, I've been working with the PM who owns serialization, and this is not a major change to CSLA, and other than there being a new configuration switch this change should have NO IMPACT ON ANY APPLICATION CODE.

How is the CSLA supported in production environments?

CSLA is not a "product". I don't sell it, nor do I sell support for it. CSLA is part of my Expert VB/C# 2005 Business Objects books, and is covered under a very liberal, essentially open-source, license

As such, support in a production environment is the responsibility of the organization using the framework.

What is the typical model for extending\enhancing the CSLA so that one can take advantages of new versions and migrate the custom enhancements easily to the new CSLA runtime?

CSLA is designed to include numerous extensibility points, allowing organizations to customize the behavior of key functionality without altering the core framework. This is most often handled through inheritance, where an organization inherits from a CSLA base class to create their own custom base class that extends or alters the core CSLA behavior. In other cases a provider model is used to allow organizations to replace pre-supplied providers with their own custom providers.

What Application Service Provider and\or 24x7x365 customer references exist for CSLA implementations?

Magenic can provide various case studies around their implementation of projects using CSLA .NET.

For my part, since I don't sell CSLA, I can't fund the process necessary to go through the legal hoops at most organizations to release their names as references. I do maintain this list of organizations who use CSLA. I can say that the framework is used in a wide range of applications, from small to very large and mission critical.

Also, here are some unsolicited quotes from CSLA .NET users:

"A day doesn't go by without me marveling at how elegant this CSLA is."

"Rocky, I learned so much from your books. They had enlightened me on true OO practice, including David West's Object Thinking that you recommend. Thank you."

"First, a huge thank you for an awesome business object framework. I've learned so much just by stepping through your code."

"Having single handedly completed a rather major WinForms app, which has now been in operation for over a year at several sites, I can tell you that you absolutely cannot go wrong choosing CSLA."

"I'd like to say that you did a great job on CSLA. I've found it very helpful in the creation of standardly developed and maintainable code among our teams."

Are there any Visual Studio 2005 project templates available for using the CSLA within VS2005?

CSLA includes a set of snippets and class templates for each object stereotype. Even more importantly, in my view, there are several code-generation templates available for CodeSmith and other code generators, and Kathleen Dollard's book on .NET code generation also includes a CSLA code generator. Additionally, Magenic has a very powerful and extensible code generator that we often use on CSLA projects.

While project and file templates offer some short-term productivity, properly implemented code generation provides increased productivity over the lifetime of the entire project and should be a requirement for any large initiative (CSLA based or not).

Thursday, September 7, 2006 9:31:32 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, September 5, 2006

Several people have asked me about my thoughts on the Microsoft .NET 3.0 Workflow Foundation (WF) technology.


My views certainly don’t correspond with Microsoft's official line. But the “official line” comes from the WF marketing team, and they'll tell you that WF is the be-all-and-end-all, and that's obviously silly. Microsoft product teams are always excited about their work, which is good and makes sense. We all just need to apply an "excitement filter" to anything they say, bring it back to reality and decide what really works for us. ;)


Depending on who you talk to, WF should be used to do almost anything and everything. It can drive your UI, replace your business layer, orchestrate your processes and workflow, manage your data access and solve world hunger…


My view on WF is a bit more modest:


Most applications have a lot of highly interactive processes - where users edit, view and otherwise interact with the system. These applications almost always also have some non-interactive processes - where the user initiates an action, but then a sequence of steps are followed without the user's input, and typically without even telling the user about each step.


Think about an inventory system. There's lots of interaction as the user adds products, updates quantities, moves inventory around, changes cost/price data, etc. Then there's almost always a point at which a "pick list" gets generated so someone can go into the warehouse and actually get the stuff so it can be shipped or used or whatever. Generating a pick list is a non-trivial task, because it requires looking at demand (orders, etc.), evaluating what products to get, where they are and ordering the list to make the best use of the stock floor personnel's time. This is a non-interactive process.


Today we all write these non-interactive processes in code. Maybe with a set of objects working in concert, but more often as a linear or procedural set of code. If a change is needed to the process, we have to alter the code itself, possibly introducing unintended side-effects, because there's little isolation between steps.


Personally I think this is where WF fits in. It is really good at helping you create and manage non-interactive processes.


Yes, you have to think about those non-interactive processes in a different way to use WF. But it is probably worth it, because in the end you'll have divided each process into a set of discrete, autonomous steps. WF itself will invoke each step in order, and you have the pleasure (seriously!) of creating each step as an independent unit of code.


From an OO design perspective it is almost perfect, because each step is a use case, that can be designed and implemented in isolation - which is a rare and exciting thing!


Note that getting to this point really does require rethinking of the non-interactive process. You have to break the process down into a set of discrete steps, ensuring that each step has very clearly defined inputs and outputs, and the implementation of each step must arbitrarily ensure any prerequisites are met, because it can't know in what order things will eventually occur.


The great thing (?) about this design process is that the decomposition necessary to pull it off is exactly the same stuff universities were teaching 25 years ago to COBOL and FORTRAN students. This is procedural programming "done right". To me though, the cool think is that each "procedure" now becomes a use case, and so we're finally in a position to exploit the power of procedural AND object-oriented design and programming! (and yes, I am totally serious)


So in the end, I think that most applications have a place for WF, because most applications have one or more of these non-interactive processes. The design effort is worth it, because the end result is a more flexible and maintainable process within your application.

Tuesday, September 5, 2006 11:24:24 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Thursday, August 10, 2006
Yesterday I recorded two more DNR TV shows on CSLA .NET with Carl Franklin, so watch for those to go online in the next few weeks. Carl does a nice job of editing the recordings and cleaning up the audio, so it takes some time between recording and "airing", but it is well worth it!

Thursday, August 10, 2006 1:57:00 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Saturday, August 5, 2006

People often ask me how business is going, or how Magenic is doing. I answer “good”. But that’s not really true.


It turns out that it is better than good. I’ve been in consulting, one way or another, for nearly 12 years now and there are a couple times of year when things always slow down: late summer and the end-of-year holidays.


Well this summer, for the first time in my recollection, summer has gotten more busy, not less!


So I’m posting this blog entry in an attempt to address Magenic’s primary issue right now: finding good .NET development resources. Yup, we just can’t find enough people with good .NET experience. This includes regular Web and Windows .NET development, middle-tier work and SQL Server. But it also includes Biztalk Server and SharePoint Server as well. Any peripheral technologies like content management are always welcome too.


I’ve been with Magenic for 6 years as of this month, and I’ve never regretted my choice to work for the company. Greg and Paul (the owners) have steered the company through the dot-com bubble and its subsequent crash with admirable skill. And while no one could say 2002-4 were fun, I can honestly say that I felt more secure at Magenic than my friends at other companies were feeling at the time.


Sure, consulting is consulting. If you want to come work for Magenic you need to realize right up front the realities of being a consultant. But given that, I find it hard to imagine a better consulting company to work for, especially if your focus is around Microsoft and .NET.


One of Magenic’s core tenants is to try and find “cool work”. Obviously that’s not always possible, because each individual defines “cool” differently, and there are business realities around consulting that simply can’t be ignored. But just the fact that this is one of the company’s core tenants says a lot!


So here’s the deal. If you live (or would like to live) in the Boston, Atlanta, Chicago, Minneapolis or San Francisco areas, and if you’ve got .NET skills, and if you want to escape the politics of IT in exchange for the life of a consultant then this is an excellent time to see if Magenic is the right place for you.


If you are interested, just send me an email and I’ll forward it on to one of our recruiters (kind of a fast-track offer :) ). Of you can contact recruiting directly through the web site.

Saturday, August 5, 2006 2:17:13 PM (Central Standard Time, UTC-06:00)  #    Disclaimer