In our first post in this series, we saw a typical conversation between a project manager and a developer over a “minor” change to a website. Even small and seemingly insignificant changes to require a significant amount of work. And every change made to a site impacts not only the site or software on the front end, but all the other systems that collaborate to make your website/software function properly.

So let’s take a look into the mind of a software developer and examine out exactly what effort goes into making software changes.

What’s Involved – The Development Process

Here are the highlights of the different phases of software development. Each can take as little as an hour or as long as a day or two, depending on the task at hand.

Planning and Discovery – A discussion, usually between the project manager and two or more developers, about what needs to be done and the difficulty involved.

Specifications – The developers determine the specifics of the update or change, how it impact the current structure of the software, and how all the elements should “behave” together. Take the example from our first post: Adding a gender field. The variables include:

• Field will have three choices (Male, Female, Prefer not to answer)
• Field is required.
• Field error message: “Oops.. your gender is required.”
• Info should be added to the users table in the database.
• Info should be displayed in the backend Content Management System (CMS)

Impact Analysis – The developers must answer the questions: What other systems will this impact? Do we need to make software updates to other systems?  Are there any reporting tools that need to be updated? Any automated scripts?  All of these elements add to the planning and development hours.

Infrastructure and Workflow – The developers then map out the work, determining the order in which the changes need. There is a front end website that relies on a back end database, and if the front end is modified before the database is in place it will break the system and no data will be gathered.

Source Control – Almost all websites and software should rely on source control systems, which allow developers to work simultaneously and not overwrite each other’s changes.  Source control tracks all updates and versions of software/website code so we can rollback to any point in time. In this stage we also identify a version number for this change (v1.0.12, 2.1.3, etc.).

Database Schema Design – What database elements are affected?  Who is responsible for making database changes?  Some organizations have Database Administrators (DBA) who are required to make all updates to the infrastructure via request forms that project managers fill out (sad but true—I’ve seen it). Now your simple website change depends on another employee’s resources.

Development – All this planning and we haven’t even done any development work yet. Crazy, right? But necessary. The development phase is where the actual coding takes place. The developer makes changes to the website according to the specs and workflow previously defined.

Pre-Deployment User Testing – The developer takes the time to test their work according to specifications. This ensures there are no errors and the product is ready for internal for internal QA and testing.

Deployment to Staging Environment – Developers use different environments to segregate their work from clients and the rest of the world. At this stage all code is in the developer (DEV) environment and we need to push all code to staging (STAGE) for internal testing and eventually client review. This also allows the developer to work in parallel and not affect and QA procedures.

Group Testing (QA) – Testing and Quality Assurance (QA) is the process of testing the product to make sure the behavior functions according to the specifications defined. This includes capture of user data in the backend database and, in the case of websites, making sure you test multiple browsers according to your audience’s browsing habits. Log all issues in a bug tracking system, make changes and updates accordingly and redeploy for further rounds of testing until all bugs and issues are resolved across all browsers and environments. Clearly necessary, and clearly time consuming.

Manager and Client Approval – Submit to the client for approval, receive (the very likely) comments and changes, make updates as needed and redeploy to staging until all issues are resolved.

Deployment to Production Environment – Move all changes to the production environment so the project is live for all to see. This involves packaging and tagging all files in source control, and deploying the code to the production server. Finally, the change is now LIVE.

Post Deployment Testing – Test the production site to ensure all files were deployed successfully and everything is functioning as expected.

Proceed/Rollback changes as needed – If there are any errors on your production environment, roll back the code to the previous release and fix the issue. Repeat “the Development Process” until production is functioning properly. If all checks and balances are observed then there should be no need to rollback.

Clearly, a small change to a site doesn’t translate into a “simple” development project. In our next and final post in the series, we’ll look at why seemingly minor changes have big impact, and why software developers are always wary of tackling “small” projects under tight deadlines.