- Phoenix project
- Principles of Development
- What is critical
- General best practices
- Industry stats
- Principles
- When you have bigger teams
- Key questions
- Process
- CI/CD
- Testing
- Documentation & Release Notes
- Support Tickets
- Roles
- Remote working best practices
- Team Management
Phoenix project
Principles of Development
- Locality and Simplicity
- Focus, flow and joy
- Improvement of daily work
- Psychological safety
- Customer focus
What is critical
- Release notes to our customers
- Standardised dev environments
General best practices
- Every developer uses a common build environment
- Every developer is supported by a continuous build and integration system
- Everyone can run their code in production-like environments
- Automated test suites are built to replace manual testing
- Architecture is decoupled to liberate features teams so developers can deliver value independently
- When something goes wrong, we ask “what” caused the problem, not “who”?
- Developers should write their own automated tests and check them in
- All code check-ins should come with automated tests. Write automated tests as they write the feature, not afterward.
- Automated tests should be done on every check-in of the code
- CEO writes the whitepaper himself. If you can write clearly, you can think clearly. If you can think clearly, you can speak clearly.
- Choose security over features
- Choose developer productivity over features
Industry stats
- Ratio of designers to developers is 1:6 today (not 1:70 previously) because it is important to create products that people love.
- Product manager translates functional requirements to development specifications.
Principles
- Ruthless pursuit of perfection
- Urgency to achieve the mission
- Constant dis-satisfaction with the status quo
- Zeal for helping the customers
When you have bigger teams
- Write blog posts on Redditt or Quora - this helps notice developers
- Provide flexibility - give them 10% of their time to work on something they like
- Do something on Github - allow some code to be used by 3rd parties
- £1K dev budget to do what you like
- Monthly hackathons
- Get the team to do the coding tests (and PI) so you can compare whether your bar for recruiting is high
Key questions
- What is the best way to setup tool to automatically generate documentation?
- What does it involve to automate functional testing? Will tools like Selenium help in our context?
- How do we best create a Support knowledge base (internal and external facing)?
- Are we going to follow Agile/Scrum or Kanban in terms of the methodology? What is more appropriate for MetaBroadcast? If we are following Scrum, I’d like us to find a way to measure the teams performance and velocity. Also, how do we
- How do you deal with un-ending backlogs? The risk is that items lower down the backlog will never get looked at.
- How do we implement functional programming principles ie. the results are always the same for the same parameters. “Immutability” principle?
- Are there any major security gaps we need to close?
- In practical terms, what are the actions to implement CI/CD?
- Can we understand diagrammatically how we deploy code? Something along these lines
- What profiling test tools do we need? Java Flight Recorder, JProfiler or Yorkit?
- How do we get our teams to be most productive i.e. what is the operating rhythm?
- Happy hour / engineering happy hours
- Slack vs email
- Distractions on slack - how to do deep work?
Process
CI/CD
Testing
- Functional testing
- Developers should write their own automated tests
- Automated tests should be done on every check-in of the code i.e. write automated tests as they write the feature, not afterward.
- Integration testing - do we need to worry about this?
- Regression testing - do we need to worry about this?
- UAT testing?
- Any other types of testing we need to consider for MetaBroadcast?
Documentation & Release Notes
- Developers should document their software within the code as they write the code
- This allows for Documentation to be automatically created
- Release notes should be generated from a subset of the documentation to share with our customers once a quarter
Support Tickets
- Resolution of each support ticket should be documented in a Knowledge Base Article. Articles can be either of these or both for a given issue:
- Internal articles - teaching how a non-technical user can troubleshoot and resolve the problem (potentially by running a script or looking at an interrogation tool)
- External - explaining to customer how to do something. This would be a unique public facing link (not searchable on Google) that can be shared
Roles
- Full-stack developer
- DevOps engineer
- UX engineer
- Support - team members are responsible for L1 or L2 support and can handle easier support tickets. If it is a software bug, it could escalate down to L3 support which can only be handled by the engineers.
- QA testing - there are two schools of thought.
- Developers should do their own testing and write their own test scripts and this makes them more accountable; if they have a separate QA team, the developers might become lazy.
- Developers should focus on writing code and leave the testing to an independent QA team who are unbiased and will find ways to break the solution
- Product manager - translates functional requirements to development specifications. Typically done the founder at very stages of a start-up. CTO for smaller companies. Dedicated Product manager for mid-sized companies.
- Pre-sales - sits on all customer calls, helps understand customer requirements and architect their solutions to build confidence. Puts together implementation costs based on work involved. Founder typically leads this in early stage start-ups. CTO for smaller companies. Dedicated pre-sales engineers for mid-sized companies.
- Solution architect - this role can overlap with the pre-sales role and has largely the same responsibilities as a pre-sales.
- Scrum master - helps the team enhance and streamline the processes by which they achieve their goals. They do so as a team member, or collaborator, ideally not as someone in control. The best scrum teams are self-organizing, and therefore don’t react well to top-down management. Again, small organisations don’t necessarily have a separate scrum master
- Project manager - scrum master’s non-technical counterpart. Unlikely for companies to need both a scrum master and a project manager.
Remote working best practices
- Every person in the organisation needs to be “touched” at least once a day - even if it is for 5 mins.
- Typical agenda: a) progress since yesterday, b) priorities for next day, c) roadblocks/areas where you need help
Team Management
- Is there / should there be allotted time for training per year per team member? Should that training be paid by company? Should it be relevant for the work performed at the company, or could it be certifications or the likes of that?
- Should we try and instil a culture that encourages failure over idleness?