[{"_1":2,"_3":-5,"_4":-5},"loaderData",{"_5":6,"_7":8},"actionData","errors","root",{"_73":74,"_75":76,"_77":78,"_79":80},"routes/tags.$slug",{"_9":10,"_11":12,"_13":14},"retObject",[61,62],"tilList",[],"blogList",[15,16],{"_21":47,"_23":48,"_17":49,"_19":50},{"_17":18,"_19":20,"_21":22,"_23":24},"matter",{"_43":44,"_45":46},"readTime",{"_35":36,"_37":38,"_39":40,"_41":42},"slug","04-design-principles","frontmatter",{"_25":26,"_27":28,"_29":30,"_31":32,"_33":34},"date","2020-07-29","description","An introduction to the why and how of design patterns","hero","https://res.cloudinary.com/dinypqsgl/image/upload/v1680036203/blog/constellation_tvvs9q.jpg","tag","architecture","title","Design Principles","minutes",2.605,"text","3 min read","time",156300,"words",521,"content","\n\n\nBe forewarned that _most_ if not all of the discussed design patterns will be\nobject oriented in nature. Despite this, the overall spirit of design patterns\ncan prove to be helpful to functional and procedural programmers alike. Before\nwe tackle the **how** of design patterns, it's important to determine the\n**why**.\n\n\n\tIf you know the why, you can live any how\n\n\n## Why design patterns matter\n\nAs, at the time of writing this, I admittedly have not given much thought to\ndesign patterns for a variety of reasons. Including but not limited to:\nJavaScript doesn't lend it self very nicely to object oriented design patterns\ngiven its prototypical inheritance chain and the fact that during my day-to-day\ntasks, I'm not often pondering \"what pattern would work best in this scenario\".\nRegardless, as Bruce Lee once said, all knowledge is self knowledge... Thus,\nlearning about design patterns will, at the very least, help me learn more about\nmyself. Hippy dippy things aside, there are actual tangible benefits to learning\ndesign patterns.\n\nFor example, naming a thing allows us to say more with less. When we use a\npattern in a description, it lets other developers know what design we have in\nmind. Similar to how naming your child whilst still in the womb makes the whole\nbaby thing all the more real, so to is true for design patterns. Why the baby\nexample? My brother just had a kid so I've got babies on the brain 😆.\n\nSpeaking design also allows us developers to stay in the design phase of our\nsolutions longer. Oftentimes, if you're anything like me, you're itching to\ngetting to typing... this however, can be counterproductive as we may end up\ncoding ourselves into a corner (I've done this before and it is **not** fun).\nAnother benefit to speaking design is that it allows the conversation to stay at\na higher level of abstraction and this is beneficial because developers who may\nnot be versed in the implementation language of the solution can still\ncontribute to the overall development of a solution. Inclusiveness is gooooood.\n\nLastly, knowing design patterns can open up career opportunities! If you're at\nall interested in being a Solutions Architect, design patterns will become your\nnew best friend.\n\n## How do I use design patterns\n\nI would be remiss if I did not state this disclaimer: design patterns cannot be\nimplemented by a framework and they don't even exactly go into your code... they\ngo into your 🧠. Once we've got a good working knowledge we can then apply these\npatterns to our old code and prevent our new code from becoming a hodge-podge of\nspaghetti.\n\n## A reminder\n\nWhen it comes to designs, there's a couple of things that we need to keep in\nmind:\n\n1. Program to an interface and not an implementation.\n2. Favor composition over inheritance\n3. Encapsulate what varies.\n4. Too much abstraction isn't necessarily a good thing!\n","data",{"_25":26,"_31":32,"_33":34},"10-technical-debt",{"_33":58,"_25":57,"_27":59,"_29":60,"_31":32},{"_43":55,"_45":56},{"_39":51,"_41":52,"_35":53,"_37":54},576000,1920,9.6,"10 min read","\n\n\nThe beginning of my career was blessed by the fact that I never really had to\ndeal with code that other people had written (at least not directly). When I\nbegan my career, I started off working at an agency, and if you've ever worked\nat an agency before, you're aware of the fact that the work is primarily project\nbased. Meaning, once I was done writing the code for a specific project, I\nwasn't on the hook for maintenance (there was no technical debt that I ever had\nto pay down). This sounds great, but there were trade-offs with this no tech\ndebt way of working; hardcore deadlines and sleepless nights being but two of\nthe negative aspects of this kind of project work.\n\nEven when I transitioned to being a product developer at Mastercard, everything\nI worked on was greenfield; I started everything from a clean slate. I was\nfortunate in this regard -- I didn't have to deal with technical debt for a\nlarge portion of my career 😏! \"However, when I was eventually confronted with\ntechnical debt in the real world, I was utterly astonished by the extent of its\npresence in numerous high-profile applications and businesses.\n\nSo let's talk a little about how I learned to manage, mitigate, and pay down\ntechnical debt 🙏🏽!\n\n## What is technical debt\n\n\n\nTechnical debt, at least in the context of this blog post, refers to decisions\nthat engineering teams make in order to expedite the delivery of features. At a\ngranular level, continuing to use and expand up class components that exist in a\nReact codebase instead of trying to write new components using hooks (reusing\nold outdated patterns) is a decision that adds technical debt. At a higher level\nof abstraction, continuing to work with and utilize a custom built fullstack\nframework (that is poorly documented) instead of using a prebuilt solution like\n[NextJS](https://nextjs.org/) or\n\n[Remix](https://remix.run/) is another form of technical debt. Don't get me\nwrong, the custom built solution works... but it's clunky and hard for to reason\nabout and this very same thing can be said about React class components.\n\n\n\nNow, why do we call technical debt \"technical debt\"? Well, similar to debt in\nthe real world, technical debt accrues interest and the longer that we wait to\npay off this debt, the more the interest will compound. Now the interest I'm\nreferring to isn't monetary in nature (like that of your mortgage 😅) but a more\nintangible interest. This \"interest\" results in engineers spending more time\nfighting with the codebase instead of actually focusing on delivering value to\nusers. As the technical debt accrues interest, it becomes increasingly more\nfrustrating and tedious for engineers to work on solving problems; their focus\nshifts from \"let me deliever value\" to \"please lady luck, don't let me break\nanything during my deployment\".\n\nPlease keep in mind, I'll be talking about technical debt and how I've seen it\nmanifest inside frontend codebases. I'm sure the discussion I'm having below\nwill be applicable to other parts of the stack but since I am a frontend\ndeveloper (at least for right now), I'll be focusing on the frontend.\n\n## Paying down the debt\n\n\n\nBy this point, we should all be on the same page about what technical debt is\n(at least at a high level), and the next obvious question is, \"now what\"? My\ntrite response is let's talk about figuring out how to go about paying down this\ndebt.\n\n\n\nLast year I was exposed to a method in which a team can pay down technical debt\nwhilst still continuing to deliver value to their users. Oftentimes, our initial\nvisceral reaction to projects with severe technical debt--and this used to be my\nreaction too by the way-- is to treat them like Frankenstein's monster... our\nprescribed remedy is cleansing by fire 😆. While it would be great to be able to\nstart a project from scratch and rebuild an existing application from the\nground-up, sometimes it just isn't feasible. What do you mean Taran? We're\nengineers! If we can dream it, we can do it! Well yes, you're right, technically\nanything is feasible but I'm not only talking about technical feasibility.\n\nRewriting an entire application or sometimes an entire host of applications with\na brand new shiny framework just not make sense for the business, especially if\nthe business is risk averse. Writing software takes time and if you're rewriting\nsoftware and functionality that already exists, it's really tough to get buy in\nfrom senior leadership that this is indeed required. Unless your technical debt\nis so much so that it endangers the scalability of the business, I highly doubt\none would be able to sell a proposal for a rewrite up the entire chain of\ncommand -- your manager might just stop you before you even try to convince\nanyone else that it's a good idea. Don't forget, the time we spend working on\none thing is time we're spending not working on another thing.\n\n

\n\tTime is money, money is power, power is pizza, pizza is knowledge, let's go.\n

\n\nSo what is an engineer to do? How do we deal with this technical debt,\nespecially if the organization that you're working with is totally against a\nground-up rewrite. The answer: a phased migration!\n\n## Phased migration\n\nNow what do I mean by phased migration? Well just that... you migrate things...\nin phases 🤣. Kidding aside, a phased migration is one in which where we pick\nparticular pieces of functionality/pieces of the codebase and start rewriting\n(migrating) them over to an isolated area (the \"clean\" area) in a manner such\nthat they can still be consumed by the legacy bits of the application.\n\n\n\nThe phased migration I'm in favour of is one in which we start by picking out\nleaf nodes and working our way up the depedency tree. Rewriting entire routes or\nlarge components of an application is no easy feat and will require turns of\ntime, however, if you break down the depedency tree into leaf nodes and start\nleaf by leaf, pretty soon you'll have rewritten quite a large chunk of your\ncodebase without you even realizing it.\n\nAfter the completion of the leaf nodes, we move up to the parent nodes and begin\nmigrating those over to the new paradigm. It's a recursive cleanup of tech debt!\nThere's a lot of different ways this manifests in a codebase and I'll leave the\nimplementation up to you, but if you're interested in how I'm attempting to do\nit at my current workplace, it's via NX. It's actually quite easy to plop NX\ninto an existing application and the suite of tools it ships with and sensible\ndefaults they provided you really make it easy to get started partioning out\nyour codebase into \"legacy\" and \"new\". With NX, anything that's inside the libs\ndirectory is considered new and anything that's inside of the src directory\nwould be considered legacy.\n\nThe level of effort thats associated with this migration strategy is lower than\na ground-up rewrite but the trade-off is that it'll take way longer to have\nreach a state of minimal tech debt. Regardless, engineers will end up being\nhappier since they are getting to write shiny good clean code and the business\nwill stay happy because we didn't have to throw everything that was written a\nfew years ago into the trash.\n\n### How did NX help with my tech debt at work\n\nThe code for my works primary project exists in an `src` folder. There are a ton\nof components, business logic, and state management files spread across this one\ndirectory. Not only that, but the project itself was also configured to use\n`tslint` and `enzyme`; both libraries that have been deprecated and should no\nlonger be used.\n\nThe way in which NX enabled me to start writing brand new features using modern\ntech while not having to migrate every component at once was via the usage of nx\nlibs. NX is a suite of monorepo tools that provides users with a CLI to generate\nnew libraries, in addition to having a cache that stores the result of various\noutput commands (like your test and lint commands).\n\nOnce my colleagues and I had agreed to break our project into domains and\nsubdomains, we created separate NX libs for each subdomain. For example, we have\na `product-presentation` domain, a `search` domain, and... sigh, an `ads`\ndomain; each domain was assigned a corresponding lib.\n\nThe command to generate a react lib is: `npx nx g @nx/react:library`.\n\nAnother thing that NX helped us to do was enforce module boundaries. In the\nlegacy `src` folder, presentational components are coupled with data access\ncomponents and utility functions are scattered all over the place. By embracing\nNX's prescribed best practices and\n\n[Project Boundaries](https://nx.dev/core-features/enforce-project-boundaries) my\nteam and I were able to enforce best practices by making engineers embrace the\ncreation of cohesive units. The enforcement happens at the linting level\n(`eslint` will yell if you don't follow proper module scoping) and at the PR\nlevel; a combination of man and machine 😆.\n\nNX is deserving of its own blog post and I can't do it justice in this single\nentry alone. Please standby for me to give a meetup presentation and record it.\n\n## How do I manage tech debt\n\n**Tech debt comes and goes; accept that it exists and that it's just something\nthat you need to manage**. There's two things I know for sure when it comes to\ntech debt; tech debt always comes back (and that's okay 😊) and tech debt comes\nback at an excelerated rate if teams do not have a sense of ownership over their\ndestiny. Truly, autonomy and responsibility are two factors that can help\ncontribute to keeping tech debt at pay.\n\n

\n\tI slept and dreamt that life was joy. I awoke and saw that life was service. I\n\tacted and behold, service was joy.\n

\n\nIt really comes down to process, not discipline. I repeat, do not rely on\ndiscipline to maintain code standards and to keep tech debt at bay. Discipline\nbreaks down and engineers tend to skew towards laziness and for these reasons\nalone, relying solely on discipline is an incorrect approach toward software\ndevelopment. We need to put tooling in place (like linting, proper code reviews,\ncodeowner files) that enables us to embrace a coherent approach to software\ndevelopment. In fact, these things are not new concepts; codeowners have been a\nthing on github since 2017!\n\n## Closing Thoughts\n\nHopefully you found this post helpful! I'm a novice at handling technical debt\nbut I'm grateful for having had the opportunity to share my experience with you.\nHopefully it'll give you some hope when you're dealing with your own version of\n\"Frankenstein\"... remember, fire is not always the answer! 😆\n",{"_25":57,"_31":32,"_33":58},"2023-07-26","Managing technical debt","Not all debt is bad, but technical debt generally tends to suck more than most other kinds of debt","https://res.cloudinary.com/dinypqsgl/image/upload/v1690343493/blog/scott-graham-5fNmWej4tAA-unsplash_vlsarc.jpg",[63,64],[],{"_23":69,"_17":70,"_19":71,"_21":47},{"_21":22,"_23":65,"_17":66,"_19":67},{"_25":26,"_27":28,"_29":30,"_31":32,"_33":34},{"_43":44,"_45":68},{"_35":36,"_37":38,"_39":40,"_41":42},{"_25":26,"_31":32,"_33":34},{"_33":58,"_25":57,"_27":59,"_29":60,"_31":32},{"_45":72,"_43":55},{"_41":52,"_35":53,"_37":54,"_39":51},{"_25":57,"_31":32,"_33":58},"ENV",{"_100":101,"_102":103,"_104":105,"_106":107,"_108":109,"_110":111},"requestInfo",{"_96":97},"newsLetterData",{"_87":88},"honeypotInputProps",{"_81":82,"_83":84,"_85":86},"nameFieldName","name__confirm","validFromFieldName","from__confirm","encryptedValidFrom","2uFkfVUVzLLHMPsLW3Nmr89Cf2j7Y17atQmwLtCBcahn8UksGq5xa30=","newsletterImage",{"_89":90,"_91":92,"_93":94,"_95":94},"src","https://res.cloudinary.com/dinypqsgl/image/upload/f_webp/c_scale,h_150,w_150/b_transparent/r_max/v1/blog/me?_a=DATAiZeEZAA0","srcSet","https://res.cloudinary.com/dinypqsgl/image/upload/f_webp/c_scale,h_150,w_150/b_transparent/r_max/v1/blog/me?_a=DATAiZeEZAA0 1x, https://res.cloudinary.com/dinypqsgl/image/upload/f_webp/c_scale,h_300,w_300/b_transparent/r_max/v1/blog/me?_a=DATAiZeEZAA0 2x","width",150,"height","userPreferences",{"_98":99},"theme","light","MODE","production","SENTRY_DSN","https://4e34045e065e0a3ef57135ae5020f388@o4506001960468480.ingest.sentry.io/4506001960599552","AMPLITUDE_INIT","12e15cca4c978dad4bb7dc430e747471","CONVERT_KIT_FORM_ID","7241351","ALGOLIA_APP_ID","1WK0J33355","ALGOLIA_SEARCH_KEY","1020981c7c75273359b7fe3f80a8909e"]

Blog posts

Managing technical debt

Design Principles