As a product manager at patterns & practices, I got to write a lot more code than most people would expect from a product manager. However the nature of the job and the team meant that it was basically all prototypes and samples. So after over 3 years, it's very exciting to be working as a solution architect in Microsoft's Solutions Development Centre where I am able to get my hands dirty with real enterprise projects again. And for the first time in ages, I get to experience something most of you do every day: finding out what it's like to use patterns & practices deliverables on "real world" projects.
Our team has just started work on a large customer project, and for the last two weeks my key task has been to establish the baseline architecture, which basically involves trying out design approaches and establishing repeatable patterns through implementing just a couple of use-cases end-to-end. So now I wanted to share how we are using patterns & practices deliverables on this project and what the experience feels like from outside of Building 5. Keep in mind that we are still in the early stages of this project and we may yet revisit any number of design decisions as we implement more features and get more test feedback - but hopefully these first impressions are still interesting, and I'll try to keep you updated on what changes as the project progresses.
I'm sure it will come as no surprise that we're making extensive use of patterns & practices deliverables on the project, although to be perfectly honest I didn't expect to be using so much at these early stages - it just happened that we kept running into requirements where they proved helpful. Here's a quick rundown of what we've used where in the baseline:
So that's what we've used. But what was the experience like? OK I realise I'm not entirely impartial, but here are a few thoughts from the first couple of weeks of work:
I'd be interested in hearing whether I'm still looking at p&p through rose-coloured glasses, and to hear how your experiences are different to mine. Also I know that Don, Grigori and the gang will be watching, so this is still a great forum to influence the direction that these deliverables go in the future.
Any chance we will be able to peek into code rather than your quite impressive description?
Really like to see something because EDRA is getting 4 years old and so far no enterprise reference implementation is available using the .net 3 feature-map
Hi Adrian -
I'm afraid that one of the differences between working on p&p projects and customer projects is that customer confidentiality means that I can't share the code. Still even if I could share it, at this stage it's way too early to position this solution as a blueprint for others to follow. Once the design has matured and has been adequately tested, I may be able to extract the interesting (and generic) elements into a new sample (or get the p&p team to do this).
In the meantime, have you had a look at the p&p Software Factories, including the reference implementations? These deliverables are much more recent than EDRA and play a very similar role in demonstrating proven practices for end-to-end applications.
There's one big thing that sticks out in my mind. Developer pain doesn't really hit until you are past the green field development part of the project. I can cobble together nearly anything to produce a working v1 of an average sized project. Don't take my usage of the word "cobble" to make an implication on the P&P stuff. By cobble, I mean nearly anything (non-OOP, half-baked in-house frameworks, etc). Experience tells me these systems come together really fast for v1 (short time to market), but then the fit hits the shan after a large number of requirements changes. v1 is really quick/cheap to build, v2 comes after many requirements changes and is either a complete rewrite or extremely expensive in terms of labor and debugging. This has been my experience in consulting as I started out building a lot of half-baked applications. ;-)
While I think it's very important that a team dogfood it's own work (and I applaud you for this), realize that the pain only shows itself down the road.
Martin Fowler summed up my experience here:
I would also be interested to hear the development methodology you guys are using (planning/testing/etc). Tools are only a little piece of the battle.
I do appreciate this post, and I look forward into getting a better peek into the MS world. :-)
Two things I've noticed...
1. The config problem never goes away and in fact keeps getting bigger and is harder to change later on. I think it's a good policy to analyse your common bits of config and try to share them somehow. This doesn't just mean sticking them in the machine.config though!
2. The comment about greenfield is true. You may find that you have different views on some of this stuff when you enter perf test ;)
As I mentioned in my last post , I've been having some fun discovering what it's like to use patterns
As I mentioned in my last post , I've been having some fun discovering what it's like to use
MS Patterns and Practices to Become Test-Infected?
Well, I've had a blast using the data library. I had a custom data class that was still a bit cumbersome to use, but man-o-man this new way for data access is awesome. See, this is my first time using any p&p library and now I see what I've been missing. Can't wait to utilize the exception class. Thanks Tom and crew for such an awesome, quick solution developing apps.