Enterprise Code Reuse in the Real World

Tom HollanderMicrosoft ServicesSession Code: ARC303

Agenda

What is Code Reuse and why is it needed?Types of Code Reuse

Definitions, Technology Relationships, Code Generation, Approaches

Adoption StrategiesTop-Down vs. Bottom Up, Buy vs. Build

Lessons Learned and Case Studies

What Is Reusable Code?

A collection of supporting components, tools and processesDesigned for use across multiple applications, services or domainsCaptures proven practices for application developmentContains significant and valuable IPGrows and evolves with time and new technologies

Why Do We Need It?

Productivity – faster development and releaseQuality – repeatable, high quality applicationsConsistency – same approach and architecture Value – reduced cost for dev, deploy and opsAllows developers to concentrate on functionality, not supporting services

Patterns

Some History

PolymorphismEncapsulationSubclasses

Object Orientated

Location TransparentTight CouplingRuntime MetadataLimited Distribution

Message-basedContract + PolicyLoose CouplingBroad InteropThe ‘Cloud’

Component Orientated

ServiceOrientated

1980s 2000s +1990s

Code Generators

The Code Reuse ContinuumSc

enar

io A

gnos

tic

Sc

enar

io S

peci

fic

Base Platform Services

Reusable Components

Application Frameworks

Code Generation

Web Client Software Factory

.NET Framework

Composite UI App. Block

Enterprise Library

Mor

e Fl

exib

le

M

ore

Pres

crip

tive

Composition of Patterns & Frameworks

Model View Presenter

WinForms

CAB

SCSF

ASP.NET .NET CF

MCSF

Service Locator

IOC / Dependency

Injection

Prism

WPF / Silverlight

WCSF

Patt

ern

sTe

chnolo

gy

Fram

ew

ork

sTo

olin

g

Code Generation meets Code Reuse

Guiding principles:Code generation must achieve a satisfactory cost/benefit ratio.

The value of productivity gain must be offset by cost of developing and maintaining tools and templates.

Must be applicable across a range of scenarios, without needing to customise each timeCode generation should not result in unnecessary duplication of code.

Code Generation meets Code Reuse

Benefits (when done well):Simple conformance to architectureProductivity of devs by reducing repetitive tasksYour solution only contains the code you needIt’s just code so can be stepped into and debuggedImprovements can be implemented easily through code base by re-generating

When templates changeWhen inputs change

Code Generation meets Code Reuse

Drawbacks of code generation:Can be complex to manage toolsCatering for all possible scenarios can be more difficult than when building componentsGovernance model must be rigidly enforcedPoorly applied code gen can produce ‘bloatware’Getting the value prop right between generated and custom/reused code

Code Generation Approaches

Consume: Never manually edited and can be re-generated as required (even daily)Extend: Never manually edited, can be re-generated and extended through inheritance or partial-classesCustomise: Code that is generated as ‘pump primer’ for a particular problem. Generated once and then edited as needed. Never re-generatedThe trick is in determining where the line is between generated and custom code…

Code Generation Tools

Input (Front-end)Microsoft OfficeSQL Server schema

GeneratorMicrosoft Text Template Engine – T4Third Party and Custom tools

Management Visual StudioCommand-line tools

Top Down or Bottom Up?

Top DownDriven based on broad organisational needOwned and implemented by central guidance groupConsumed by individual project teams

Bottom UpDriven based on specific project/application needOwned and implemented by consumersMay be shared with other project teams or central guidance group

Top Down or Bottom Up?

Top Down is good for:Focus on Organisational needStrategic alignmentSingle maintenance model Enable all teams to be involved in its creationEnsures all support services are considered – training No ‘Point’ solutions

Top Down or Bottom Up?

But…One size does not fit allPowers that be are not “on the hook” for deliveryThe view from the Ivory Tower is different from the view from the groundGovernance model is tricky to get rightDifficult to adapt to speed of changeWho manages the migration and evolution?

Top Down or Bottom Up?

Bottom Up is good for:Minimising complexity and effort, by only building and using what a specific application needsMinimising randomisation of project teamsEncouraging technical innovation and agilityAssisting broader code reuse strategies through harvesting stuff proven to work

Top Down or Bottom Up?

But…Can result in multiple teams reinventing the wheel

...with varying degrees of successOrganisation-wide integration and interoperability can sufferAs can skills transfer and maintenance costsSometimes it is critical that things are done just one way

Top Down or Bottom Up?

So which is right?A pragmatic approach:

Enterprise Architecture focuses on certain key concerns

Platforms, Integration Patterns, Security Services, ...Frameworks and components to support these

Project teams given relative autonomy within these constraintsApproaches proven to be successful harvested and made available for other teamsAccept the fact that change is constant!

Buy or Build?

If you want some reusable code, you have two main options

“Buy” – Take some code that someone else has written

These days, usually Free*Microsoft, partners, ISVs, open source community

“Build” – Design, develop, test and support your own code.

Buy – Popular Options

Cross-Cutting Concerns – EntLib, Log4NetData Persistence – NHibernate, CSLA, Repository FactoryDependency Injection – Spring, Windsor, Unity Web UI Frameworks – ASP.NET MVC, WCSF, DotNetNuke, MonorailSmart Client Frameworks – CAB/SCSF, PrismUnit Testing Frameworks – Moq, RhinoMocks

3rd Party Considerations

Licenses – ongoing costs and implicationsSupport – vendor and communityDocumentation and Training – quality and concurrencyRoadmap – sustainable and supportedDependencies – desired and appropriateCompatibility – effective fit within organisation platform

Build – Roll Your Own

Sometimes the best (or only) optionMost common scenarios:

AuthorisationLegacy IntegrationService Discovery / Metadata RepositoryUI ControlsUI Composition

Build – Some Common Pitfalls

Not harvesting from proven practicesSolutions that are more complex than the problemCustom solutions to generic problemsDiverging too far from base platformForcing onto all apps without considering valueLock-in to an architectural approachExcessive ongoing maintenance and support costsNot spending enough time on usability, documentation and training

Choosing an Approach

Is it important for this to be done consistently across applications?Does a solution already exist?

Inside or outside our organisation?Designed for reuse, or built into a single app?Does it meet our technical requirements?Are the non-technical implications acceptable?

Do we have resources to:Build a new solution?Support the solution?Implement governance and training?

Case Study: Identifying the Issue

•ASP.NET User Interfaces

What’s the Scenario?

•Improve testability

What’s the Goal?

•In our last project we had too many regressions in the UI layer

Why is this goal

important?

Case Study: Identifying Candidates

•No

Can we harvest anything that has proven successful

in our org?

•Patterns: MVP, MVC

•Frameworks: Spring.NET

•Toolsets: WCSF

If not, what are some possible

solutions?

Case Study: Evaluating Candidates How does it work?

How does it meet the goal?

•Minor impact on developer productivity

What are the compromises?

•YesIs it compatible with other architectural

decisions?

IView

.ascx PresenterTest View

Test

Case Study: Moving Forward

•Integrate with authorisation framework

•Standard master pages with navigation

Are there any gaps we need to fill?

•Lunchtime presentations,

•Developer pairing

•Code reviews

How do we get our devs and testers

up to speed?

•Team retrospectives

•Bug counts

How do we measure the

success of the approach?

Take Away

Think where it can be best applied in your project or organisationAddress a specific problemPick an easy start – generate sprocs?Always harvest from proven practicesCreate feedback loop, collect IP and start again

question & answerTom Hollander

tomholl@microsoft.comhttp://blogs.msdn.com/tomholl

www.microsoft.com/teched

Sessions On-Demand & Community

http://microsoft.com/technet

Resources for IT Professionals

http://microsoft.com/msdn

Resources for Developers

www.microsoft.com/learning

Microsoft Certification & Training Resources

Resources

COMPLETE YOUR EVALUATION FORMS IN COMMNET AND BE IN TO WIN ONE OF THE 150 DAILY PRIZES*

GIVE US YOUR FEEDBACK & WIN INSTANTLY!

*For full terms & conditions and more information, please visit the CommNet Portal.

© 2009 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS,

IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.