Should I break a massive project into multiple pieces?

I’m working on an ecommerce site and I could break it up as : catalog, checkout, user area, admin/reporting area, inventory manager, and so on.

So far I’ve done 2 sections (working on the 3rd) and they took 2 months each although I was learning a ton. From here I think each section will take 3-4 weeks, maybe less.

Would you prefer to have 1 massive portfolio piece, or a bunch of mid sized projects?

hmmm 2 Months in an ecommerce site you should already have a Viable demo. not pretty or anything but at least a working full stack barebone (db-server-front). I advise you scale back your project and try to make a viable demo and develop new features then.

1 Like

I suppose that would be true if I wasn’t getting stuck for 3 days on small issues and was somewhat competent. My speed is much faster now at least.

Not sure how much my advice helps here, but when I start to work on a project I always envision it as a lot of smaller projects, as you said. I think this is good to not get overwhelmed and see each piece through to completion.

I find myself confused, Sean. I’m not an expert but I hope my thoughts will help. When you say section, do you mean <section> or do you mean webpage, or are you just thinking conceptually - breaking the project up into manageable chunks?

Since you’re learning, I wouldn’t worry that it’s taking you so long - that’s normal and it seems like you’re getting faster, which is good. Your goal is to produce a portfolio to show what you can do, which can be accomplished by either producing smaller projects that showcase different skills with different themes and for different industries (which I think is better because a site should have a consistent theme across all or most of it, and so it’s hard to showcase the full range of your designing and coding skills), or one or two large projects that are specific to certain industries that you’re interested in specializing in.

The first part of your project should always be planning. Decide how many different webpages you’re going to need to provide what the client wants and think carefully about how to accomplish that gracefully. Which page you start with will be partially determined by deadlines. Your client may need the inventory management page first, followed by certain other sub-pages,and then a main page to tie it together, concluding with any other subsidiary pages that are less important. You can map it out on paper or in a document, then break each page down with what needs to be included, and don’t forget about links between pages!

I don’t think it’d be a good idea to put everything into one page file. If you know how, I’d say that you should have one set of files (keeping in mind that you’ll need HTML, CSS, JS and whatever other languages you’re learning) each for your uniform headers and footers, other sets for places those have to be different (which shouldn’t be often, except for if you’re also designing a support site, I think). The main part of each page should have its own files, too. Of course, you could shoot for both - smaller projects to show breadth of skills, and large ones to show the depth of your ability. Again, however, my personal choice would be several smaller projects, but that may not suit your needs and goals.

Does that help?

1 Like

Definitely break it up, think in terms of components or micro-services, as you will then be able to see each intricate detail of each portion of the project and see what needs to be changed easier.

Good luck!

a professor of mine once opined i should never endeavor to build complexity but small fully functional programs that work well together.

breaking a project down into smaller manageable pieces is a wise move. i would argue its the only choice.

a classical way to think about it is the construction of a home. picture an inverted tree diagram with home at the top. the next level below would be components of home, such as foundation, plumbing, electricity, frame, walls, roof and landscape. these smaller projects may themselves have smaller projects unto them all of which may overlap in timefrrame or be dependent in some way, e.g., walls cannot come before foundation while landscaping is independent of electricity.

the person who breaks a large problem into a smaller one to solve will come out on top.

the other benefit of breaking a project down into smaller pieces is reuseability. on your journey you will surely tread over the same path and build sufficient experience on how to traverse that path. after iterating through the construction of 20 user areas for example, you may very well have a base structure you can reference the next time you need to build one ready to go with minimal modification.

1 Like

It does, thanks. By sections I really meant modules, like the admin area, the checkout, the catalog etc. I do split into multiple components (front end) or models/routers on the back end

1 Like

Yeah, I would still agree with breaking up the sections (Admin area/ checkout) etc. :slight_smile: Good luck with it all!

there is an ecommerce tutorial on the vue-js basic course. I suggest you do that and see if you can slowly adapt it to react using the context api.

Its not clear if your working on a portfolio piece or an actual product.
Regardless, you can always take one of the many software development approaches. Probably the most common approach today is agile. Without getting into any buzzwords, the basic idea is you build your system up from the bare minimum to more advanced, but you also get feedback at each stage (sprint).

So for example, if you must have all those features you mentioned then do need to do the basic minimum work for all of them, get feedback and or re-evaluate everything, then add extra features and so on and so forth.

So yes you are building your project into multiple pieces, but in this approach you should be able to spot issues earlier than later, than if you did everything for a certain part, then found out you need to change everything later. There are plenty of other ways to go about software development but I pointed out the most common and potentially one of the most generic.

Goodluck and keep building :smiley: