“How the perception of quality of software is affected
by other merits than core technical features and the code”

– sales techniques
– initial approach and product presentation
– management of customer expectations
– matching the sales process and its promises with operations
– simple and effective communications in presenting solutions

Software in-line documents: comments lines

Some of the g2g communication is within source code comment lines.

– comments being to the point: don’t blabber
– aim your comments covering 2-10% of total line count (SLOCs)
– comment contents should be useful for developer or other stakeholder (designers, users involved in customizing)
– positive points: score by checking your commentary is not bloated, repetitive, unnecessary

Quality of the payload code

– linted with appropriate tool
– advanced: metrics with SonarQube or other dashboarding tools
– make sure there’s really an active process to make sure code stays well maintained / “hygienic”
– don’t fall to the “just letting metrics be”, do TAKE ACTION. Let my experience speak: technical debt never goes down automatically.
– scanning using programmatic methods
– human perception of the code: ask your colleague for code review
– self-explanatory, or perceived throught architectural documentation?

– in open-source projects, code quality comes in 2 senses:
– the actual code (payload)
– comments
– other possible artefacts that are in the repository

Do code Commit patterns matter?

– commit pattern means the temporal distribution of developer’s effort
– a commit means “uploading” to the central repository part of new code
(or fix) from a developer’s computer
– does the client see and care about something in when and by whom the
‘git commits’ are done?
– there may not yet be actually any hard science on the research of commit
patterns and how they affect code quality
– different software corporations and/or teams might have conventions on this