Documentation and Testing


Hey everyone! I wanted to spend this blog finally talking about my project. I can’t share details due to a non-disclosure agreement, however I really wanted to discuss some learnings about legacy code and technical debt.

Here’s an except about technical debt:

Technical debt (also known as tech debt or code debt) describes what results when development teams take actions to expedite the delivery of a piece of functionality or a project which later needs to be refactored.

I don’t think the author of this paragraph is talking about the quality of the resulting product, but rather the context around the product itself. There is a lot more that goes into software development that goes beyond design and implementation. Hint: the two phrases mentioned in the title of this post are kind of important, especially when new developers inherit your code.

From Michael Feather’s Working Effectively With Legacy Code, he states that “legacy code is simply code without tests.” Without tests, it’s difficult to refactor existing code without a way to verify if introduces bugs. It took me very long into my journey to learn about the importance of regression testing but every interviewer I’ve spoken with so far has stopped my spiel about a project to ask if any tests were written.

While I learned a lot in Web Development and Mobile Development, two of the more programming heavy courses, the most critical skills I gained were near the end of the program. From Software Engineering II, I learned about TDD (Test Driven Development) which as the name implies, is about incrementally building a program by writing the tests first and satisfying all prior tests as well as the current problem to solve. From Cloud Development, I learned how to design a backend according to API specifications and how to develop and document my own API.

Inheriting code that someone else wrote is an inevitability. I hear about it all the time from software engineers at large companies. A lot of their work comes from implementing minor bugfixes or refactoring a project to the newest tech in the stack. For example, classic multi-page websites to React SPAs. Work is often incremental, updating one page at a time until the site is finally transferred. There are cases where it’s not that clean, for example incompatibilities in the existing code with the new tech stack. But that’s a topic for another time.

Print Friendly, PDF & Email

Leave a Reply

Your email address will not be published. Required fields are marked *