icelava.net

why be normal?
Welcome to icelava.net Sign in | Help
in Search

Signs your colleague may not be a good developer #3

Last post 03-22-2009, 10:50 by icelava. 0 replies.
Sort Posts: Previous Next
  •  03-22-2009, 10:50 5530

    Signs your colleague may not be a good developer #3

    It has long been my suspicion, that many organisations do not permit their application source code to be copied out of their premises, not because of security or IP reasons, but to just save themselves from sheer embarassment.

    Honourary members of the court, allow me to present exhibit A

                }
              }
            }
          }
        }
      }
    }

    For obvious reasons, I am not allowed to expose more of the evidence. So let me fill in the details and explain that is at line 565 of a C# method. Yeap, seven levels of branching code logic. But wait, there's more! That is only half way through the method; it continues for some three hundred lines more. Seriously, this is not the first time I have had to deal with such labyrinths of code. I have seem worse in past projects. And I know I have also not seen the worst of technical debts yet. This has been a problem since the beginning of software development, and its recurrence to this day is still oh so common. Unfathomable.

    But you know what the real problem is? No matter how many times I deal with and fix such abhorring, criminal works, it has not gotten one bit easier for me to read and understand what were going on with the original programmers' minds. Messy complex code continues to remain messy complex code. Unlike the processes of nature, they do not erode and decompose into simpler substances over time. I am highly distressed that no matter how much I learn to write high-quality readable code, it does not help me to read rubbish code. Like what really can an expert chef do for rotten food. In the absence of original requirements documents, it is near impossible to figure what the code is trying to do, for what reason.

    If your colleague's toolbox only contains primitive implemnets of if-else, switch-case, nested for-loops for unending ArrayLists and DataSets, beware. It is safer to socialise with lepers. For such programmers produce ultra contamination that strike deeper than gamma rays can into your brain the moment you read their code and train of thought. Thoughts that never consider how to make this simpler and easier to read. Thoughts that do not figure how to slice the concerns and abstractions into bite-size chunks so they can be dealt with individually. How one slots and organises his/her thoughts is of critical importance.

    Just so, you know, that you may have to read the code again.

    Refactoring? Well let me inform there are more flaws to the logic and design than a couple of code rearrangements can fix. Therefore it still boils down to my die-hard opinion that interviews need to include some practical programming exercise so that candidates' programming styles and mentalities can be observed and assessed. When you hire hands to do work, you jolly well better test the very skills that pertain to the work that must be done. Would you hire a violin player without hearing him/her play?

    Filed under: ,
View as RSS news feed in XML
Powered by Community Server, by Telligent Systems