« Back to blog

Makeovers

Roughly a month ago i was hard at work, against time time and energies to integrate a whole new set of changes in the services with the UI. It was crazy to put it mildly and it was one huge chunk and it was evolving everyday. The whole transition to the new changes took a new 5 days to come to stable grounds. After i was done, i left for a week long break. I knew that the changes would continue, even from where i left off. When i came back however, change was made in virtually every way the application was conceived to begin with. The changes resulted in a drastic makeover and i was in no state to even comprehend the new dynamics of the business that were introduced in the software. I was truly lost. Makeovers are a part of any developmental process. But the big question is if they should be. At least by definition, they should not. A makeover is something that has to come after the development phase is over, instead of being a part of it. In the world of software, where the work and the daily text is  adorning the guises of programming languages, understanding the changes becomes even more difficult. One might argue that this is a common feature of any profession and is not specific or more so in the software world. But i tend to disagree here. Not because i am a part of this Industry of Logic, but because as a proponent of logic i can not help but notice that this industry is still young and is driven by a truly illogical set of rules and frameworks. The code that every one seems to write is more art than clerical form filling. Every one has their styles and hands at coding, like i have discussed this in a previous post. And this being a primary occupation of solving problems, and varied paths may be employed at solving the same problem, the diversity of the work in front of you increases, especially in terms of solutions. So, when you sit down to try and understand what has happened to an existing project, especially one which you worked on, you will find it extremely difficult to comprehend or rather accept new ideas and the general change that has come about in the system. In most software development that i have seen taking place around me, the makeovers are in the form of incremental changes taking place over an extended period of time. True makeovers i think should be a total change of any system ground up. This is a true harbinger of complexity in any system. Such makeovers only complicate the whole process of getting acquainted with new systems. i do not claim that what i have seen or heard of is the general nature of makeovers in any field or profession. But makeovers should, in my opinion, be implemented when one attempts to make something simpler, faster and lighter. This implies a rewriting of the script which may result in an initial failure of the system with its new face. Nonetheless, it should not be avoided. The price of getting better at something is imminent failure, but often that is also its reason in the first place.