“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)
– 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