Events Nov 13, 2018

Working with developers can be difficult and frustrating. The Partech Shaker hosted Le Wagon, a leading coding school, who gave us some very practical tips to building a solid technical product, getting your business off to a good start.

Are you a designer or an entrepreneur working with developers? Would you like to understand how it really works? Le Wagon has developed a 9-week training program to teach coding to anyone. By providing you with technical coding skills, Le Wagon helps you to overcome common communication issues between business and technical teams.

Context
By definition, a start-up doesn’t have a business model. The challenge for development teams is to define the best technical organization to enable fast action and optimize changes. There is no best method, you need to find the one that works for you.

Versioning
Your first step is to freeze code versions in time. If you don’t save your code regularly, you won’t be able to go backwards when issues occur. We all use tools like Dropbox to save files in Cloud. Developers use GitHub. This software development platform enables developers to share, collaborate and centralize coding information so that they can build better software.

How does it work? First thing to do is to create a “branch”: a timeline with regular saves as your projects progress. Each developer working on a specific functionality writes a branch. The objective is to be able to work alone on the functionality. When the functionality is complete, you then operate a “Pull Request”: you ask other developers to give you their feedback on your code. The idea is to have automatic feedback on each developer’s work. This not only generates reviews of your work but more importantly, you are not the only developer familiar with the code. If you work in silo, you won’t understand your colleagues’ code and vice versa. By systematically having your changes proofread by a third party, you streamline the code differentiation to the entire team. The idea is to avoid having only one referent for each functionality. When this process is complete, you can then merge.

Good branch practices:
- One branch per functionality rather than one branch per developer: create a branch for each new functionality
- Feature branch: several developers can collaborate on the same branch
- If a branch is too long, then you haven’t managed to cut the process into small enough pieces
- 2 sets of eyes: each coding branch should be reviewed by at least 2 developers, before merging. If you are the only developer in the company, you can request help from a senior freelance developer.

 

Let’s take a look at a practical case: A product manager reports a technical bug on a link, what should I do?
1 / create a branch and name it;
2 / work on the branch to identify the bug and correct it;
3 / save your changes = do the commit
4/ run a local test to check if your changes were successful, without breaking the whole code;
5/ if this works, send the changes to the server (send the branch via GitHub)
6 / make a “Pull request”: describe the issue and how you solved it, so that another developer can see what you have done and give you his/her feedback.

A Pull request review of 100 lines is efficient: any longer and developers won’t look at it as it is too fastidious; any shorter, they may question what you have done. Once this stage is complete, merge the pool request: you accept the changes and merge.

Deployment – This means sending the code to the server then to production. You can use a host Cloud such as HEROKU for this. Whenever HEROKU sees a change in GitHub, it deploys it into production. The merge button then becomes a ship button and the code goes into production.

Testing - To double-check, add an automatic testing phase. Tools such as TRAVIS look at branches, launch a test each time it identifies a new branch and then communicate the information on GitHub. Travis sends a message such as “I performed all the tests and didn’t find any issues”.

 

The main challenge for developers is not writing the functionality code but writing the code to test it. A developer needs to be able to check that his code is correct. How can you be sure that you have performed all the necessary tests? What should you test? An experienced developer knows what to test to anticipate any bugs: he has the “flair” for it. This comes with experience. Ideally, you need a test for each functionality. This is a lengthy process, but in the end, it saves time: it is a security net for the developers, to avoid stress about breaking the whole branch when you change something.

You should also run systematic tests on integration: the idea is to simulate user behavior on your website to make sure that the flow works seamlessly. Write a test code for any systematic action. If you work in a very early stage start-up, don’t launch any tests until you have stabilized your product.

 

The steps we have described are called the Continuous delivery method - Martin Fowler stated the following on how to judge the confidence of a developer team in its product: “The key test is that a business sponsor can request that the current development version of the software be deployed into production at a moment’s notice – and nobody bats an eyelid, yet alone panics.”

The advantages of this Continuous delivery method are: reduced deployment risks; real progress; user feedback.
If you break something, don’t panic: just go back to the previous version.

Monitoring - This is the final step to check that production will go well. Here, you can use tools such as Uptime Robot. With this tool, when something goes wrong on your website, you are notified before the user. This is key because if a user encounters an issue when navigating on your website, they won’t tell you. They will just use another site.

Advice from a developer
- Resist the temptation to Meta-work (avoid fixing a meeting to plan a meeting);
- Avoid meetings (when coding, developers require a high level of concentration and shouldn’t be interrupted);
- Write everything down (adopt a writing culture to facilitate communication);
- Embrace synchronicity (you don’t have to be physically present to get the information);
- Don’t pull developers from The Zone (coding is a very time-consuming process, so give your developers some objectives and let them work alone).

 

Potential toolkit for a more efficient production launch
Zapier, Typeform, MailChimp, Trello, Airtable, G Suite

 

Don't miss any of the Partech Shaker's events! Join our Meetup group here.