Gitlab

getting system

• Bad code === bad product
• Best code !== best product
• We should strive to construct high quality code
• Everyone who writes code is changing the product
• To maintain quality we should be aware of what changes are happening and why

A brief history lesson

Our historical approach to Software Development

1. Idea
2. Informal discussion
3. Make an asana task (maybe)
4. Immediately start implementing
5. Code deployed directly to prod
6. Fix it when it blows up

What's wrong with that?

Disparate sources of information

• Source of ideas coming from weird spreadsheets
• In-person discussions mostly undocumented
• Bug reports come via email or slack or zendesk or your mum
• Tasks live in Asana as one liners with little context

Ideation

• Idea/feature discussions happen with little/no record
• Human memory is bad, details are lost
• No singular source of truth
• Discussion has little chances for outside input
• Hard to audit or review past ideas and processes
• Good ideas that don't progress can be forgotten

Design

• Design discussions lack input from rest of team
• Ideas go to design with little UX discovery
• Designs could be biased/not informed by quant/qual data

Implementation

• Discussions lack team inclusion into creating the most effective solution
• Planning can be burdened on one person
• Plans not documented to be referenced later
• Lack of upfront planning makes it difficult to estimate time required
• Code goes live with little oversight
• Knowledge of systems gets centralised to the person who built it

Bug Tracking

• Bugs often reported but not recorded
• Reported bugs include "User said portfolio broken"
  What does that mean???
• Long standing bugs become "accepted" and never get fixed

How does this effect the product

• Lack of documentation on the "What? Why? How?" for future reference

• Valuable discussions on ideas get lost ("Why did we do that again?")

• Lack of planning/understanding creates inflexible solutions
  (tech debt, slowing down iteration speed)

• Rushed designs that either require reworking or we end up living with
  (design debt?)

• Downtime due to broken solutions deployed without review
  (Loss of new users and can turn off existing users)

• Lack of feedback for developers (No insight on what to improve next time)

• Bugs reaching users, some bugs having a long lifetime (Poor user experience)

   

Our lord and saviour
Gitlab

What is it?

• Source code version control (aka Bitbucket)
• Collaborative software development tool
• "It's a discussion about software"

How do we solve '''some''' of our problems with Gitlab?

You have issues

• The name isn't negative
• Think of them as a collaboration tool

What are issues for?

• Discussing the implementation of a new feature
• Submitting enhancement proposals
• Asking questions
• Reporting bugs and malfunctions
• Obtaining support
• Elaborating new code implementations

What happens if you don't make an issue first?

• I will find you
• You will make it hard to find or reference your work later
• There may be parts of the system you aren’t familiar with
• There may be limitations or possibilities you’re not aware of
• There may be factors for users you may not know
• There may be work going on in a parallel effort which relates your idea
• There may be future considerations or plans you're not aware of

Example lifecycle of a new feature issue

1. We identify a business problem/opportunity (Not enough users signing up)
2. We talk to customers and do user research
   (We find out we're missing dogecoin on the platform)
3. We discuss/brainstorm solutions and pick the best one
4. New feature issue created in Gitlab
5. We create a prototype to validate that our solution actually solves that problem (Richard creates simplywall.st/doge page mockup, gets Al's feedback on it)
6. We test the prototype and we see that users understand how to access the feature and find it attractive
7. Issue moves into the technical planning and Implementation phases
   (Possibly in a different related issue)

Example lifecycle of an enhancement issue

1. We identify or flag a technical problem or optimization
2. Discussion/brainstorm on possible solutions and pick the best approach
3. Planning/discussion on implementation strategy
4. Merge Request created
5. Implementation
6. Complete
7. Code reviewed and approved
8. Deployment

Example lifecycle of a bug issue

1. User reports a bug via Zendesk
   (Company news empty on ASX:TLS)
2. Marcelito investigates and creates bug report
   (Company news section empty for some companies)
3. Bug gets assigned or picked up
4. Discussion on approach or request for input
5. Merge request created in WIP mode
6. Work starts and commits are added
7. Work complete, WIP mode removed and approvers added
8. Approved/Denied

When not to make an Issue

• Typos/Corrections
• Small bugfixes with no bug report

Merge Requests

• If you're not writing code you don't need to care

• Used as the starting point for constructing code

• If you don't need an issue you start directly with a merge request

• Can operate similarly to Issues (contains similar collab tools)

• However more for final discussion of technical details

• Are for constructrive criticism or suggestions

• Final place for feedback and quality of code before it makes its way into the product

• Two eyes better than one

Typo/Correction/Small bug fix
MR workflow

1. Create MR with title, add description
2. Work starts
3. Fix commited
4. Approvers added
5. Merged/Denied

Overall workflow

1. Task, Feature or Bug is created as an Issue

2. Discussion (It works like a slack thread e.g. "@adamhejl should we make the doge logo 3d?")

3. Issue progresses to implementation stage

4. "Create merge request (MR)" from Issue to automatically create a working branch

5. MR is in Work In Progress (WIP) mode <-(Start here if skipping Issues)

6. Implementation & commits added

7. MR set as complete, reviewers assigned

8. MR is discussed if necessary

9. MR Approved & Merged

10. Deployed to production

Gitlab doesn't do everything

Gitlab doesn't do

• Generation of ideas (see Product Board) 
• Product direction (see Product Board)
• Proper documentation or company Wiki

Extra stuff it does do

• Milestones (groups of issues) 
• Issue boards (Like asana boards)
• Basic issue prioritisation (issue weights)
• Issue tagging
• Time tracking
• Review apps

Questions