Charteris Community Server

Welcome to the Charteris Community
Welcome to Charteris Community Server Sign in | Join | Help
in Search
Home Blogs Photos Downloads

Alan Dean

Senior Technologist, Charteris

Principles and Axioms

 I'm holding an internal discussion arising from one of our regular Core Capability conference calls at the moment and I thought that it would be useful to surface part of that to the outside world to get feedback.

The premise is to see if it is possble to set out certain principles and derive some axioms from those principles that can drive out 'default development environments'. Here, I have chosen two sets of axioms. The first being "Microsoft" for those clients who prefer to use mainstream, low risk tooling and practices. The second being "Alt.Net" for clients who are willing to work with non-Microsoft software for development purposes, most notably open source software.

My thinking may be wrong. My decisions may be wrong. Whatever you think - let me know!

Please note that this is only a first draft - errors and omissions are to be expected.

Axiomatically "Microsoft" Axiomatically "Alt.Net"
Principle: Project status and progress should be available.
Team Foundation Server
MS Project		 Burndown Charts
Principle: Requirements must be defined.
Functional Requirements Specification
Non-Functional Requirements Specification		 Personas
User Story cards
Principle: The architectural context must be defined.
Logical Architecture Specification
Physical Architecture Specification		 Logical Architecture Specification
Physical Architecture Specification
Principle: (Non-)Functional tests should be defined.
Scenarios in Team Foundation Server Scenarios on reverse of User Story cards
Principle: Non-Functional tests should be defined.
Scenarios in Team Foundation Server Scenarios on reverse of User Story cards
Principle: Version Control must be employed.
Team Foundation Server Subversion
Principle: Services should be employed to traverse boundaries.
WCF / WS-*
REST		 WCF / WS-*
REST
Principle: Coding standards should be enforced.
FxCop & StyleCop FxCop & StyleCop
Principle: Defects should be tracked.
Team Foundation Server Bugzilla
Principle: Developers must test units of code in isolation.
MS Test NUnit
Principle: Where possible, testers must automate functional verification of the application.
MS Test FitNesse
Principle: The application must be subject to a build process.
MSBuild NAnt
Principle: The application should be automatically built on a regular basis.
Team Foundation Server CruiseControl.net
Principle: XML Code Comments should be compiled.
Sandcastle Sandcastle
Principle: Deployment media should be built.
WiX / Votive WiX / Votive
Principle: Where possible, database design should evolve.
Visual Studio Database Edition SubSonic Migrations
Principle: Where appropriate, ORM should be employed.
Linq2SQL SubSonic or NHibernate
Principle: Where appropriate, diagnostics should be implemented.
Enterprise Library Logging Block log4net
Principle: Where appropriate, dependency injection should be employed.
Unity StructureMap or Spring.NET
Principle: Where appropriate, the MVC pattern should be employed in web development.
ASP.NET MVC ASP.NET MVC or MonoRail
Principle: Where appropriate, in-memory caching should be employed.
Velocity Velocity or memcached
Principle: Where appropriate, reverse proxies should be employed to enhance HTTP scalability.
ISA Server ISA Server, Apache, or squid
Principle: Where appropriate, AJAX should be employed in web applications to improve user experience.
ASP.NET AJAX jQuery
Principle: Applications should be security-hardened.
SDLC & Threat Modelling STRIDE SDLC & Threat Modelling STRIDE
Principle: Applications should encrypt sensitive data.
System.Cryptography System.Cryptography
Published Jul 21 2008, 09:18 PM by aland
Filed under:

Comments

 

Greg Young said:

Is Linq2Sql really an ORM? seems to be missing most of the "M" part.

Should Windsor be mentioned for DI?

is subsonic really "alt"?

Continuous integration: TeamCity?

for enforcing coding standards how about ndpend?

defect tracking: Jira, FogBugz?

July 21, 2008 10:16 PM
 

Dave Laribee said:

Alan,

I wouldn't set the ALT.NET and Microsoft as mutually exclusive. I think we get into trouble when we get into the whole "Us vs. Them" debate and, from my vantage, that's not at all what it's about.

Maybe you could frame your guidance around "for pay" and "for free" tools. I think you can take your principles and say "okay, here, this is the kind of tool we'd be looking for?" Then, from there, you can discuss the mainstream or commercial option along with the community-supplied or open source option: tradeoffs, maturity, etc.

At any rate, I'd bring ALT.NET into the mix to discuss the principles we're arriving at. There's a number of Microsoft products that can let us get closer to the principles if not right on the money as far as tooling.

July 22, 2008 2:36 AM
 

Glenn Block said:

The list implies that some things on the list are mutually exclusive though they are not.

For example TFS vs user scenarios on story cards. You do not have to do one or the other, you can do both. For example p&p practices uses XP yet also uses TFS for workitems. Stories and Epics tend to be more coarse grained than workitems. You can start with cards, and then create work items in TFS that correspond. You can do this on an incremental basis.

The implication is that it's a black and white decision and that you cannot mix and match. The reality is that you can mix and match based on the needs. This story continues to improve with frameworks coming out of Microsoft like MVC which can integrate well with open-source containers  like Castle, Structure Map, etc.

July 22, 2008 8:32 PM
 

David Oliver said:

You could go one step further and do alternative databases and BPM engines as well.

August 9, 2008 12:50 PM
 

Bookmarks about Scalability said:

Pingback from  Bookmarks about Scalability

October 25, 2008 12:00 AM

Leave a Comment

(required) 
(optional)
(required) 
Submit

This Blog

Syndication

Web Presence
Any comments or statements made herein do not necessarily reflect those of Charteris plc.
© 2006-2007 Charteris plc.