Brian Noyle
Senior Software Architect
Background
Originally trained as a global change biologist and tundra botanist, Brian has nearly 10 years experience as GIS software developer and architect.
While Brian is primarily .NET and ESRI focused, he also has done a significant amount of work in the OGC realm as well as encouraging the use of smaller GIS toolsets and vendors where possible. His professional and technical interests are primarily focused on moving clients toward more standard architecture and development practices and patterns to facilitate a closer integration of GIS with the standard IT enterprise. Brian has extensive experience in full software lifecycle management with a focus on delivering through agile project management methods.
When he's not in the office, Brian can be found on his mountain bike, picking a bluegrass lick on the guitar, or standing in a river waving a stick.
Philosophy
Smile, this is fun!
Life is simply too short to spend one's time laboring in a job that isn't enjoyable. I left a rewarding training as a botanist behind to work in bits and bytes everyday because I love what we do here at DTS. Addressing your business problem, solving your programming enigma, or modeling your schema challenges with the latest and greatest technologies gets me out of bed in the morning and is tremendously rewarding. Being a team of "doers" means buckling down on tough technical issues, finding novel solutions, and avoiding negativity.
It isn't done until it's tested
Having been around the "final signoff" block a time or two, it has become apparent to me that automated unit testing, and test driven development (TDD) more specifically, is the single greatest tool the developer can use to guarantee that the team ships quality. Testing (whether unit or functional) should never be an afterthought to be conducted once all the code is written. It is an integral and iterative part of our day to day operations. Embracing unit testing and/or TDD practices has a dramatic and simplifying effect on the code base and architecture of an application, keeping things as simple as possible and ensuring a high quality product that behaves as expected, and handles exception scenarios and corner cases gracefully.
Don't write that code
Sounds odd coming from a developer. A mantra I have frequently been reminded of and have taken to heart is that the most valuable line of code is the line you never write. It costs nothing to produce, nothing to unit test, nothing to functional test, and will never result in unintended bugs. Don't write it until you need it and your software will be vastly simplified at both the code and functional levels.
