Structuring an Application

Some Thoughts

Topics

• VENDOR project goals

• Quick tour

• System architecture choices

• Mistakes

Project Goals

• Augment commercial tax assessment system with GIS tools

• Provide workflow management tools for clerks, appraisers, and GIS editors

• Minimize data entry and re-entry by plugging in 3rd

party data sources

• Be stable enough for commercial deployment to multiple tax districts

Delivered Components

Core Functions

VENDOR Toolkit

(VENDOR)

GEM Web Services

(Woolpert)

Supporting Products

GEM Workflow

Web

GIS Editor Tools

Edit Listener and

GEM2VENDOR services

Design Decisions

• Centralize business logic in model classes

• Model View Presenter for GUI applications

• Plug-in architecture for 3rd party data sources

• Push GIS code to framework wherever possible

– Mostly because of unfamiliarity of team

System Architecture Choices

• Separation

– Web stuff belongs in web projects

– GIS stuff belongs in GIS projects

– Etc.

• Reuse

– The model is what ties things together so attempt to centralize and reuse

Guiding Principle

• NEVER REPEAT YOURSELF!

– Handle GIS archiving/versioning in one place only

– Rule set for generating XML documents in one place only

– If we do something twice, automate and refactor

The Softer Side

• Mandatory phone meetings twice a week for 6 months

• Knowing who the client is: “product owner” vs. who can sign the acceptance

• Post deployment: client interactions via issue tracking web site

Tools

• I’m forgetful

– How to do something in SQL

– How to write that thingy in C#

– Which users to add to what group

– Which things are different on my PC vs. clients

• Tooling and automation is one way to avoid pitfalls

MSBuild

• Biggest discovery of 2008 for my productivity

• Makes even simple things easier in the short run with multiple developers

• Learned to isolate what is different on my machine than other machines

– Team members, client machine

MSBuild

• Really cool GUI

WIXWindows Installer XML

• Open sourced tool from Microsoft to create Microsoft Installers (MSI)

• Scriptable and can do anything, with a learning curve– Has nice extensions for AD, IIS, etc.

• Used to create documentation only on this project. See more use in future

WIXWindows Installer XML

Heat

• Generate initial XML stub from existing project

You

• Write your XML

Candle

• Transforms that in to MSI database

Light

• Builds the MSI from Candle output

WIXWindows Installer XML

• Example – Building documentation

GOOFS AND GAFFSWhen things went horribly wrong

Mistakes

• Being strict with structure led to unnecessary complexity

– a.k.a. I learned something in a peer review

– Even just with plethora of projects

• Staying on top of testing

– At some point I just let them slide for older code while adding more for new stuff

Suggestion

• Strive for “good enough” not perfection

– If it works as expected, it’s perfect to the client

• Perfection is in the eye of the beholder

– Does not mean you should not try to do a good job

– Resist the temptation to “make a quick improvement” – DONE == DONE!

Mistakes

• Not being rigorous with understanding the goal before starting work

– Very complex system, tons of business rules

– Became more successful through time because we began to do this

Suggestion

Use descriptive text and pictures to verify your assumptions with the client

Mistakes

• Not communicating enough

– Make a DB schema change which is not communicated

– Update a config setting which is not communicated

– Change method signature on web service which is not communicated

Suggestion

• You absolutely cannot communicate too much

• If you need time to get things done close your door, “Do Not Disturb” on IM, and block off calendar

• Otherwise…5 minute conversation now could save 1 hour later today.

WHAT IS YOUR EXPERIENCE? HOW HAVE YOU DONE IT?