Difference between revisions of "Is code quality **actually** important?"
From CitconWiki
Jump to navigationJump to search (Created page with "The context for the discussion was on quality vs. time-to-market === What is code quality? === * Peer reviews generally leads to good code quality ** https://en.wikipedia.org...") |
|||
Line 29: | Line 29: | ||
* Out of the 20 or so participants only three had clear vocabulary and process in place to distinguish between different kinds of work | * Out of the 20 or so participants only three had clear vocabulary and process in place to distinguish between different kinds of work | ||
** e.g. solution core work that needs high quality vs. a bet on a new low-risk feature, just to understand would it be used at all | ** e.g. solution core work that needs high quality vs. a bet on a new low-risk feature, just to understand would it be used at all | ||
+ | ** This makes code quality discussions difficult as likely all work following same standards |
Latest revision as of 22:21, 27 May 2024
The context for the discussion was on quality vs. time-to-market
What is code quality?
- Peer reviews generally leads to good code quality
- https://en.wikipedia.org/wiki/Broken_windows_theory
- Linters, style checkers etc. were considered hygiene and should be done by tools, not in a review
- Decoupling risks and architectural changes in reviews, e.g. fix risk now, ship, asses architecture as a next step or later
- At google you need one review from someone understanding the business logic/context and one review from someone certified as "language reader" for the implementation language
- "Code quality is not getting calls on a weekend"
Various business goals setting need for code quality
- Threads was originally just a stripped down instagram, the business goal was to win market share(?) with Twitter in turmoil.
- Code quality and other technical aspects were to be tackled later
- Solutions with actual usage care about their customer retention, customer lifetime value etc.
- Need for extendability and maintainability, while not upsetting existing users.
- One participant worked closely with a team creating valuable PoCs in three weeks, that were then handed over for maintenance and refinement for another team if the solution gets traction
- Open source
- Share solutions and crowdsource the evolution and maintenance
Other
- There is satisfaction in creating good quality code
- Programming languages likely to trend towards ways that enable AI code writing and reading
- Intermediate level language?
- Prediction that front-end development role gone in 10 years
- Cobol not generatable today?
- Out of the 20 or so participants only three had clear vocabulary and process in place to distinguish between different kinds of work
- e.g. solution core work that needs high quality vs. a bet on a new low-risk feature, just to understand would it be used at all
- This makes code quality discussions difficult as likely all work following same standards