Efficient Development page

Learn the tools and technology commonly used within a project.

Overview

After creating goals, and prioritizing the features that add the most value to your users, you might be ready to actually build something.

The goal of development is to support a product’s development. Limited to a technical perspective (given the right features), a good product is error free and high-performance.

Time and budget are always constraints on achieving this goal. So a good development process quickly and sustainably adds features. This is what we mean by efficient development.

The key/secret to efficient development is maintainability. Maintainability is how easily a codebase can respond to change. A highly maintainable app enables the most efficient development, which allows you to quickly improve the application, resulting in something that is error free, fast, has a better user experience, and adds more customer value.

This page is a list of characteristics of a maintainable application and team.

Checklist

Tools and environment (ops)

Required

Source control is:

Used

Git

Used with a branch and merge strategy.

An issue tracker is:

Used

Integrated with source control.

Used by non developers.

The following environments exist

Development

Test

Staging

Production

A 1-3 step process for the following exist:

Setting up a development environment

Testing the application.

Building the application into a production distributable.

Deploy to test and staging.

Continuous Integration:

Exists

Runs on all commits / pushes

Recommended

Portability:

Containerized microservices

  • The application self-documents the environment in which it runs. That documentation is widely known (Example: docker files)

Cloud Deployment:

The application is able to be started and stopped on new machines easily.

New machines are able to be created easily.

New machines are able to be created across multiple platforms.

Monitoring:

Vital app performance characteristics are measured (errors, CPU, Memory)

Errors (client and server side) are automatically emailed to team

Reporting:

Vital app performance characteristics are reported and analyzed every 1-6 weeks

Code quality

Required

Is the high level architecture documented and followed?

Yes No

Are there unit tests?

Yes No

Is there documentation for the code?

Yes No

All modules include:

High level documentation.

Tests

Inline documentation

A demo

Are there performance tests?

Yes No

The service layer is:

RESTful

Documented

Tested

Built / working

Recommended

Is technical debt measured? Is some value (often in days / weeks) of technical debt calculated?

Yes No

Is technical debt factored into estimates? Do estimations of time, or points, or effort include discussions of technical debt?

Yes No

Team

Recommended Is there a QA team or resource?

Yes No

Are teams grouped by specialty? Example: client vs. server

Yes No

Do you work alongside the client’s developers?

Yes No

Is every piece of code known to at least two people? No piece of code should be "workable" by only one person.

Yes No

There are code reviews:

Every commit

Every week

Every month

Of new people’s code

Never

Methodologies

The following are some common project management methodologies.

Scrum

Summary:

  • Work organized in sprints (~2-6 weeks)

Guides:

Kanban

Summary:

  • Task board where any engineer can take a job and complete it.
  • Continuous delivery

Guides:

Extreme Programming

Compared to Scrum:

  • Allows changes in sprints.
  • Work in strict priority order.
  • Prescribes engineering practices (TDD, automation, pair programming)

Versioning and Environment Workflows

This document describes the process of development workflows with respect to versioning software and application environments (dev, test, staging, prod). The specifics on your project should be documented in the Engagement Summary Document

  • Versioning Software: GitHub
  • Continuous Integration: TravisCI
  • Environments
    • Production - The production servers and databases users interact with.
    • Staging - An environment that matches production as closely as possible that is able to verify the next release is going to work as expected.
    • Development - An environment that allows developers to quickly show off new features or test their code in a near production environment.
  • Branches
    • master - Represents the features that will go onto staging.
    • {ISSUE_NUM}_FEATURE - A feature branch that is forked from master. When ready, it is merged into master
    • RELEASE-pre.X - A tagged version of master that will be pushed to Staging for testing. If successful, it will be tagged without -pre.X for released.
    • RELEASE - A release that will be pushed to Production.