I have finally started toying with asp.net 2.0. I figured I better get with it before it was RTM. In any case I started with converting my homebrew website project.

The conversion utility was actually quite good, and made a number of changes; including folder structure, a few access modifiers, and most importantly removing the notion of "code behind" and replacing it with partial classes for pages and controls. It's not like it compiled right away, but nobody expected that. The first thing to note about 2.0 is that application code (specific business logic classes, special functional classes, interface definitions, etc) is now totally seperate from page and control code. In fact, that's one of the new asp.net system folders - "App_Code". The classes defined in this code are compiled to a seperate assembly at run time. The pages are compiled to their own assembly, and neither assembly is placed in the /bin directory any longer. You will find the assemblies in the temporary asp.net folder - as you would have in 1.1. For my homebrew application I see 3 assemblies - "App_Web_[random].dll"; "App_Code.[random].dll"; and "App_global.asax.[random].dll".

To take a look, I quickly open them in Relfector and verify the contents...

Yep, that's my app_code section of the site. Then I open the App_Web...

OK, not quite what I was expecting. Those are my controls (ascx), but I don't see my pages anywhere. Then I get what I expect from the global...

As you can see, this presents a new way of thinking about things like state managers, or custom configuration file readers. If you have this in application code, that code can no longer access instances of pages, nor can you late bind to these assemblies as they are not published by name to /bin.

I also use UIP on the site, which requires late binding, so that was one thing that was broken. The other was that I use a PageBase object for each page to create a master template style arrangement for common navigation, and footer - object instances of controls. The idea of a master template is built into asp.net 2.0, so I'll have to look at changing. In any event, the pages are also handled by a state manager. This is a business object which interacts with instances of pages and controls. Both of these concepts are broken in asp.net 2.0 because business logic classes (app_code) have no way of knowing about page classes. This problem is easily handled through a bit of indirection and late control binding as discussed here:

http://msdn.microsoft.com/asp.net/default.aspx?pull=/library/en-us/dnaspp/html/upgradingaspnet.asp

(look at the section on conversion issues)

This doesn't really put my code in a great place for 2.0, but does bring it to a point where it will compile. Because of the late binding, I actually end up having to move all of my app_code out to a separate assembly so I can reference it. I asked Scott Guthrie about this, and ended up having an interesting discussion (mostly with Simon Calvert actually) regarding the usefulness of the app_code section.

Simon gave the following reasons for the app_code architecture:

"App_code gives several benefits in developing applications:

it’s a known folder into which you can easily drop code files and not have to undergo any manual build step. This improves productivity in certain situations. App_code also has given semantics for arbitrary file extensions, not just regular code files. You can drop XSD or WSDL files and again, everything is done for you in the runtime. That is proxies are suto generated etc. Then in the designer tool, you get benefits in creating a class file and objects within the folder and have immediate intellisense and statement completion against your custom objects. This latter point is important in terms of productivity. If the app_code were a separate class library, then you would need to have separate projects, with references and undergo a build process in order to pull the updated class library to the web project.

App_code also allows sub-separation for specific scenarios like code languages, so you can easily separate out and manage the vb/c# in a shared code project for example

When using the app_code folder, the compilation process means that the assembly is compiled and that your pages all get references to that assembly automatically. It therefore is a separate assembly

Consuming types from the app_code folder is as simple as new-ing the type in your page codebehind for example and in cases where you might need the assembly name, we have strived to remove the requirement for the assembly name. For example, if you create a custom control in app_code then you can register it without referring to the assembly name. In cases where the name is required, you can use the moniker, “app_code”"

Well, I don't know enough yet about working in asp.net 2.0, so I am sure we'll find Simon's advice helpful as we move along. For my project, I still need that late binding so I have a separate assembly. They did mention potentially getting at the app_code via the BuildManager.GetType() method, but didn't expand on that, and I haven't looked into it.

My final issue to get the project actually working was to get SQL Server reconnected, and minor modification to an XmlValidatingReader (deprecated in 2.0) in the UIP to become an XmlReader with the proper attributes.

I purchased the book Crystal Clear by Alistair Cockburn (apparently pronounced "Koh-burn"). As I read it I will try to post highlights. Seems like it has some promise.

I finally bottled that smoked porter homebrew last night. That's going to be good.

As I bottled that beer, I was thinking through the Agile methodology information I have read recently. While I have been familiar with Agile for some time, I haven't really been in a situation where I needed to utilize it, or implement it in depth. However, that time has come with some changes at a client site. They want more maturity in their development, fewer defects, more predictable timelines - you've heard the story 1000 times.

First question - why is it so difficult to get development done right when we all know the answers to better development? While I think it has something to do with developer motivation, I think it is primarily a management issue. In organizations where the management is unwilling to trust development, and to work closely with them on a "methodology" that seems like just another "latest thing", a framework like Agile cannot take hold. Old fashioned results orientation around artifacts and PM tasks that development doesn't really want to invest in are still demanded by management. Furthermore, there is no tolerance for learning curve time to implement the changes. Half-hearted or non-existent mangement investment leads to a failure of implementation in the development department. This leads management to declare victory on it being a useless methodology change, and then to cry again about results.

So, I guess my first answer to my first question is that "WE" all know how development should be done, but not everyone in the organization agrees with us.

The second answer might be that we don't actually know how to do it, or agree on what's best. In my experience, the ability to gain understanding of a potential implementation is limited by undertstanding of the scope of the development effort, and what pieces of the latest methodologies will be used, and to what depth. Are we trying to be CMMI level 5, level 1, or nowhere near it? How much can we expect our PMs and Business Owners to engage in scenario definitions? What will the resulting documents look like? So, even as developers we tend to mill around trying to answer management's questions and needs, along with how it will work for us. Often the effort ends here, or again becomes half-hearted.

Basically, these issues cause me to want to find a way to ease into this methodology change. I can see the Agile paradigm being broken into two methodology sections - management methodologies (both team and project) and development. Development methodologies might include things like TDD, SCRUM, and pairing. Management methodologies include managing special cause variations and the related tracking, velocity tracking, sprial workplans, etc. In discussing this with a friend from the client in question, he had a good idea on how to work with this as it relates to managemnt - treat the output to management as an interface. Give them the same old stuff based on information we gather however we want at the development team level. This is sound I think, and even matches some of what I was reading from David Anderson about meeting CMMI requirements with MSF Agile.

In any event, the question then becomes "What are the essentials to getting started with an Agile development team?". Can we do SCRUM without stakeholder buyin? No. Can we do TDD without management buyin? Maybe. Can we track velocity without changing the project tracking software management just purchased? Maybe. The answers to the 'maybe' questions becomes, "What does development control as a department" and "How high up in Development can we get buy in". I think in this situation development controls all PM activities, and we can get buy in all the way up. That means we can define tasks in terms of scenarios, we can estimate timelines for management while not tracking our own progress this way. Maybe along the way we will even be able to give them better information, and so win them over. But we'll hold that goal patiently. For now, we also control development methodology, so we can being with TDD and pairing. A few buyin issues do exists here however; it takes time to build test harnesses, and changes must be made to the physical space to facilitate pairing - perhaps even common development machines purchased.

Well, we are going to try. I can't say the team is optimistic yet about their chances. Management has crushed the spirit a bit. Hopefully, I can keep you posted on the progress, and not the failure of this initiative.