Todd Gill Info

TODD E. GILL

TECHNICAL ARCHITECT / DEVELOPER / CONSULTANT

Experienced technical architect, developer, team lead and consultant specializing in web applications and Salesforce.com development / integrations. Experienced with many languages and platforms. Able to communicate clearly with business stakeholders and technical resources to deliver high-value solutions as efficiently as possible given the context of the situation. Comfortable in client-facing roles and capable of leading a team or just implementing a solution on my own.

I provide hands-on support and guidance for most all phases of software development: application architecture/design, proof-of-concept development, automated test development (unit and integration test), server-side development, front-end development, deployment/release management. I also can set up the processes and tools necessary to support efficient, modern development teams and that support ongoing communication with business stakeholders.

While, I’m familiar with larger enterprise projects having multiple teams, I also understand the challenges and opportunities of SMB’s and startups. I am accustomed to risking my own capital and understand the importance of risk management and setting up favorable reward/risk (this is the job of business owners). I’m always looking for ways to create maximum value.

MY APPROACH

The information I’m sharing here is technical in nature, but there is much more to software development than keywords and acronyms. So, I thought it would be a good idea if I shared some of my thoughts regarding software development.

CLEAR COMMUNICATION IS REQUIRED FOR SUCCESS

After working with many different clients, with their different platforms, technologies, management styles and business models, I firmly believe that clear communication at all levels is the key to success in software development.

CONTEXT IS KING

After taking part in many different projects, I can usually determine how a development phase will end up based on the decision-making approaches taken by the development team and stakeholders. Decisions made for a software development project cannot be made in a vacuum! They must always be made based on the context of the situation. There are usually many feasible ways to build software solutions that meet stakeholder goals.

AVOID TECHNOLOGY DOGMA

Development teams should build solutions using the resources, platforms and tools that are available or required by the business, and not just the ones members of the development team prefer to use.
CLEAR EXPECTATIONS LEAD TO SUCCESS (AKA ‘USE THE RIGHT AMOUNT OF WORDS AND PRETTY PICTURES TO BE CLEAR WITH YOUR AUDIENCE’)

I believe that successful software development projects depend upon a shared understanding of project goals, time/budget constraints, business priorities and, of course, the successful management of a very large number of details. We don’t need to over-document like IBM, but everyone from project stakeholders to developers and QA testers need to use words and pictures to get the point across clearly to everyone else (with some key resources having the extra responsibility of translating between multiple groups)

TECHNOLOGIES CHANGE, BUT SOFTWARE DEVELOPMENT FUNDAMENTALS ENDURE.

MORE ABOUT MY EXPERIENCE

I have led and participated in many development teams, both on-site and remote. In addition to programming, I am experienced with multi-environment design, setup and configuration and with the associated complexities this brings to promotion and release.
I always promote the usage of collaboration tools so I and my teams can do just that, whether working remotely or in the same building. My clients have said they appreciate how I communicate complex issues and ideas between development team members and clients/stakeholders in a way that each group can understand.

PET PEEVES

When developers create a solution that does not take the rest of the system into consideration
When developers write code in order to say they did something at a scrum meeting
When project managers only ask “What did you do yesterday? What will you do tomorrow? Why isn’t it done yet?” without understanding the issues enough to facilitate a solution.
Uncontrolled deployments
When business does not budget for technical debt
When there are no proper written use cases to define what it is we’re building before we build it (I prefer Allistair Cockburn style use-cases)
When any resource has a profound inability to admit fault or accept responsibility. These are the people who always seem to be blaming and belittling others. They also tend to run businesses into the ground.
Over-documentation
Under-documentation
Over-simplifying a non-trivial task in order to justify short timeline or low budget
Micromanagement
Incompetence as expressed through arrogance and… incompetence!
Business leaders who think it is their job to “always be right” instead of focusing on facilitating and guiding the creation of value

HAPPY TO HAVE

Collaborative environment where competent professionals listen and share
Decision makers who understand and accept the limits of their own understanding
Useful documentation that accurately describes what it is the team is building together
People who can factor a problem down to its simplest requirements, but not simpler than it needs to be.
Competent resources WHO CAN COMMUNICATE WITH OTHERS CLEARLY VIA WRITING AND SPEAKING
Appropriate delegation to competent resources, as opposed to dumping tasks and avoiding responsibility
Business stakeholders who understand their job is “to manage risk while exposing the company to huge upside possibilities”.

SPECIALTIES AND ACRONYMS

System Architecture and Design
Proof of concept development for new applications, technologies, platforms, vendor services, etc.
Creating and supporting development and deployment/release management practices to support multiple environments (i.e. dev, test, stage, prod, etc.)
Creating custom integrations using ETL tools, custom tools, or some combination of the two
Expressing technical designs for technical resources using diagrams, use cases, assignable issue tracker work items, written text, proof-of-concept examples, web conferences or whatever else it takes to improve accuracy and efficiency
Legacy Applications – maintenance, updates, refactoring, upgrades and phased retirement
Salesforce.com Development: Force.com, Apex, triggers, unit/integration test code development, SOQL, etc. I currently hold the Salesforce Certified Platform Developer II and Salesforce Certified Platform Developer I credentials
Microsoft technologies: .NET, SQL Server, etc.
Python / Django
Shell scripting / automation
High Availability / High Traffic Production Web Sites
Dev Team Management
Deployment/Release Management
Requirements Documentation
Backlog development and grooming
Securing applications
Full stack development (multiple platforms / languages, polyglot)
Extensive experience with Microsoft technologies

Ability and willingness to:

Ask questions
Say “I don’t know”
Read the manual
Learn about new technologies that might help us reach our goals
Learn why a legacy system or legacy code was put in place before ripping it out and replacing it

Also, I will gladly configure JIRA (or whatever issue tracking tool is available) in a sensible manner to support efficient workflows if necessary. Heavily influenced by “Getting Things Done (GTD)” approach to task, calendar and reference item organization. When team collaboration tools (i.e. issue tracking software) is not understood and not used correctly, it is a hindrance to the entire business.

Feel free to download my resume for additional details.