Best advice for big coding projects

#productivity #codenewbie #codequality #architecture

⁣The best advice I’ve gotten (and applied) for solving large/complex development tasks is to research and map out a solution BEFORE you start coding. 🗺⠀
⠀
— Do the research, explore, and weigh all the potential options. ⠀
— Does this task/project lend itself to some system design pattern? Explore that.⠀
— Don’t forget to explore existing tools and services/APIs. Don’t reinvent the wheel.⠀
— Write/type them in some organized form (document, diagram, etc.)⠀
— Determine the logic flow and data flow; how does data move through your solution?⠀
— Define and diagram the different components needed and how the will work together⠀
— Also get feedback from another dev(s) if possible. ⠀
⠀

⠀
This doesn’t have to take a long time or be a lot of writing, but even doing a little of this upfront can save a lot of time and produce better software.⠀
⠀
👉🏾 Curious; what is your advice for tackling large development projects/tasks?

Top comments (6)

jrogers8835 • Jun 25 '20

Sad path. Sad path. Sad path. So many times I see designs that are elegant only for happy path or assume nothing will ever go wrong. Plan and design for failure from the start.
Avoid transactionality across microservices... learned this one the hard way.
Borrow someone who hasn't been in the design sessions and explain it to them. Good gauge for if things are counter intuitive, over complex, or go against norms.
Plan MVP, MUP, and MAP iterations at least. Going all or nothing before seeing it operational is going to hurt you later. (Viable, usable, and adoptable for anyone not familiar with the latter 2)
TDD isn't just unit tests, know what payloads should generate what responses before you start so you can recognize gaps. Update your collection of tests as the project grows.
understand and incorporate client/ pm mvp, short term, and long term goals for the project but avoid over engineering flexibility that's not even in the roadmap

Kelvin Graddick • Jun 26 '20

Thank you!! These are gems!

neil445 • Jun 27 '20

Documentation is key. I've worked on a fairly huge project that was initially estimated with 9 months for the MVP, unfortunately, it dragged on for 2 years; TWO YEARS! The major cause of the delays were features and additional functionalities that were "sneaked in", you may call them scope creep. We have documentation for the functional specs but they are everywhere, we have a version in cloud, on the contract, and somewhere else's computer but they all don't tell the same thing. If there was one thing I learned through it, have the everything documented in one place, and DATE them. Document every decision on the project you've talked about with the client/project manager be it in a formal meeting or a coffee machine encounter.