So much, so fast

One of the toughest things about being an application architect at a small company is needing to know everything about everything, yesterday. I'm working on a very large project right now, and I need to get in depth with a huge number of topics, all at once, just to get the project kicked off. Other parts of the team are sitting on their hands waiting for me to get stuff done, and I hate being a bottleneck. It makes for some very busy days where I don't seem to get a lot done, or get to know as much about a topic as I really need to to make sure I am pushing us in the right direction.

For instance, today was a fairly typical day.

I spent an hour reading through emails and blogs this morning as I ate my breakfast and chatted about the inauguration in my office.

I then reviewed a spec I had written yesterday on Security Authentication, Authorization and Threat Modelling for my project. I had to go back and dig into the Geneva Framework and the .NET Access Control Service to see how close I was to the mark. I've got a real fear that I need to become a lot more familiar with threat modelling before I can consider this spec complete, or I need to con someone else in the office into become the SME on Security.

I spent two hours writing an application specific functional spec for a WCF Based Azure Web Service, mostly dealing with the 'what' side of the house, i.e. what it's supposed to do, but leaving out the 'how', i.e. how it's going to do what it has to do. This particular piece of the project is one of the more important aspects because the service has to be very secure, has a lot of validation built into it to prevent corrupt data from being uploaded or downloaded, and I had to build in a migration path to eventually move from one version of the service to the next without breaking existing clients. I actually took the time to put a lot of thought into that mechanism, but the spec isn't close enough to be ready to turn over to a developer (unless it is me), because I didn't cover any of the aspects of Azure or Geneva that need to be covered in a 'how' spec.

I spent an hour and a half re-arranging projects in my Team Foundation Server project to try to get everything organized and clean, the way I want it. This involved changing some namespaces, and working through a real bastard of a problem involving a confusion between the Silverlight Unity Framework and the Windows Unity Framework. Somehow the Silverlight Unity DLL had been linked into one of the non-Silverlight projects, and nothing was compiling. This problem came on the heels of a similar issue yesterday where the ICommand interface I was using in one of my projects got linked to System.Windows.Input instead of the PresentationCore library. That cost me three hours yesterday. I really need to lock down my project files (usually from myself).

I then spent 2 hours delving back into the MVVM pattern for WPF development to figure out how exactly to launch dialog boxes and other windows from a view in the 'correct' way. Where exactly does the code go to 'new' the view, and which view model do you bind it to? That's a whole blog post unto itself. I've just started with the MVVM pattern, and it's powerful, but in trying to explain it to a junior dev, he kept asking me how the View Model in our scenario wasn't just a big global variable, albeit a global variable with a lot of pizazz. It's those type of questions that lead me to doubt my understanding of the pattern, and I ended up spending a lot more time trying to explain the pattern to myself again, but we all came away with a slightly more enlightened view.

I spent an hour this afternoon trying to turn an XSD file into classes using XSD.exe and then trying to figure out how to turn those classes into database tables. We probably should have gone the other way and started with tables, but that's a whole other discussion. I'll have to finish that task tomorrow.

I also spent twenty minutes trying to help our project manager tie TFS Work Items to MS Project properly. We want to have two different project plan views, one for internal use, and one, a higher level view, for the customer, but we don't want to maintain the tasks in two places. We're working through some theories on exactly how to do that. I've never used TFS prior to this project, so we're learning some interesting lessons.

Tomorrow, I need to get a handle on the project plan as it is due by Friday. I need to review the WCF spec I did, get the classes converted to database tables, spin up an entity framework model for them, dig into SDS and attempt to migrate a SQL 2008 Data model into SDS, and then I'll need to map that back to my Conceptual Object model in EF. That exercise is also an upcoming blog post. And oh yeah, I need to build out the Access Control functionality so I can set up the 'how to' spec for the WCF services. Right after I finish the first draft of some other functional specs for the other applications we're designing so the QA team can start writing their test plans.