New Solution Structure and Political Bogus

Matt haven't got chance to touch the new solution structure last Friday. However, he managed to document our thoughts and decisions onto Cockpit's PatternWiki for later reference.
Now we three get together start to make changes according to the standards. This is great. Eventually, we have something all happy and I can finally put my heart back to the chest. Although it is still not 100% as 'Central .Net PatternWiki' suggested.

Now we have something like this:
File structure:

{root}/Cockpit
|- Client
---- Cockpit (proj) -- client app
---- Controls (proj) -- reuse controls

|- Server
---- BusinessLayer (proj) -- cockpit business logics
---- DataLayer (proj) -- data access layer
---- Teps (proj) -- Topend integration, will moved to shared later
-------- Interfaces (folder)
-------- Core (folder)
-------- Components (folder)
-------- Product (folder)

|- CockpitWebServices (proj) -- Web Services
|- Common
---- DataSets (proj) -- common library to both client and server side
|- TestTools (proj) -- test utility tools

Solution structure has Client/Server/Common folder hidden. They are there to physically group projects/assemblies.

Namespace:

CompanyName.Cockpit
CompanyName.Cockpit.Presentation.Forms
CompanyName.Cockpit.BussniessLayer
CompanyName.Cockpit.Datalayer
CompanyName.Cockpit.Controls
CompanyName.Teps
CompanyName.Teps.[Product]
CompanyName.Teps.Core


Well, it is impossible to have it followed the 'Central PatternWiki' very strictly. Every project (I should say "Solution") is a unique piece. 'Central PatternWiki' gives a loose, high-level abstraction of the practice we have from another ASP.NET project. As in this organisation we are new to .NET development. The central standard needs further elaboration by each satellite project standard that works around it.

It is unfair to accuse central pattern to be 'loose, board and vague' because when it was put in together, there isn't a counter project delivered by another team to verified it. Vice versa, it is dictating to criticise Cockpit project not following the standard.

We make excellent practice a standard and it evolved as improvement made. What we should really look at is whatever that makes more senses, rather than 'we spent million pounds to have it, so live with it.'

Current design came after quite a lot of discussion and debate between Matt and myself and largely follows Microsoft Namespace Naming Guidelines and Coding Techniques and Programming Practices, I would rather say it is a sensible decision.

Sample .NET Coding Standards is also a good sum-up of what Microsoft proposed.

However, there are some unpleasing incidents. D(real name hidden for obvious reason) "happened" to notice what Matt has done for the Cockpit standard this morning and then went to talk to Gary and Matt to find out what is about. Then he came back to me and shagged (don't really want to use this word) me. "We have been spent 9 months and 150 thousand pounds on the pattern, why don't you follow blah blah blah..." Then he sent out an email to Matt, Gary, Phil and cc it to TS and CM. The email is about the Cockpit Patternwiki, mentioning the information there shouldn't really be there and should on the Central Patternwiki and maximise knowledge sharing.

I think there few things here are inappropriate:
1) The budget and expense on another project that brought the central pattern is irrelevant to what Cockpit does. Until the corporate-wise standard being approved and signed off, which then becomes 'rules', there isn't any good reason that we shouldn't make it better.
2) I have been trying to sell central pattern since I joined the Cockpit project from day one. I can only make suggestions, but it is the decision of Cockpit technical lead and architect. In this regard, I would say it is a medium victory that we finally made the solution changes.
3) As one of members that worked on Cockpit team, D should send the email to me as well rather than keeping me out from the conversation.
4) It is technically and politically infeasible for updating Central Pattern without negotiating with the gatekeeper. Otherwise, it will become a graffiti eventually. Or end up with endless debating on 'goods' and 'bads' without having anything delivered. My attitude is 'do it', 'prove it' then show to people.

Now, I should really think about how and when to put the Cockpit Pattern to be with Central Pattern.