Home » work » management » Quality of the code – what it depends on?

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.

Advertisements

2 thoughts on “Quality of the code – what it depends on?

  1. First of all, I do not have enough experience to evaluate code, so I cannot tell if you deliver good code or bad, and that’s not what my comment is about :)

    I agree on you on the shit in – is shit out principle as you describe it. But I think in your conclusion you are mixing some things.

    If you have shitty specifications, should that relate to the output code? Does it mean a developer should not deliver good code, just because the specs are not to his standards? I think not.

    problems in the specifications –> delivered functionality might not be as wished
    problems in the technical specs –> problems with architecture not being suitable for the chosen solutions, technical problems like performance issues
    problems in the visual design –> ugly output

    problems in developers experience –> problems in the delivered code
    From a trained developer you can expect good quality code: documented, tested, working. Sure if the specs are not so good, it might not do what is wanted, but it should do what is specified and according to coding standards.

  2. Greetings, Tom

    First let me do a little disclaimer: this post was planned as a rough preliminary for a much more detailed one that’s not written yet because of zeitnot, so these aren’t really a conclusions (not a final ones at least), and practically nothing yes is explained/showed of what actually drawn me to this and other conclusions.
    Thus I’d prefer really not to discuss it here in depth before the final text I’m still planning to write will be finished and posted.
    So I’ll only make some brief remarks which possibly may make you interested in upcoming post.

    > problems in the specifications –> delivered functionality might not be as wished
    > problems in the technical specs –> problems with architecture not being suitable
    > for the chosen solutions, technical problems like performance issues
    > problems in the visual design –> ugly output
    > problems in developers experience –> problems in the delivered code
    That’s a nice clear separation, and I’d wish it would really be like this. But, unfortunately, when it comes to human factor simple and clear things mostly don’t work (not 100%).
    A good/ok specification saves developer an effort to “decode” what is it he has to create. And the developer that’s really good in software development will hardly be any good in such “humanitarian” thing as guessing someone’s expectations. On the other hand assigning a job to wrong specialist is a perfect way to dismotivate that person. An example: if you’d (theoretically) be hired by someone as a skilled project manager but was given tasks to do graphics and presentations instead of managing project/people, and your work would be estimated by how good the graphics look (not even represent the data thay should), yet at the same time any trouble with project/people would also automatically be your fault, wouldn’t this dismotivate you?
    Same thing here with developer – he should use some “watery” texts to “decode” what is it management wants to have, but at same time if the soft that was developed is not so good it still is his fault.

    Another important thing to notice is that developers nowadays rarely develop something on their own from beginning to the end. It’s usually teams of developers that work on some systems separated in some modules that should somehow interact with earch other. And thus if specification for one module is not good and as a result for that module “delivered functionality might not be as wished”, other parts of system get affected. And if the interaction between modules is not well specified it again affects all parts. Ofcourse, the result may not always be somethig that would be called a “bad code”. Rather a “bad architecture” etc, but will customer/management care for this “terminological” details in the end when they don’t get the desired result? For them the software is just “bad” and that’s it.

    Then, some parts of desired functionality may be plainly omitted in the spec, and may be added to spec after major part of system is ready and thus cannot be simply changed because of the dependencies of modules in the system. Thus this functionality may be added it not very “natural” way for the system.
    Again it may be called “bad architecture” not “bad code”, but again, who will care for these “therminological” details?

    Finally, if the specification may be quite “watery” sometimes it also may tend to specify too much details and “micromanage” the development (like having specified some particular algorithms or technologies to be used at some particular places, or similar things), which is almost an intrusion to a code itself, so here it is possible to create some bad code right in specification.

    As you can see, there may be many pitfalls here that are not clearly visible but yet, in my opinion, may have a very significant impact on the process and result of software development.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s