The Tale of a Consultant

As a consultant I am constantly being interviewed and am always asked the question, "Tell me a little about yourself and your background." No offense to the questioner but it is painful for me to repeat myself constantly. But it is his right to know who I am versus the other guy he spoke to so here I will describe myself briefly for the benefit of everyone.

I am programmer by hobby and profession. I have been coding since as long as I can remember. I remember bragging about my little cursor driven drawing program in 6th grade written in GWBasic. I went on to complete school and college with a Bachelor's degree in Computer Science and then a Master's in Computer Information Systems.

During my undergraduate studies I worked as an intern in a small startup called Quantum Software developing VB 6 code and small apps. There I began to understand the software lifecycle; requirements gathering, development, testing, deploying, etc. The whole nine yards. It was truly a learning experience and being in a startup it was a fast paced challenging environment.

After that, while I was in graduate school I was hired as a Lab Administrator. There my constant fiddling around with new technologies impressed my professor and we started playing around and writing papers together on some of the new stuff that was coming out in the early 2000s like XML, .NET, Web Services, Web Development Linux, etc. While I was doing that, I had gained enough Web Development skills that I started getting consulting projects to do different websites. That was the beginning of my consulting career.

Soon after I graduated I started consulting fulltime with different consulting companies. Working with numerous clients in various industries ranging from health care to energy and financial I was addicted to fast paced challenging work. My drive to always find a better way to do something, and trying to improve the code quality of a project often got me praises but sometimes lead to trouble. Being the one who cries fox does not always get you in good standing with your manager. Nevertheless, I never compromised on my basic principles of software development such as designing your code before writing it, finding ways of improving badly written code, and using proven industry standards, patterns and practices for common problems, etc.

My biggest example of that was at a large scale enterprise project project in one of the biggest energy companies in the world. I was a back-end developer writing service layer code and interacting heavily with NHibernate and the Database. Well into the project, major performance and development issues started appearing in the application. I began to see that my NHibernate calls and queries were getting harder to write and the data coming back was inconsistent and slower than what was expected. It was clear that working with a legacy database where the data requirements were constantly changing NHibernate was a poor choice for the data layer. I have written extensively in blogs and forums as to the problems I faced. I will summarize and say that the developers and BAs were extremely joyful when I wrote some code that directly utilized SQL queries and was able to populate the screens through the service layer. Furthermore, we had developed a little tool that would automate this process of building complex SQL queries and visually mapping them to regular business objects. The tool then generated all the painful ADO.NET code that no one wanted to write or see.

This caused a stir in the project management and architecture teams. Some were excited while others saw a potential threat. To say the least, me and my partner who helped me showcase the tool were relieved of our duties and went on to found our own start-up to build custom mapping and code generation tool.

Since then I have been in and out of consulting roles in Houston's leading energy and financial firms.

Throughout my career my focus has been on Architecture and good design with focus on code quality. I like to architect my projects and implement the code necessary to prove the architecture is working to solve the business need. I don't beleive in "plug and play" architecture where a number of open source or existing frameworks are mashed up to create an architecture that has all the latest technologies but does not meet the business challenges on hand. I also am not a fan of the "whiteboard" architects who always stay at a high level and are abstract about their designs leaving all the details to developers. They are unable to grasp the challenges a developer faces in solving the business problems and dont provide effective architectural solutions. I understand that communication is at the heart of a successful project. I have learnt that managing developers is a very tricky job where there is always a constant influx of ideas and creativity that is required to be harnessed and channelled into succesfully completing a project. Not appreciating a developer's creativity can lead to serious consequences. Creating processess and infrastructure to allow developers to produce their best work requires a great deal of effort. It requires establishing well defined and stable processes for source control, change management, testing, building, and deployment. Being hands on and being a leader by being an example for the rest of the team is the only form of leadership I believe in.

To conclude, I am an easy going guy, who is always very easy to talk to and loves technology. Software development and consulting is and has always been my passion.