You can also find me on Linked In and assorted other electronic places, including these blog posts.
These days, I work closely with Spitfire Management on Project Management software for the construction (A/E/C) industry. The software is truly a culmination of everything I’ve have worked on over the years. It is fully role-based and configurable at the field level. It is extensible and interoperable via Web Services. It is web-deployed, but manages a fairly rich HTLM5 user interface that takes care of project tracking and coordination including Document Control, Document Management, Workflow Scripts, Routing, Compliance tracking, Alerts and Notifications, Contract Management, and Change Management. This construction project management software system has been deployed by owners, property developers, construction managers, design build and general contractors as well as specialty subcontractors.
Microsoft certifies that I know SQL, so you know it must be true (or at least that I am skilled at taking exams). Seriously, I love data and working with data just comes naturally to me. Over the years as the industry has moved towards smaller IT shops and virtual deployment, I have tried to remove as much of the burden of maintaining a fine-tuned SQL database as possible. One such example is automatic index optimization.
It isn’t just SQL, though. Deploying technology requires an eye on the big picture and quite often getting more done with less, or at least as few resources as possible. Few understand why I harp on single instance storage (AKA data deduplication). Even Microsoft has removed the feature from its Exchange storage engine. But in my mind, as we accumulate more and more storage and understand that it is organized by reference and relationship, it becomes critical for software to take responsibility and not waste storage. Even in its abundance and cheapness, storage is a resource that carries an ongoing cost. Even on AWS.
In fact, AWS is amazing. AWS includes such a breath of features and capabilities, it almost makes it fun to deploy new instances of servers and IT infrastructure. The fun thing is that we built archiving in the Spitfire Project Management System the way we did because different storage devices have different cost and performance characteristics. Very few clients have large enough IT shops to take advantage of that great design – but on AWS, you can deploy production OLTP data on SSD, SQL Logs onto IOPS volumes and read only archived catalog data onto cheaper volumes. That is just one of the reasons I recommend AWS and help clients deploy there.
When possible, I try to leverage best-of-breed solutions rather than build my own. Spitfire’s template engine is amazingly powerful, and it deploys easily because it uses Microsoft Word files. In 2014, we realized that the sfPMS file catalog, even with its version tracking and office integration would never keep up with cloud storage accessibility from the likes of BOX, Google Drive and Microsoft OneDrive (and the others). Instead of spending valuable resources trying to keep up, we embraced a cooperative, connected plan, teaming up with Cloud Elements and synchronizing the Spitfire Project Management Catalog with cloud storage.
So, sometimes we need to write code to do cool new things. Since I’ve programmed in assembly, FORTRAN, PL/I, FoxPro, PHP, Pearl, C# and VB.NET and others, the language is irrelevant at this point. The complexity of the algorithm is irrelevant. We strive for data driven design and flexible rule-based logic that has testing built in. Reusable code, that lasts.
Still reading? With luck, this has given you a sense of my pragmatic approach as a technologist. Lets talk!