4 posts tagged with "software"

8 Years ago…

AngularJS was very popular library and talk of the town.

The Software product had a requirement of providing a search solution with display of tabular data / pagination etc. with some UI animation.

It was decided by the tech lead and the management to go with AngularJS and there could be various reasons for it, possibly:

• AngularJS was popular framework
• Going forward all the new features in this software product had to be developed using AngularJS
• It is always exciting to work on a new technology irrespective of figuring out if it actually is needed.

This feature was released and praised, but over the years, there have been no instances of this library being used for any other features, reasons:

• Continued usage of the legacy framework, it being the obvious choice
• The rising popularity of Angular2 over AngularJS causing lack of time and interest.
• Lack of resources / technical skills in AngularJS

So, this huge product had AngularJS as a low hanging fruit, used only for one single feature.

However, security fixes to AngularJS library were patched whenever available.

Transition from AngularJS to Vanilla JavaScript​

Fast forward to today, and our feature remains, but the landscape has shifted. AngularJS is officially deprecated and so we had to reevaluate our choice.

• AngularJS library is deprecated.
• Security concerns from customers
• In this entire product, AngularJS is just used for this one feature.

We chose to use Vanilla JavaScript for various reasons, though the specifics are not relevant here.

When I began working on this feature, it became clear that Vanilla JavaScript could effortlessly provide the same functionality.

Over-Engineering and Unnecessary Complexity in the Original Code​

After careful evaluation of the code, it appeared that this feature was over-engineered.

• I discovered unused or infrequently used library files, bootstrap files, and a templating engine library.
• I believe these libraries were added with the assumption that they would be useful for developing new features in the future. However, this turned out not to be the case.
• Naturally, no one wanted to work with this code again, so all the core library files were left untouched.
• There were clear violations of the DRY (Don't Repeat Yourself) and KISS (Keep It Simple, Stupid) design principles, indicating areas for improvement.

Enter the era of simplification.​

Opting for vanilla JavaScript, we embarked on a journey to streamline our codebase and embrace the principles of DRY (Don't Repeat Yourself), KISS (Keep It Simple, Stupid), and YAGNI (You Ain't Gonna Need It).

The entire exercise of removing AngularJs involved the following steps:

• Reviewing and understanding the entire feature
• Reading the AngularJS code and identifying areas for improvement
• Rewriting the entire feature using vanilla JavaScript
• Ensuring the transformation does not affect the user, as only the underlying technology is being changed, not the user experience.

The Transformation: From Excessive to Efficient Coding​

What began as an experiment turned into a revelation. With over 16K lines of unnecessary clutter stripped away, and under 1K lines of focused, purposeful addition, we emerged with a leaner, more efficient feature.

The journey wasn't without its challenges, but it was immensely rewarding. We honed our skills, boosted our confidence, and left behind a codebase that is not just functional, but elegant and maintainable.

• Increased my confidence in working independently on a feature.
• Enhanced my ability to read any framework code and convert it to vanilla JavaScript.
• Deepened my understanding of vanilla JavaScript.
• Refactored the code, making it more readable and maintainable.

As we continue to evolve, let's remember the value of simplicity, the power of pragmatism, and the importance of continuous improvement.

In this blog post, I am thrilled to share the story behind my proudest Pull Request (PR) yet. PR#458 wasn't just another contribution but a significant milestone in my journey as a software developer. It was a challenging task that pushed me to my limits, and in overcoming those challenges, I learned valuable lessons that have shaped my approach to coding.

By the Numbers​

Before we delve into the story, let's take a moment to appreciate the sheer scale of this Pull Request. It comprised nearly 10 individual commits, introduced close to 2,800 new lines of code, and astonishingly, resulted in the deletion or modification of over 314,400 lines across almost 1,000 files.

History​

The project I worked on has a rich history spanning almost two decades, evolving from a Windows application to a browser-based web app with a diverse tech stack. This enterprise application has made careers of many software engineers, which means this codebase had been touched by many software engineers. With wide tech stack such as CPP, Java and Dojo framework on the UI, over the years, it accumulated tech debt, and my role primarily focused on UI enhancements and refactoring.

The need for a change​

The accumulation of tech debt prompted a thorough review of the codebase to identify areas for improvement:

• Removal of unused assets and code snippets.
• Refactoring of legacy code to improve readability and maintainability.
• Elimination of support for outdated browsers.
• Streamlining of build scripts to remove unnecessary generated files.

Motivational Quotes​

I came across a tweet from Elon Musk that resonated deeply with me: "Far better to delete code than add it." This philosophy encapsulates the essence of efficient software development. While striving for 100% optimized and performant code from day one may seem ideal, the reality is that codebases evolve over time, accumulating unnecessary complexities and redundancies.

Another quote I hold dear is, "Always leave the code better than you found it," attributed to Ward Cunningham. This mindset drove me to embark on a journey of code refactoring and deletion, particularly in a legacy codebase spanning two decades.

Given that we were at the onset of a new release cycle, it presented the perfect opportunity to implement these changes. In the process, I identified several areas ripe for improvement:

• Eliminating unused styles and assets meticulously, even if they were part of the codebase for years.
• Letting go of support for outdated browsers, such as IE6, as their usage dwindled over time.
• Since our project utilized the Dojo framework, it came with its own set of theme files. I painstakingly sifted through these files, pinpointing and eliminating any redundant styles that were no longer in use.
• Streamlining build scripts to remove unnecessary auto-generated files, optimizing the build process.

These actions required patience and thorough unit testing at every stage to ensure they didn't impact existing functionality adversely. By adhering to these principles and embracing the challenge of improving legacy code, I not only enhanced the codebase's quality but also cultivated a mindset of continuous improvement in software development.

We diligently conducted unit tests at every stage to ensure that our changes didn't inadvertently impact any existing functionality.

In the end, this comprehensive cleanup effort not only improved the overall quality of our codebase but also positioned us for smoother development cycles in the future.

The Result​

The PR was not only about code changes but also about personal growth:

• Increased confidence in tackling a codebase spanning two decades.
• Improved code readability and maintainability.
• Timely refactoring to prevent future tech debt.
• Opened doors for new opportunities and stretch assignments.

Room for improvement​

While I'm incredibly proud of this PR, reflecting on it, there are areas where I could have refined my approach:

• Learning Opportunity: This PR provided me with a valuable opportunity to delve deep into the codebase, uncovering insights and learning valuable lessons along the way. It's crucial to leverage such opportunities for continuous growth and improvement.

• Confidence Boost: Deleting code can be daunting, especially when it seems to be functioning correctly. However, this experience reinforced my confidence in making impactful changes to enhance the codebase's quality and performance.

• Enhanced Readability and Maintainability: By eliminating unused code and improving overall code cleanliness, we not only optimized performance but also made future development efforts more efficient. Why burden ourselves with code that serves no purpose? Additionally, utilizing version control tools like Git and GitHub ensures that we can always reference previous versions if needed.

• Doors to New Opportunities: Although this PR focused on code cleanup rather than adding new features, it opened doors to exciting opportunities. It demonstrated my commitment to maintaining code quality and readiness to tackle tech debt, qualities that are highly valued in any development team.

In hindsight, I could have further optimized my approach:

• Breaking down the tasks into smaller, more focused PRs could have facilitated smoother integration and minimized the risk of unintended side effects. This iterative approach would have allowed for more granular testing and validation over multiple production builds, ensuring a seamless transition.

Conclusion​

In conclusion, working on PR#458 was an enriching experience:

• Deepened my understanding of the codebase.
• Boosted my confidence in refactoring and deletion.
• Enhanced the overall quality of the codebase.
• Presented new opportunities for professional growth and learning.
• Overall, PR#458 represents not just a code contribution but a journey of growth, learning, and improvement.

Working on legacy code has its own advantages and in this post I want to talk about how I enjoy and appreciate working on code that is dated as old as 15+ years.

You do not always get to start a project from scratch. Any software product usually evolves over time and ensuring that all the future developments are robust requires considerable efforts.

I am a avid reader of HackerNews, I like to read about start-ups and I love to work with code. I started my career as a programmer working on web projects. I have had experiences working independently and with a huge team. In this post, I try to pen down my experiences as a software developer and some of the things I learned throughout this journey.