Dev Cast - Lessons from a Complex Application

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

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 
Let’s look at an example

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

Example – Building documentation

Goofs and Gaffs
When 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?

http://dylandoesdigits.blogspot.com	54
http://dylandoesdigits.posterous.com	3
http://dylandoesdigits.blogspot.co.uk	2
http://www.slideshare.net	1
http://digits.transatlantical.me	1
http://posterous.com	1
http://www.google.com.mx	1
http://dylandoesdigits.blogspot.com.es	1

Dev Cast - Lessons from a Complex Application

by Dylan Thomas on Feb 09, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

8 Embeds 64

Statistics

Dev Cast - Lessons from a Complex Application — Presentation Transcript