Discriminating Against Special Case Entities

This is something that I'm really struggling with as I pick up O/R knowledge. I'm going to attempt to describe my confusion using a trivial example so I hope this is clear...

I'm building a bank account management system. I need to track different types of accounts, transactions, etc. Typically, types are structured in the database as reference data (look-up tables, pick your poison). So, I'll have an Account table and an Account ENTITY. There could be several types of accounts, like Savings, Checking, Money Market, etc. and these values exist in the AccountTypes table. Same goes for transaction types.

Obviously, all this data needs to be maintained. New types of Accounts are created, retired (read deleted, for simplicity's sake, please...) and if there needs to be a corresponding ENTITY, ok no big deal. However, I'm going to have business logic that is going to depend on what type of account I'm working with; if it's a checking account that you earn an extra dollar every time you have a direct deposit, I'm going to have to accommodate that logic.

I feel this is where ENTITIES and O/R mapping are causing me heartburn. The OCD part of me says that everything needs to be identical, so I need an ENTITY for the account type data. Great. Pretty even. The design is consistent. However, when I go to check what type of Account I'm working with, what am I going to check against? My only option at this point is "theAccount.Type.Id = 1234".

"I smell man flesh."

OK, maybe not. But human-injected duplication is a repulsive as rotting flesh. Plus, this makes deployment a bear because, now, all the IDs have to stay the same or else you break your code. But, if I make the AccountType ENTITY a SPECIAL CASE so that "theAccount.Type = AccountType.DDBonusChecking", I'm forced to rebuild/redeploy the application any time a new AccountType is created. Not only that, but I feel that I've now sufficiently mucked-up my database design as well because there's no real "need" to have the AccountType table since they all exist in the code anyway.

It's possible that I'm making the situation much worse than it actually is. However, this is something that my group does in applications regularly; that is, we give the customer the ability to manage their reference data. When we weren't using ENTITIES and just DataSets and stored procedures with business logic, it wasn't an issue. Just look up the value and move on. There doesn't seem to be any direct analog to that with ENTITIES that is as elegant...

Agile Analysis and Planning

A week ago, my group was contacted by an extremely high-profile customer. Apparently, they are looking to migrate a monolithic J2EE application (presumed million(s) of LOC) to a .NET application, as Sun has announced that support for its Unified Development Server and Forte technologies will expire come Jan 1 2006 - at least, according to my knowledge.

The customer, from my early and brief interaction, is dangerous. They're developers and, apparently, had an active role in the development of the current system. Every time I heard "and the XYZ component, which is a SINGLETON..." my skin melted off my body...

Anyway, given the inherit complexity such an application could poses, they are looking for migration plan(s) on how such a project would be approached. The output will be a document, or several, stating that, given the recon, we suggest the following approach(es) and then the customer gets to pick which one is the prettiest, since they really, really dig architecture diagrams.

So...given these ideas, could this analysis and planning/migration document be managed under an Agile methodology? I mean, planning and analysis - which, I take as "big up-front design" - seem to be the antithesis of all that is Agile. However, since the system is so vast and - oh, yeah, we only have about a month to produce the document - there's so many unknowns that will be difficult to discover, it seems as though it could be run Agile-ly and succeed.

Personally, I believe anything and everything can be done with an Agile spin. While I am far from any stretch of "mastering" Agile methods, I try to find ways to apply it to every day problems in life...Anyway, if any one has any thoughts or suggestions, I would greatly appreciate them.

Virtual [Agile] Developer

I stated earlier that, in July, I was planning a presentation on Virtual PC and Virtual Server. Overall, it was really a hit and miss. One coworker/higher-up asked about how my group (AppDev) could possibly work with our networking and server-consolidation offerings to provide "packaged"(?) solutions, which wasn't really my intent, but hey, if it pays the bills...

Actually, what I was hoping to drive home was how those products could enable our team to develop better software. We do a lot of, well, immature things as a team: Load beta software on servers that customers are using, not to mention the rest of the team - things like that.

Those kind of "mistakes" just make your job more difficult. When you need to deploy the latest "build" (because, sigh, we don't do automated builds..."small moves...small moves"...) to the staging server, it's a chore because you never know if it's gonna take because the machine has so much crap on it, it's unreliable and almost unusable.

Here's a thought: what if, when the automated build, that we don't have, runs after we check code in, automatically created a new instance of an already, preconfigured, sysprep'd virtual machine that the build could be deployed to? OK, that's pretty cool. Now, how many acceptance testers do you have? OK, got that number? Make that many machines. Now your testers can test - reliably - in an isolated and constrained environment consistantly everytime you deploy the software. They could even have their own instance of the database(s) running on those machines so that they aren't trampling over each others feet. Uh oh! They found a bug?! How about saving the machine state,copying it to your machine, attaching it to your local instance of Virtual PC, restoring it in the condition the user left it and attaching VS.NET to the process to debug it?

And oh yeah, did you know that Virtual Server is managed via a web site? Oh, and that you can connect to machines using that web site?

You know...that's insane. It probably would just save so much time it's not worth talking about any more...

NB: I tried the whole remote debugging a virtual machine with an ASP.NET app. It didn't go so smoothly. I'm sure others have tried and met similar fates. I imagine that a WinForms or console apps would produce better results since you won't have to contend with IIS owning the process and everything. It is doable though...

Benefit of the Doubt

So I genuinely try to give other developers the benefit of the doubt; if I don't get why they wrote/designed something the way they did, I'll try my hardest to accept it and say "they probably had there reasons". And I do this no matter who the author is: internal/group or even Corporate shops...like Microsoft...I'm giving them the benefit of the doubt on this one...to an extent...

I was "pairing", very informalily (though I guess that's the point), with a coworker and we got into a discussion regarding the file he was working on. He was building a screen to manage a M-to-M relationship between two entities (you know, an "select one, select all, deselect one, deselect all" interface?)* and had to filter the selected items out of the "available" and also return a list of the selected items. His code consisted of something like the following:


Public Property Selected as IList
Get
return selectedValues
End Get
Set(value as IList)
for each item as ItemType in value
for each availableItem as ItemType in Available
if item.Id = availableItem.Id then
available.Remove(item)
end if
next
next
End Set
End Property


I informed him that he produced some pretty smelly code since the ASP.NET ListBox control exposes FindByValue() and FindByText() methods. He pointed out to me that these method probably just perform an O(n) iteration of the Items collection to find the desired item. I said "NO WAY! Microsoft is sooo much smarter than that. They probably used an IDictionary implementation that's specialized for such a collection, making it really easy to find the values"

Um...No. They didn't. I even checked Framework 2.0 B2. See for your self:



Why in the world would they do it this way?! I can't imagine it's because of ViewState and persistance. On top of that, there's duplication between FindByValueInternal and FindByTextInternal that I'm sure could've been avoided, especially by using an IDictionary implementation of some sort.

I still, to a degree, feel the need to give Microsoft the benefit of the doubt as they wrote the Framework and I'm sure they had a really good reason for not approaching this problem differently. Needless to say, I was seriously saddened by my discovery...

* The same developer asked me earlier in the day, in reference to the multi-select interface: "so what's the order of the buttons?" Lacking a better answer, I said (with jestures) "it's over, over-over, over, and over-over...OR...over, over-over, over, and over-over, depending on your perspective"...He knew exactly what I meant too...