challenges.Rmd

# Planning Ahead {#planning}

## Working with a "long-term" mindset

> "Rome ne fut pas faite toute en un jour"

French proverb

### Prepare for success

-> Planning is everything 

-> Get ready for complexity

-> Think big, act small. 
Understand the big picture, but implement one small feature at a time.

-> Future is now

### Applying the KISS principle

> The KISS principle states that most systems work best if they are kept simple rather than made complicated; therefore, simplicity should be a key goal in design, and unnecessary complexity should be avoided.

`r right_link("KISS principle", "https://en.wikipedia.org/wiki/KISS_principle")`

Deeply rooted in the [Unix Philosophy](http://www.catb.org/~esr/writings/taoup/html/ch01s07.html), the KISS principle stands for "Keep It Simple, Stupid".

The story behind this principle is supposed to be that Kelly Johnson, lead engineer at the Lockheed Skunk Works, gave his workers a set of very common tools and said that the airplanes should be repairable with these tools, and these tools only. 
The idea behind being, that the action of repairing the aircrafts that come out of their factories should be possible to carry out by the average engineer. 

KISS will: 

-> Help you reason about the app in the long run, since it is  

-> Hard to remove a feature once it's implemented

### Think long-term maintenance, now

Maintenance, on the other hand, is something to think about from the beginning.  
It includes being able to ensure that the application will work in the long run, and that new features can be easily implemented. 

+ Working in the long run: separate the code containing the "business logic" (aka the data manipulation and the algorithms, which can work outside the context of the app) from the code building the application. 
That way, you can write regression tests for these functions to ensure they are stable. 
+ Implement new elements: as we are working with modules, it's easy to insert new elements inside the global application. 


## Working as a team: tools & organisation

Big Shiny Apps usually mean that several people will work on the application. 
For example, at ThinkR, 3 to 4 people usually work on the application. 
So, how do we organize that?

### From the tools point of view: 

+ Use version control (not sure I have to expand on that topic ;) )
+ Think of your shiny app as a tree, and divide it as much as possible into little pieces. 
Then, create one Shiny module piece by piece. 
This allows you to split the work, and also to have smaller files — it's easier to work on 20 files of 200 lines than on one big app.R file. 

### From the organisational point of view

 + Define one person to be in charge of having the big picture of the app. 
 This person will kick off the project, and write the skeleton of the app, with a good module and files structure. 
 This person will also be in charge of accepting new merge requests from other developers, and to orchestrate the master and dev branches. 
+ List the tasks, and open one issue for each task on your version control system. 
Each issue will be solved in a separate branch. 
+ Finally, assign one module to one developer — if it seems that working on one module is a two-person job, divide again into two other submodules. 
This is a relatively complex task, as the output of one module influences the input of another, so be sure to assign them well.