A reflection
Maurizio Lupo
Dealing with uncertainty
- start doing what you are sure of
- delaying decision point
- start with the user
Note: accept that things are going to change
What are the right priorities
Reprioritise tasks in order of certainty.
Delay all decisions that can be delayed
Short development iterations:
- refactor to introduce new feature
- introduce feature + test
- integrate
- ship
- goto 1
Note: Development iterations are not the same as product iterations.
I recommend super short iterations. (1 day)
rules:
every day you ship a working version of the software
never build more features then expected but keep the system open to add new features
The process requires that, when thinking how to go from A to B. You have to consider the journey, not only the final result.
"If you want to go fast, go alone. If you want to go far, go together."
Collaborate:
- resilience
- sharing and learning
- for sanity check
How?
- Pairing/Mobbing
- Show and tell
- Code reviews
Note: PRs with purpose (unsure, or needs validation, show and tell)
-
push to master otherwise
-
PR ARE A BLUNT TOOL FOR ENSURING CORRECTNESS
- never postpone
- the only "end-to-end tests" fallacy
- dumb tests are fine
- good code is easy to test
Note: Never postpone testing: test is supposed to help you, should not be a chore. Automated tests should save your time. But the only do so if you don't postpone them.
If testing is difficult consider changing the code or changing testing strategy/level.
100% test coverage is often the wrong goal
try to cover 1 obvious cases and the corner cases balance cost/convenience
Balance for acceptance and unit test: "I don't need to write unit test because I am experienced enough to write modular/testable code. Also testing the implementation may become an hindrance when refactoring. I only need to write acceptance test to ensure the correctness"
"Legacy software is any software where people are afraid to make changes”
Rajiv Prabhakar Note: If people are afraid, they are not refactoring and the code deteriorates. When this happen the development slows down considerably.
Tech debt
- only if necessary
- documented
- two types Note:
There are 2 types of tech debt. The first one can be addressed the first time you change the code (as soon as it is documented clearly). I suggest to move this in the project board, to be picked up when you do any change to the the project.
The second type takes more effort and time and requires planning ahead. You have to deal with this and agree a strategy with the PM.
“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live”
John Woods
Note:
Document:
- how (to run/to test/to use)
- why
- tradeoffs
- assumptions
Note:
- document your love for the next dev. document why, tradeoffs, assumptions, tech debt keep the documentation in the most obvious place and keep it up-to-date.
Break rules:
- Pragmatism over principles
- Understand why rule was in place
Don't be too clever
- Keep it simple
- "everybody does it" is no good reason
- explicit is better than implicit
- do not look too far ahead
Note:
- Vanilla is better (keep things simple and do not use fancy libs, unless necessary or very convenient)
- do things for a reason
- use functional paradygm with moderation
- use rest sensibly, graphql is probably not the solution you are looking for
- do not use nesting on sass. Except for namespacing
- do not use fancy transpilation or macros
- redux-form
Make a service observable:
- Monitoring, alerting
- Audit
- logs
- business metrics
- @sithmel
- maurizio.lupo@gmail.com