Quality of the code – what it depends on?

Because of some “wierd” questions I’ve heared a few times during last months from some “young managers” I’ve been thinking about factors that affect quality of the program code “produced” by software developers, and about conditions that must be fullfilled to achieve good quality of program code.

I plan to return on this topic later in more details, but let’s start with some theses to have a start.

I believe that motivated* software developer may be looked at as some kind of “transformator” that transforms some inputs into a program code. And in this case (as in most cases that are conceptually similar) I find applicable the folklore “rule” (or saying) of sound engineers, which they say about the input audio signal processed and outputted: “shit in – shit out”. That’s it, 100% radical – if you have “shit” input signal no matter how good your DSP processors and sound effects are, you will still get “shit” in output.
(* – by being “motivated” I mean that no “organizational” questions like working place quality or low salary affects the developer’s will to do his work).

Fortunately for managers, humans are smarter than machines, so this rule is not 100% same with software developers – in some cases they may make good things out of shit inputs, but it may require some other resources (like time and/or additional motivation).

So, what the most important “inputs” for motivated software developer are?
One is definitely the skill of software developer himself, and also his experience with technologies used/required in current work. Another in the project/program/module requirements/specification.

More factors come into play when you have team of developers. This change is crucial from conceptual point of view because in case of teamwork it’s more beneficial to see the team itself as a “transformator” unit.
And even more factors add if there is a system architector that defines the system’s structure (and possibly also used technologies).

Communication and comprehensible feedback from testers/QA comes into play at the testing/bugfixing phase.

That’s it for now. To be continued… soon.