Working with Developers 101

In order to help you get the most out of your time with our team, we’ve put together this short guide. This will include some of our processes, potential hurdles we’ll face, and answers to why we approach some topics the way we do.

Onboarding

  • You have a website or application that was previously managed by someone else
    •  First collect all necessary login information as well as any additional asset locations
  • You give us access to your system
    • Provide the login credentials to our team
    • We will start researching the system from the top down
    • This gives us an idea of how to approach any future problems
    • This initial research phase can take a great deal of time depending on how the systems are set up
  • Identify issues that are present in the system before we begin work
    • We will work with you to identify any problems that are present at the start of the business relationship
    • Many issues may not be obvious in the beginning
    • Using our systems, we can identify what existed before we started work or how long ago someone else worked on it
  • Project Creation
    • Based on the identified issues, or a list of changes you already want to make, we create Projects for each major request
Potential Hurdles
  • Unexpected issues
    • Sometimes, code can look like it is working from the outside, but once you are in the code you see that it only looks like it is functioning properly
  • This is like the check engine light in your car
    • The light might not light up when there is a major issue
    • If it has gone off, then something is wrong
    •  It could be a minor or major issue or affect other parts of the car 
  • Initial Research can take a long time
    • Depending on the complexity of the system, this can take a matter of days or weeks until the team has a firm understanding of the system as a whole

How a Project Starts

  • You have a request that requires a developer
    • You reach out and let us know what you need
  • A document is created that houses requirements of this update
    • This document is housed off of email so that we can all reference it later. 
    • This document forms the basis for the Scope
  • Developers are assigned to research
    • Developers will look into the code in question and determine the Level of Effort for the change
    • As the developer researches the issue, they will track their hours
  • An Estimate is created
    • Based on the research, an estimate of cost in hours and delivery date are sent
    • Once agreed upon with the client, the developers will start working the issue
  • Delivery of Update
    • Once all updates have been completed, they will go into testing
    • This may require deployment of a draft version of the update on what is called a Test server
    • After testing is complete, the update will be deployed to live servers
Potential Hurdles
  • Estimates are Estimates
    • If you go to a auto repair shop, you expect the Estimate to be close to what you pay in the end
    • Often, there are other problems that are only uncovered once work has started
    • Due to this, we as the developers reserve the right to decide what needs to be repaired to make the update
  • Hours are Hours
    • If a task takes more time to fix than originally estimated, then we will provide a clear reason for this in the form of a report
    • This is why we provide estimates and not final bills when we begin projects

Complex vs Simple Issues

  • Complexity can often be misleading
    • To a non-technical individual, everything can seem the same level of effort
    • Our expertise allows us to help you identify what is potentially a large or small project
    • Sometimes, even simple issues can be made complex by underlying problems
  • Examples of Simple issues:
    • Changing a picture
    • Changing text
    • Updating links
  • Complex Issues
    • Adding new features or functionality
    • Security Updates
    • Membership Portals
  • Rule of Thumb
    • The more moving parts it has, the more complex it is

Why Start with Research?

  • We begin every project with research in order to understand how to best implement your change
    • Systems are written in many architectures and languages
    • We have expertise to decode this into something we can work with
  • With research before hand, we can give a better overall estimate
    • Assign people with greatest knowledge in this language to reduce overall hours needed
  • Without Research
    • More surprises that will pop up, estimate will be less reliable
    • Less familiarity with the language is like sending an English speaker to another country

What is In Scope?

  • Scope is agreed upon in the beginning of a project
    • We try to make it simple to understand, but we can give greater detail
  • Moving Targets
    • If something needs to be changed to make a system function, then we will create a new estimate
    • Additional requests you think up later be added into a new project
  • As technology experts, we decide what may or may not be in scope