DEV Community

James Hickey
James Hickey

Posted on

What The #1 Thing That Affects Software Quality In Your Opinion?

Out of all coding practices, team management tools, project management tools, frameworks, development approaches, methodologies, etc. - what have you found to be the biggest contributor to quality software?

Discussion (21)

Collapse
pbouillon profile image
Pierre Bouillon

Communication

Communication alone can help to dismiss a lot of tension inside the team, unusable piece of software, spare time when stuck, etc.

Benefits are not endless but there is sure plenty of them !

Collapse
wchr profile image
Wachira

Documentation

Docs really increase the quality of your software because they provide a blueprint of everything your software does,roadmap and chronology of its development i.e.(story descriptions, PR messages, commits and wikis)

💯

Collapse
ericcheatham profile image
Eric Cheatham

+1000

I find that poorly documented code is poorly maintained and understood code.

Collapse
golangch profile image
Stefan Wuthrich

For sure well-organized ways of testing (which kind of testing is less important imho) and always having the big picture in mind when doing decisions. A bit with other words I wrote about some minutes ago here: dev.to/golangch/confession-how-i-g...

Collapse
rommik profile image
Roman Mikhailov • Edited

Indifference. (as in negative contributor to quality)

If the developer does not care for the code, no amount of communication, documentation, time, or even experience will solve it. Indifference is an outcome of toxic, political, and bad management environments. Teams/Companies that value input from VIPs instead of the subject matter experts. In a long run they end up with nightmare code, low skill, high burnout, and constant maintenance lifestyle.

Collapse
tchaflich profile image
Thomas C. Haflich

How much everybody involved cares about it being quality.

Giving a crap about quality won't make your product good, but not caring sure does increase the chances of it being bad.

If you take another answer mentioned - communication, say - more or less effort will be put into it based on how much either party cares. It's that effort (or lack of it) that is at the root of everything.

Caring about stuff tends to be a black hole, too. One or two people on a team who just flatly do not give a damn can drag everybody else down into apathy with them. Teams can get themselves into a culture death spiral this way. It's important to nip that in the bud before the product suffers.

Collapse
tanguyandreani profile image
Tanguy Andreani • Edited

Time. Especially for small / personal projects.

Collapse
phlash909 profile image
Phil Ashby

Yep. Time to re think the problem now you have a solution to explore it with. Time to refactor the ugly bits, or the architecture as a whole. Time to ask a colleague/friend/mentor. Time to learn a new technique or language feature or library that could help.

IMO this is the primary reason FOSS is generally better than commercial code (there are always exceptions - bite me!), it's had more time spent on it, although a close second is caring about quality in FOSS.

Collapse
dampee profile image
Damiaan

Was about to answer the same. But not only small projects but any project.

Collapse
tanguyandreani profile image
Tanguy Andreani

Right now I can only speak for small projects since I never worked on enterprise grade software.

Collapse
austinstanding profile image
Austin Standing

Communication, but I want to highlight a specific aspect--knowing why someone is asking for it. Understanding the context of the request will always help me with thinking through details of implementation, not to mention thinking of holes in the process I might be able to patch along the way. I also become more invested in fixing a problem if it's been demystified. It's hard to dance the dance if I don't hear the music.

Another consideration, is there a better way to do this? Is someone trying to create a solution for something they don't fully understand? Is it already handled elsewhere?

Collapse
mykeg profile image
MyKeg

Developers themselves.

Are they experienced?
Do they care about quality?
Do they put in the time needed, sometimes extra time, or do they stick to their 9-5 schedule?
Do they embrace learning new skills, tools, or do they reject it saying someone else owns that process?
When quality issues surface, do they always have an excuse about something somewhere else in the release process?
When quality issues surface, do other team members know how to debug/fix something, or is there just one SME on that team that has all the answers?

Collapse
amandaiaria profile image
Amanda Iaria

Communication and just wanting something better.

For instance, let's say you work in a VERY Legacy type of environment. An environment that doesn't want to try (hell even research) better ways of doing things. Like REST vs SOAP. Or just looking at how the American IRS runs.

One day your perfect code that may have been running for 20 years will break.

Collapse
mykeg profile image
MyKeg

With a critical bug that is preventing a customer from using the product, and the team is under pressure to fix it, and fixing it is the top priority for everyone involved (dev, test, release management, operations, support, account manager, etc.), and you make a change to hopefully fix it at 4:45 PM, do you stick around while testing takes place, or do you clock out at 5pm sharp and not look back until you come in the next morning?

Collapse
akhilaariyachandra profile image
Akhila Ariyachandra

Commitment to the project. Someone who is committed to the project know coding properly will save themselves time and effort in the future.

Collapse
brburzon profile image
Brandon Burzon

For me, I find that having a team culture that prioritizes quality over deadlines helps a lot in empowering developers to not take hacky shortcuts.

Collapse
n8chz profile image
Lorraine Lee

To me quality of software is nearly synonymous with robustness.

Collapse
veebuv profile image
Vaibhav Namburi

Quality defined by the engineering principles.

Is the company built around engineering or engineering built around the company