What does larger scale software development look like?

[WebDevCody]

I didn’t expect this video to get that many views. I just wanted to make a video to give people who work solo or or on a smaller project more insight into a larger scale project. Your mileage may very. Every company does things their own way from what I’ve seen, and most companies have various teams that all work on their own sub systems and integrate with others.

[MaJetiGizzle]

As an enterprise developer myself, this is by far one of the best breakdowns of how enterprise software development works and I wish there was a video like this when I got my first developer job.

[redaelouahabi]

Yes, you're correct. Startups may have lower complexity, but the underlying concepts and patterns remain consistent. This video is truly exceptional, highlighting this fact.

[shubh-kr]

Bro... it's as much real as it can be. It's THE BEST description of how different teams in 80% of the industry do their job. And you also covered rest of the 20% by including redundant systems, and multi layered prod systems (Production Microservices like architecture). Great stuff.👏

[svenbloem]

Since the start of coding 2010 I was always on my own with solo projects as fullstack dev. I had always big questionmarks regarding those enterprise teams working together. Those 24 min of your video were so incredible eye opening to me and it made me a good feeling to finally understand how this works. Awesome work here Cody

[JosephAuslander]

This is epic. I've worked in enterprise environments for the last 10 years and this is by far the best intro explanation I have ever seen. Well done :)

[KuroManX]

Beginning of year I singned a simple VPS, the best choice I made so far, started learning linux, ssh, git hub actions, automatic deploy, git (for real), managing db, staging (my personal PC), production environment, nginx, and those things made me so more aware of how development works and how can I really deliver software as a product.

[kellychi]

As a web dev newbie who just came out of a coding bootcamp, this kind of content is super valuable since the teachers never really talk about this too much. I am so glad that I found your channel! This type of real world content is also rather rare on YouTube, and I am looking forward to seeing more of this from you 😀

[gundalaibatkhuu]

As a final year CS student, I am so grateful to have watched this before my first actual job. Thanks a lot

[kennethweber]

I am on a 5 man scrum team implementing robotics in software and this video holds pretty true. Depending on the scale of the company you find yourself in, that whole user interaction part can sometimes get absorbed by the roll of a pm and perhaps other individuals or teams, but this was a great summary of how things work.

Great video.

[vladimirgorea]

With 10+ years of enterprise web dev experience under my belt, i approve this. One thing you missed though are the many endless product team meetings. The flows you talk about here are happening in an ideal scenario. In reality there's a lot of big talks and "we're all a big family", feature rushes, egocentric people, pizza parties, "synergistic" in person meetings and not so much time actually writing good software. Btw, perhaps we should also open the topic of "cloud" costs. I've worked with one that started with gcloud and datastore and it turned into a hot mess that needed almost 1 year of refactoring and paying 10k+/month for infra alone

[rhumedisi]

Thank you very much for this brillian discuss on how enterprise systems are developed and how enterprise teams work on large scale projects. This video is way more than a random video as you share a lot of insights into how large team are structured and how their projects are planned, developed and deployed. Quite a rare video on youtube. Thanks once again.

[Hescar]

As a SM this is a great for devs to understand why there's so much syncs and managment stuff or meetings. Enterprise will scalate like crazy were you can have like 100 teams trying to push features. Great video!

[carlosmspk]

I've had only one professional experience with working with a bigger team and I have to say this video is spot on. Literally everything we did, we did exactly as explained in the video. The only thing I would say differed, is that we had no contact with users other than error logs on AWS, our client was pretty much 100% responsible for gathering user experience and send that our way, digested, so we could turn those into issues. We also didn't have automated smoke tests, we just had QA do those manually before releasing

[WebDevCody]

A lot of others might do trunk based development (where you merge directly to main, have a ton of automated testing, and use feature flags to prevent unfinished code from being used by users), but in my situation we need to use long living feature branches. Sometimes you have to use a process that works best for your client and team.

[OsmanToplica]

Dude! This was amazing. As developers we never actually get taught this (not even in college), but we kind of pick it up in the different organizations we get to work for under our career. Seeing it laid out like this is beautiful, thanks.

[brintmontgomery]

Finally! Somebody outlined how this process works in teams at different scales! Excellent video. Thanks for making it.

[Bigfe]

Hey Cody, Love the content. I've worked professionally as an engineer for 13+ years amongst varies enterprises and this top tier content for helping dev's understand enterprise software life cycles! I will say, I'm surprised that a Business Analysts isn't sandwiched somewhere between your PM, Designer, and Client.

[warren-cga]

We've been burnt multiple times using dev -> feature branch flow and I don't recommend my teams to do it. Now we always fork features from main, and work it up through the stages so that if we need to make a cut without some buggy feature we can and feel comfortable not leaking changes into prod. Our team also use a pre-prod environment to verify changes we release before they are done to make sure we have an exact replica of what prod will be/ or what it is, because staging may contain bugs that need to resolved. As you said multiple times it gets complex if your team is bigger or have multiple team working on solution spread across the organization. BTW. very good video, you got most of it clearly explained.

[piotrpuf]

solid video; to make it more adequate and complex - Business Analyst is a must (partly overtaken by UI/UX designer here) and QA allocation in entire process; regardless the role inside organization - there is always BA being a system functional expert being able to present and negotiate options - customers in general have ideas and do not go into details since they are not technical, do not know system limitations; do not undestand full workflow scenarios; are not capable to have a holistic view, identify gaps and risks. Same goes with Devs - they don't have to understand entire functional scope of the system, to memorize or the details, or at least it is often not achievable due to e.g. rotation inside company. BA role is key to be a proxy; while UI/UX designer is a part of that process, by role definition, it is not only about interface design; but I believe the simplification here is that in most cases - BA and UX experts coexists where UX designer is more technical role (UI) focusing on workflow and visual aspect