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?
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (18)
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 !
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)
💯
+1000
I find that poorly documented code is poorly maintained and understood code.
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...
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.
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.
Time. Especially for small / personal projects.
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.
Was about to answer the same. But not only small projects but any project.
Right now I can only speak for small projects since I never worked on enterprise grade software.
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?
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?
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.
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?