<commit_before>---
layout: post
title:  "Stress driven development"
date:   2014-08-01 10:58:44
categories: blog
---

_NB: this post is factitious and should be taken lightly._

Grady Booch wrote about this [a long time ago](http://web.archive.org/web/20050203010041/http://www.manamplified.org/archives/000203.html). It was written as a response to __Test Driven Development__ (TDD). A jest-ful post, but also serious, discussing the importance of accepting that some decisions have to be made before any steps can be taken.

_And that these steps were stressful and important._
<commit_msg>First blog on stress driven development<commit_after>---
layout: post
title:  "Stress driven development"
date:   2014-08-01 10:58:44
categories: blog
---

<NAME>ooch wrote about this [a long time ago](http://web.archive.org/web/20050203010041/http://www.manamplified.org/archives/000203.html). It was written as a response to __Test Driven Development__ (TDD). He spoke about architecture decisions, language choices, and library choices. He talked of the importance of prototyping your system, stress testing alpha builds, and making decisions on scale vs power early on and throughout the lifecycle.

If you are moving to _Service Orientated Architecture_ and _Micro Architecture_ you need to have your infrastructure at the forefront.

 - _How much traffic do you need to handle now?_
 - _How much traffic do you expect in a __X__ period?_
 - _How do you want to scale your infrasctructure?_
 - _How important is latency?_
 - _How important is data integrity?_
 - _Have you used that __database__/__messaging queue__/__etc__ service before?_
 - _How quickly can you prototype/alpha the infrastructure?_
 - _How will you stress test the instrastructure?_

We don't want to over-engineer at this point, but we do want to understand requirements and growth projections.

That three server setup might work for half a year until traffic explodes; can we add extra ones easily? Traffic might spike, can we drop servers when traffic drops?

Throughout all of this the underlying applications need to know what can happen on a infrastructure level. Will data _ALWAYS_ make it through? Can the application flow break halfway, how can my application find out?

Having answers, or agreeing to provide numbers to requirements/questions early on in a project will provide safety nets and clear watches on dangers before they hit.

Stress drive out your infrastructure as you test drive out the applications. Have the experience of these pass onto the future projects. Nothing is set in stone, and errors will occur but identifying the bottleneck/danger zones will enable safer, cleaner programming and infrastructure management.

[Simulate network partitions in DBs](https://github.com/aphyr/jepsen)
[Load test functional behaviour and measure performance](http://jmeter.apache.org/)
{'fraction_non_alphanumeric': 0.0565050575514475, 'fraction_numerical': 0.023718172305545866, 'mean_word_length': 4.634577603143418, 'pattern_counts': {'":': 0, '<': 4, '<?xml version=': 0, '>': 4, 'https://': 1, 'lorem ipsum': 0, 'www.': 2, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 2, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '3105562', 'n_tokens_mistral': 779, 'n_tokens_neox': 705, 'n_words': 388}