#Issue25
3 posts

Hyperproductive development

Stop using any words that suggest anything is simple or obvious in all team communication. Write tests so people afraid of unintentional breakages can freely experiment with their ideas & contribute to the system.
Read more

Hyperproductive development

”Complex systems are easier to build than to figure out after they’re working.” - Valentino Braitenberg
  • This Law of Downhill Invention, Uphill Analysis starts becoming visible as development teams and projects start scaling.
  • The person who creates the system knows the ins & outs of it. They start assuming & expecting same level of knowledge of the system from everyone on the team.
  • First thing to ensure productive development environment is to accept the overhead that comes with larger teams. It is a tradeoff for scale.
  • Stop using any words that suggest anything is simple or obvious in all team communication.
  • Write tests so people afraid of unintentional breakages can freely experiment with their ideas & contribute to the system.
  • Try pair programming. It is one of the best ways of knowledge transfer about systems.
  • Make an exhaustive README document for developers on the team. Start this on day 1 when you start building any system.

Full post here, 5 mins read

When to automate a test

You should think of the most critical & complex flows that can be automated. When thinking of automating tests, take in account the cost of developing & maintaining automated test scripts.
Read more

When to automate a test

  • Automate unit test cases. Then move on to acceptance, integration & component level tests. Go for automated GUI testing only after creating an exhaustive test suite for the first two.
  • You should think of the most critical & complex flows that can be automated.
  • Automate regression cases at UI & API level.
  • Automate high-risk tests that check high priority & critical functions.
  • Automate data-driven testing. In this an automated test is parameterized and fed with data from a data source.
  • When thinking of automating tests, take in account the cost of developing & maintaining automated test scripts.

Full post here, 9 mins read

Taming the rate of change

Stability concerns amidst high change frequency is a new reality for us to accept and adapt to. During the normal course: Design & build for redundancy, Build pipelines to release safely & for rollback
Read more

Taming the rate of change

“Stability concerns amidst high change frequency is a new reality for us to accept and adapt to.” A suggested way improve production stability without sacrificing speed:

During the normal course

  • Design & build for redundancy
  • Build pipelines to release safely & for rollback
  • Do failover testing to validate system’s ability to move operations to back-up systems during any kind of server failure.

During an incident

  • Quickly review changes to isolate potential suspects
  • Rollback. If you can’t rollback, push a new fix.
  • If you can’t do that either, failover to a healthy copy.

After the incident

  • Do thorough postmortems & create list of follow up actions needed
  • Do a post-incident validation testing for your fixes in a mimicked failure scenario

Full post here, 11 mins read