Build IT Right Conf
I was asked to speak about building Serverless systems at the first Build IT Right Conference in Newcastle back in April. It was daunting, but definitely a worthwhile challenge. I met some fantastic people and saw some great sessions during the day.
If you get the chance to attend next year, I’d definitely recommend it!
Luckily I had the good sense to make a few notes. For what it’s worth, here they are verbatim, cribbed from the github gist I made on the day:
ML in JS
Chris Price
tensorflow.js
ImageNet - image categorization
MobileNet is this but optimised for low-power devices.
- MobileNet
- ProseNet
- coco-ssd
- speech-commands
- toxicity
- universal-sentence-encoder
Maybe toxicity is a useful feature set to use as an automod?
Are speech commands useful to us? ‘Okay your-product…’
Why JS for ML?
ML with privacy baked in - keep user data on their device.
Uses WebGL to speed up all the computation
- sometimes means things crash b/c of poor resource management
Automate all the security
Robert Rees
“Security favours the large over the small”
Buy or build:
“How much team is this?”
Cost your team:
- Ballpark of £4-500 p/day
- Ballpark of £30-50k p/year
Benchmark
- Regular use $30 p/seat
- Daily use $40-50 p/seat
- Perfect case $5 p/seat
“Reduce all the infrastructure you maintain down to what is necessary to do what is unique to your domain”
Focus on your core value add!
Services
- Automated OWASP checks
- Free for ‘light’ public server scans
- Massively helps sales
When is the last time your backup was tested?
- Testing against UAT means that you have an opportunity to build and tear down an environment regularly
Headless browser automation testing
- CI/CD hub
- Performance monitoring
- Very expensive
AWS X-Ray and stuff like Mixpanel can be combined effectively to do the same thing.
- Security audit logging
- Useful in client conversations
- Strong integration into developer feedback loop
- GH marketplace
- Dependency scanning (for multiple langs)
- Configurable rules
- Provides complete audit trail
- Especially in PRs, reviews, comments, responses and updates
- This actually satisfies a bunch of 3rd party/client security issues
Lightning talks
Elm:
Model -> View -> Update
(The Elm Architecture)
Inspiration for Redux
So basically monoidal in nature (is that a word?)
Reactive, event driven framework at core of language (so opinionated development practice)
If car mechanics built software:
“The single biggest problem in communication is the illusion that it has taken place”
George Bernard Shaw
- Use week zero wisely
- Get tooling in place first
- A tidy workshop is a happy workshop
- Buy in what you can
- Quality is more important than quantity
Buy in auth
- It’s critical to get right
- It’s not your core business problem
- Usernames and passwords aren’t working so well
- Data breaches and password leaks
Tam Mageean
“When an agile transformation starts with a revolution, it tends to end with one”
Panel Session
How do you build the right thing?
- making sure the team stays flexible
- being willing to throw stuff away
- build around user needs
- don’t develop anything until you have a robust sense of requirements
- become better at building things:
- get buy-in from the top, not just bottom-up
- the organisation needs to believe in the changes that need to be made
What do you think is the most important thing for your team in the next year?
- doing more fun things:
- hackathons, especially cross-disciplinary ones
- tech for good
- work outside of day-to-day delivery
- “these exercises help drive innovation”
- service design, not just systems design
- interdisciplinary working
- speed up iteration (pairing across disciplines)
Next ‘big’/important thing in software?
- not an innovation as such but:
- in govt, accessibility is now mandated
- in large orgs, they’re starting to move to accessibility as standard practice (even if it’s not mandated)
- lots more automation (“automate everything”)
- it hopefully will free up time to focus on other things
How do you separate hype from promising new ideas?
- common sense
- what applies to the teams and projects you’re working on?
- do what works for your team
- do what meets user needs
- what do you need?
- what’s your budget?
- what applies to the teams and projects you’re working on?
- try them and evaluate whether they’re useful or not
- meetups and other people
- trial and error
“It’s daunting how much tech is out there…”
The Personalised Century
Timandra Harkness
“What we thought of as a public space is in fact a private space.”
(The internet)
I’m Here For An Argument - Conflict in Agile Teams
Stephen Mounsey
Productive disagreement
Don’t value winning an argument over finding a solution.
For good ideas and true innovation, you need human interaction, conflict, argument, debate.
Margaret Heffernan
Fear of conflict leads to artificial harmony.
Psychological safety was what Google found on their most successful teams.
How do we manage conflict so that it’s not mutually exclusive with psychological safety?
“Agile means conflict”
- Say clearly what you do want
- Say clearly what you don’t want
“Fist of five”
- get people to vote on ideas with fingers from one hand (1-5)
- everybody has to be over a 3 to proceed
Retros:
- 3 positives about people on the team
- 1 negative, with the prompt, “At your kindest, how would you help this person to improve”
- get a box of sweets, have each person go round and give a sweet to a colleague and thank them for something
Architecture for Developers
Simon Brown
“Big Design up front is dumb. Doing no design up front is even dumber.”
Dave Thomas
Answer two basic questions about what you draw up when you do up-front design:
- is that what we’re going to build?
- is that going to work?
Architecture
Includes…
- programming language
- technologies and platforms
- monolith, microservices or hybrid approach
Design
Implementation
- coding style
Process
Identify and mitigate your highest priority risks.
This front-loads the riskier decisions you make to the start of your project lifecycle.
Identify risk collaboratively and visually.
“Risk storming”
Concrete experiment
- poc
- spike
- etc
Provides starting point and direction.
“Thinking about software architecture lets you stack the odds of success in your favour.”
“Every team needs technical leadership”
(Every ‘software system’ needs technical leadership)
Architecture also includes:
- coding
- coaching
- collaboration
“It’s much easier to lead a team if you are a part of that team.”
“Good software architects are typically good software developers. Software architects should be master builders.”
“The people designing software must understand technology… all decisions involve trade-offs.”
“Teams need a ubiquitous language to communicate effectively.”
The primary use for diagrams and documentation is communication and learning.
Alex Lynham
Notes on working for a startup in Manchester and various other projects.
alex@lynh.am
