Read on Twitter
I would like to call attention to some meta-issues I have observed over the last few years working in various software organizations.
Everything should be about ROI, and where it's backward, you are falling into social illness.
Everything should be about ROI, and where it's backward, you are falling into social illness.
The effort required to write a ticket should be lower than the effort required to resolve it.
This is frequently not the case, and the losses are so great, you can afford to track. A negative effort ratio in tickets demands a process change.
This is frequently not the case, and the losses are so great, you can afford to track. A negative effort ratio in tickets demands a process change.
The development cycle with managed environments such as stage or prod needs to be as fast as possible. We can measure:
A Engineer hours of effort
B DevOps hours of effort
C Hardware costs of CI/CD
If A isn't negligible, either DevOps is under-resourced, or priorities are wrong.
A Engineer hours of effort
B DevOps hours of effort
C Hardware costs of CI/CD
If A isn't negligible, either DevOps is under-resourced, or priorities are wrong.
Build times are a cost center, people waiting is pure overhead. And it's repeated, so each second you shave off your build time, you get back roughly
time-saved x dev-salary x devs x builds-average
If builds are unreliable for _any_ reason, that 2x the cost of builds times.
time-saved x dev-salary x devs x builds-average
If builds are unreliable for _any_ reason, that 2x the cost of builds times.
Engineering and QA should be the same team. QA and Product should be the same team.
Product is the legislature, QA is the judiciary.
Engineers should never have to navigate conflicting definitions. QA should override the word of Product until Product changes the design.
Product is the legislature, QA is the judiciary.
Engineers should never have to navigate conflicting definitions. QA should override the word of Product until Product changes the design.
QA sessions should be done with the authoring engineer, live. High bandwidth communication between QA and the Engineer cuts out costly ticket writing, emails, etc. Often the Engineer will know the problem and can PR mid-call.
Feature acceptance occurs when no bugs are found.
Feature acceptance occurs when no bugs are found.
With any feature of significant complexity, each engineer will have a different expected implementation and expect all the others to share this exact expectation.
This can be resolved by having a feature kickoff call, and having each person state how the feature will work.
This can be resolved by having a feature kickoff call, and having each person state how the feature will work.
Engineers should not be validating features locally. Local development, yes, but not validation. Rapid deployment from local to shared environments is key for efficient debugging cycles during validation. QA should never be the first person to observe code in a shared environment
Remote work is a great step in the right direction for productivity, letting people work at night would be even better. The return on investment from office equipment isn't removed by remote work. You can keep this effect by funding people's home offices.
Access and permissions should be standardized. Once one engineer has to ask for access to a certain database (for example), access should be added to the permission model for that team, so that other's don't need to make duplicate requests.
On-boarding becomes a breeze.
On-boarding becomes a breeze.
"Living documents" of useful commands need to be scripts with a test suite. Scripts will get stale without tests, but never as stale as a README file. These tests should run using the standard provided development package set for the project.
Git hygiene has a negative ROI. The time required for good git hygiene is hours per week.
The time cost savings in a bisect/debugging scenario is at-most hours per year. It's better to have an extra day of pain bisecting, than waste weeks keeping git clean.
The time cost savings in a bisect/debugging scenario is at-most hours per year. It's better to have an extra day of pain bisecting, than waste weeks keeping git clean.
Much of our software culture is built around accepting limitations, and lack of innovation in version control. We wish to organize changes with the reason for these changes.
We never get to re-organize, mostly because it would be painful, that's unacceptable.
We never get to re-organize, mostly because it would be painful, that's unacceptable.
Starting work on an unfamiliar feature should start with a 30 minute pair programming session with an engineer who is familiar with the feature. The communication that happens here cuts out hours lost in discovery.
A comment in a code review is of positive value if
- Addressing it is required for the correct operation of the program.
- The future time savings of the change, is greater than the time lost writing the comment, addressing it, and confirming it's been addressed.
Otherwise
- Addressing it is required for the correct operation of the program.
- The future time savings of the change, is greater than the time lost writing the comment, addressing it, and confirming it's been addressed.
Otherwise
Minor notes in a code review are better and more precisely expressed as an PR to the author's branch.
Changes can be accepted instantly, and we cut out the cost of the negative value comment. If it feels like too much work to make an PR, it was too minor for you to request.
Changes can be accepted instantly, and we cut out the cost of the negative value comment. If it feels like too much work to make an PR, it was too minor for you to request.
