Initial feedback on the application architecture & SDLC of NadineWest ## tdlr; I approached this review from 2 different perspectives: 1. [Architecture & Technical](#arch) 2. [Software Development Life Cycle Process](#soft) My goal in the first review oriented around identification, rather than recommendation, though I will provide some next steps.

## Architecture & Technical - **Technology Stack:** Ruby on Rails & Hotwire ([monolith](https://github.com/NadineWest/nadinewest-oms/)) ([nadinewest.com](https://nadinewest.com/)) - **Deployments:** [Heroku](https://dashboard.heroku.com/teams/nadinewest-team/apps) - **Source Control:** [Github](https://github.com/NadineWest/nadinewest-oms/) - **CI/CD:** [CircleCI](https://app.circleci.com/pipelines/github/NadineWest/nadinewest-oms) - **Issue Tracking:** [Basecamp](https://3.basecamp.com/3611527/buckets/21056952/todosets/3515279600) ([NEW](https://3.basecamp.com/3611527/buckets/21056952/card_tables/5436609025)) - **Design:** [Figma](https://www.figma.com/file/ZQtIE84Ev0gtfljRv7z0Zf/Nadine-West-MVP?type=design&node-id=1962-2024&mode=design&t=De7LDzLysip4BYtr-0) ### Strengths Overall, your technical architecture isn't bad. Ruby / Rails is a perfectly adequate choice for most of what you're doing. Other good choices your team has implemented are: - ✅ You're testing - ✅ You have CI / CD - ✅ You have a delayed job queue (this is one good scale indicator) - ✅ Heroku / Postgres are good choices for transactional e-commerce - ✅ Github for Source Control ### Weaknesses Again, I don't think your weaknesses on the technical / architecture site are that bad. Here were some things I identified. 1. **Expensive infrastructure.** You're using 12 PL Dynos in Heroku. Seems overscaled, but would have to dig a lot deeper to understand why. 2. **Possible Memory leak.** This looks new. [see image](/images/nw-throughput.png). 3. **Hotwire.** High-level is that this is a mixed bag. I'll discuss more in opportunities. 4. **2 Deployments / 1 App.** The `nadinewest-website` and `nadinewest-orm` deployments are now both part of the `nadinewest-orm` repo. This can create problems. 5. **Tribal Knowledge.** 6. **Difficulty Hiring.** In summary, Rails is not a bad decision from a technical standpoint. On the backend, it scales fine for what you guys are doing, and the established conventions and production-hardening have proven it in the wild. That said, the ecosystem for hiring devs is a lot smaller than counterparts like Javascript, Typescript, PHP, etc. Here's a chart from JetBrains (a popular IDE). ![jetbrains](/images/nw-dev-langs.png) It's important to note this also has an impact on the code ecosystem of the language. Fewer developers generally means less community activity, shared module code, solved problems, etc. It also impacts the pace at which the community can release (sometimes critical) updates. ### Moving Forward 1. **NadineWest.com - Home Page.** I would have to verify in your analytics software, but at least SEMRush says this accounts for 70% of your load (`_/getting-started` redirects there). ![SEMRush](/images/nw-sem-rush-top-pages.png) From what I have seen in Figma and code, this page does very little critical interaction with the server **for rendering**. This makes it a great candidate for serving as a static asset, which would dramatically improve cost & allow for virtually infinite scale. This is a small, incremental project that could be built on a platform like [NextJS](https://nextjs.org/docs/pages/building-your-application/rendering/static-site-generation). > zinc:"Possible Pushback" Your development team will likely not like this idea. >

> [Hotwire](https://hotwired.dev/) is designed specifically by 37Signals to make front-end development feel more like Rails, so your current team > is likely going to prefer it to most other options. >

> In addition, the team has recently spent a lot of time [stripping React out of the application](https://github.com/NadineWest/nadinewest-oms/pull/2461/files). >

> However, given the current issues & environment, it's still my recommendation. It opens up the door to hiring non-Ruby devs, dramatically reduces your > service cost for that page, and makes you more agile. 2. **NadineWest.com - User App.** Once your Home Page is moved over, the next iteration would be the rest of your app. This can be done very incrementally, and with a mind toward all of your future facing marketing integrations. There are exceptionally good patterns in the Javascript world for building out marketing tools, and JS is the fastest moving community in AI right now. ![openai](/images/nw-openai.png) I can go into more depth here as needed 3. **Load investigation.** ## Software Development Life Cycle In my view, this is where your most significant improvements need to be made. ### Strengths 1. **Work Ethic.** 2. **Established Product.** 3. **Modern Tooling.** ### Weaknesses 1. **Accountability & Velocity.** 2. **Acceptance Criteria.** 3. **BA -> Product -> Design -> Engineering.** 4. **Sprint Planning.** 5. **Findability & Organization.** 6. **Cost.** ### Moving Forward 1. **SDLC Implementation Plan.** 2. **Incremental Low-Friction Changes.** 2. **.** #### SDLC Overview #### Sprint Timing #### Development Stages #### QA Stages #### Reference Material - [Basecamp Backlog](https://3.basecamp.com/3611527/buckets/21056952/todosets/3515279600) - [NW Website](https://nadinewest.com/) - [NW Github - OMS](https://github.com/NadineWest/nadinewest-oms/tree/master) - [NW New Site Figma](https://www.figma.com/file/ZQtIE84Ev0gtfljRv7z0Zf/Nadine-West-MVP?type=design&node-id=1962-2024&mode=design&t=De7LDzLysip4BYtr-0) - [Hotwire](https://hotwired.dev/) - [Commit Moving Away from React to Hotwire](https://github.com/NadineWest/nadinewest-oms/pull/2461/files)

Enter Password