Last Friday, the CEO of the company I work for said something interesting: “Technology is not the end. It is a means to an end.” He, then, elaborated that by saying that we are making applications to make people’s lives easier. The code doesn’t have to be perfect. If it works for 90-95% of the cases, it is fine. We can go back to it later and refine it.
This caused an internal debate within me. I have always been (and still am) an advocate of beautiful code but I have (occasionally) let myself get slowed by trying to make code more beautiful (and better organized). What I should have done is made something work then refactored it afterwards. This way, I don’t delay a release and I get time to make things better later.
Obviously, this assumes I will get time later on to make the code better organized or more understandable. Depending on the industry you are working in, you may not have the time to make things better or refactor the code. So how does one deal with this? You have to strike a balance (which may not be easy at times) between trying to make everything 100% perfect and finishing the project on time.
I don’t want anyone to think that it is okay to write sloppy code and use this reason an excuse. I have had to deal with the aftermath of such code way too many times. Let me tell you, it is not pleasant (although sometimes it can be interesting). It is, however, important that we don’t get bogged down by writing that perfect piece of code that we lose sight of what is most important – getting the application in the hands of the end-users who will have feedback of their own.
Leave a Reply