Perfection in code is often a mark of a good coder. Be it Bootcamp, hackathon or interview. A snippet of code with correct format, order, pattern, and QA. This idyllic version of code, undoubtedly, works beautifully. However, coding is not a unilateral process. There maybe ’n’ numbers of options to achieve a single result. Thus a perfect code may not necessarily be the most optimal one. As Henry Petroski puts it

This is a quote by Henry Petroski on perfection in code and design.

Most web development organizations like ours, face the perpetual process of balancing client expectation, feature requirement, timeline, budget and our effort. Often, as a result, features get axed either due to lack of budget or time. In an attempt to adhere to deadlines, engineers often miss the kind of excellence they aspire to.

Perfection as a concept is often debatable. While some argue that imperfections make us real, others state it helps attain excellence. A very similar debate runs among engineers. A well scripted, formatted and organized code helps developers understand how everything works and can be easily tested. Yet, the most optimal script will do the job a hundred times over even without all the formatting.

Marketing department and/or product managers are always requesting the same thing– ‘Get it done’. They need faster turnarounds, quicker results and more A/B testing for each landing page. Behold the rise of ‘code-for-present’ approach. In today’s convenience-first millennial generation, the more important questions then becomes– is it really necessary?

What is the need today?

Unless your client uses your product offering, you will be working on a specific client product. This product will go through various phases and iterations. As an agency, you regularly work with multiple clients who are in different phases of their product development. Some will be in ideation, needing proof-of-concept or a stable MVP, while others will have a ready product in need for scalability.

If you are working with a proof-of-concept, that is, converting the client’s idea into a working prototype. This means creating multiple versions and a lot of back-and-forths. Be it design elements or functionality. In this phase, ideas come often and need to be ‘seen’. This means every change will get reflected in the innumerable prototype versions that you create. In this chaos, there is no place for formatting. You do not have the bandwidth to perfect your code; nor does your client have the hourly budget to support your endeavor.

A similar scenario will emerge when working on the MVP. When features are constantly debated and cut, phased out or brought back in. Simple functionalities like Facebook login or social media integration, become both mandatory and negotiable at the same time.

The images shows development process from POC to MVP and beta release

On the other hand, when you look at scalability in a long-term revenue project. You do not want bad code– where the mystery of ‘what broke the build?’ continues forever. Seriously, try working on someone else’s MVP and scale it. Quite recently, we worked with a product company to upgrade their Drupal version. Reworking their modules meant diving deep into their existing code, ensuring no systems broke and that any snippet we built was properly formatted for future reference.

You can see for each of the above situation, our goals drastically affected our standard of what you call ‘perfect’ code. So, does perfect code exist, anywhere?

Probably not. However, there lies a difference between bad code and imperfect code. A set of instructions poorly planned and unable to handle bad data reflects bad coding.

Today’s definition of ‘good’ code revolves around the ‘need’ it fulfills. Any code at any level of product development should be able to adhere to the following 4 point:

  • do what it is supposed to do
  • should be optimal, correct and efficient
  • handle errors without crashing or fail safely
  • edit or debug easily

Remember, a perfect code may not exist but it should perfectly fulfill its need.