Five Resolutions for the New Year

Five things Gazelle can improve on this year.

Transcript

1. Five Resolutions for the new year
3. Spread ideas
4. Spread ideas •Propose an idea
5. Spread ideas •Propose an idea •Share a new technology
6. Spread ideas •Propose an idea •Share a new technology • Teach a concept
8. Aggressively upgrade
9. Aggressively upgrade •Security
10. Aggressively upgrade •Security •New features and tools
11. Aggressively upgrade •Security •New features and tools • Availability of documentation
12. Aggressively upgrade •Security •New features and tools • Availability of documentation • Performance
14. Make deployment easy
15. Make deployment easy •Divorce environments from branches
16. Make deployment easy •Divorce environments from branches • Automate everything
17. Make deployment easy •Divorce environments from branches • Automate everything •Anyone can deploy
19. Curate tests
20. Curate tests •Write fast unit tests
21. Curate tests •Write fast unit tests •Defend against brittleness
22. Curate tests •Write fast unit tests •Defend against brittleness •Automate acceptance testing
24. Eliminate legacy code
25. Eliminate legacy code •Think about how it should work
26. Eliminate legacy code •Think about how it should work • Design with change in mind
27. Eliminate legacy code •Think about how it should work • Design with change in mind • Don't build more than what is needed
30. Five Resolutions for the new year Five things that I think engineering could get better at, that would allow us to be more efficient Some of this will be more ruby slanted since that's most of what I do
32. Spread ideas • This is the first instance of this in practice • DevTalks will be every other week on fridays starting at 1 • These are for everyone
33. Spread ideas •Propose an idea • There are plenty of dev concerns that will never be a requirement from an outside business person • This can be a platform for that • It also allows feedback to allow refinements
34. Spread ideas •Propose an idea •Share a new technology • There is a knowledge gap • Ask someone to share something you don't know
35. Spread ideas •Propose an idea •Share a new technology •Teach a concept • Shared vocabulary • Spread understanding of how to built maintainable software
37. Aggressively upgrade
38. Aggressively upgrade •Security
39. Aggressively upgrade •Security •New features and tools • Not built here • More productive
40. Aggressively upgrade •Security •New features and tools •Availability of documentation It can be hard to find documentation from 4 years ago
41. Aggressively upgrade •Security •New features and tools •Availability of documentation •Performance • What if there were one thing you could do, that would give you performance gains across your whole application?
43. Make deployment easy • Deploying our apps sucks • Releases are too inconsistent
44. Make deployment easy •Divorce environments from branches • It's dumb that I need to merge my code into backstage to deploy to the backstage environment • I should be able to deploy any branch into the backstage environment
45. Make deployment easy •Divorce environments from branches •Automate everything • We have per app automation • We need environment automation • I should be able to create as many backstage environments as I want • Version bumping too
46. Make deployment easy •Divorce environments from branches •Automate everything •Anyone can deploy • With the other two, this becomes easy • Having one expert in something is a bottleneck
48. Curate tests • Our tests aren't doing their job • They run too slow, so they get pushed off till later • Our feedback loop is too long, so issues go unnoticed for far longer • The later in the cycle you catch an issue, the more costly it is to fix
49. Curate tests •Write fast unit tests • These tests are for ensuring that you are writing now is working • They need to be fast (<5 seconds) • They should be unit tests (don't talk to the database or external systems) • Mock dependencies (More about this in another talk) • Unit tests inform on complexity of code. If it is hard to write tests for, it will probably be hard to maintain
50. Curate tests •Write fast unit tests •Defend against brittleness • Validate assumptions of code by explicitly stating them in the test • Time is an indeterminate function as far as you're concerned • Never use factory defaults for a field your code explicitly uses
51. Curate tests •Write fast unit tests •Defend against brittleness •Automate acceptance testing • We currently automate G3 • We have plenty of other systems that are 100% manual QA • Acceptance tests will catch the things unit tests and component tests don't • They ensure that the businesses goals are being met
53. Eliminate legacy code • What's make code legacy code? • The common answer is age, but I disagree • I think legacy code is any code that doesn't adequately reflect the goals of the business • Nobody wants to be a maintainer of legacy code
54. Eliminate legacy code •Think about how it should work • Often stuck in the mindset of “How can I get this cat to do a new trick?” • A better question is often “What kind of pet do I need to do this trick?”
55. Eliminate legacy code •Think about how it should work •Design with change in mind • Designing code that can't change easily means that when change is required, you become a maintainer of legacy code • Designing code that can change, allows the system to evolve with the business
56. Eliminate legacy code •Think about how it should work •Design with change in mind •Don't build more than what is needed • Code should be written to solve a problem • Building something that will never be needed or used is instantly legacy code • It also adds a burden, because it's hard to tell if code is used once it's in place. Which means people will be maintaining something that's never used. • It adds complexity that may never be necessary, such that someone must understand it • These apply to things done for performance as well
57. Do you have any ideas for things you want to get done this year?
58. Questions