As a developer and a CS Student we are normally taught about the waterfall method during college and we just naturally grab the "Development => Maintenance" phase to be the part where the developer is going to be active at and we leave it at that. We take that to be the ownership part of the project which is the first big mistake. Anyway, we'll get to the whole thing in a min.
Talking about Product Development can lead to more than one or two posts and so I'm going to leave it on the response on this to decide if I need to write more about this topic.
If observed, I never really mention my work place projects in my portfolio and it's mostly the tools and apps I've built over time which are all available on my GitHub, and the reason I do this is my role during the product development in most of the places that I've worked was limited to the development phase, I normally had no say in what the designer would do or what the client wanted or even being able to push back to the client if a requirement they mentioned overlapped existing requirements thus delaying the project more.
Not to blame the managements of any of these companies but it was my own thinking back then that it's not a part of my job to do that, my job was to inform the managers that so and so was happening and then they'd do the above but well sadly that didn't happen always.
Anyway, to the product development knowledge and the reason you need to know about this is so you as a developer can rethink where and how you are supposed to be there in the project to handle the respective problems.
There's basically the following stages that are taken in consideration before I start building anything (might come as a surprise but no, I don't just jump into writing code for something without going through these).
This isn't publicly talked about because this is mostly scraps of paper that I kept writing on and then I switched to the iPad and wrote on that instead and recently I've moved to using the Notes section that I've added on Taco for the same. Basically built that for this.
The phase involves making note of everything you currently have in mind for the project's overall scope this can be all fancy or this can be all basic in terms of features but the point is to have it written down so you know what the app is going to be about, otherwise it's just a idea you jumped to build and then forgot what all you wanted to build and that backfires pretty quickly. I seem to remember things I don't want to but then important things like these just slip past when I need them so, just note it down!
Developer's Involvement: Helps clarify what is technically feasible and if the requirement is even valid to go through or is the deadline proposed by the client even achievable
This can then be be reduced to set of core requirements that is what the next phase is about.
Here you throw the idea down the drain and stop thinking of it as my baby product , and take in a logical approach and ask yourself a few questions.
Based on the answers you will normally have a good idea as to what can be kept as a core functionality and what can be added later to make it easier for the targetted user.
Example
I used linear as a task manager while I was building the base of taco, which is basically another issue tracking / task tracking app. I had a few less detailed tasks written on the iPad. There were even plans to integrate with existing platforms, ability to import data from around every other app. I had a lot of fancy stuff I wanted to add to it but obviously the idea of scaling could go all the way to the moon and not always needed. The problem Taco wanted to solve was to have all the basic tools in place to handle tasks and collaborations between teams, not to be the most feature rich project manager out there.
I cut down the requirements to the absolute basics and now all we have is the tasks built first, the projects section was built next and then the teams part is under work right now.
Developer's Involvement: This part can mostly be avoided since the business perspective is mostly what's to be seen here but the developer can still help clarify things or even provide solutions based on past experiences
Next, you setup priorities based on your evaluation method and then get to deciding who's going to do what.
If this was being done in a company then you'd have to figure out who's available and what's to be handed to whom but since I work alone on these project the team selection is pretty simple.
Developer's Involvement: Helps give a 'base idea' of the timeline and how much extra work might be needed
You get the idea.
Though the Architechture phase is a bit time taking since that base decides how the project would flow and scale and one setup doesn't always work for every project no matter how similar the projects are, we'll get to that.
This step is where I decide how much time it'd take me to build the whole thing considering the arch would take about a week to solidify , design would involve about 2 weeks or so for the core features since it's just the tasks part that needs to be built first but that gets all the base design components to be built by then so I can reuse them in other places.
You have deadlines for your own projects? How do you think taco's first alpha was built in a 6 days!? It has a testing mode, profile management, project relations, task handling, and animation for toggles and the project deadline pulse and obviously components accompanying each with api's handling each.
That's in 6 days with about 4-6 hours of work each day. That's not the fastest in the world, not am I boasting. I'm just saying the deadline is responsible to keep me in track for the project, my productivity can go down significantly based on the following
There's definitely more but that's all you need to know for now.
This phase either lasts forever or is done within a week based on what I'm doing , if I'm building the core then I have a set number of pages that I need to design the UX for and based on that the components that need to be designed.
Then I just reuse these components as much as possible because minimalist
Back to using Taco as an example.
The tasks page has
Banners
List Elements
Side bar Navigation
Accordions (the expanded task view)
Status Menu
Search Input
Buttons
Navigation Menu
Page Headers
Task Type Headers
Now lets group them in terms of things I can make common styles out of
So my menu component has to be dynamic in terms of it's trigger but the menu style is going to be the same, the buttons are well going to be generic, headers are going to have a font size and font weight based on where they are being placed, the banner style can be used for the list items, the actual banners and even scalable to be alerts by changing the background colour, inputs, sidebar navigation structure can be reused in other pages, like the settings page.
Developer's Involvement: feasibility of what component can be built in the given base timeline and what needs to be added as extra in the timeline based on the complexity of the designs, this can increase or decrease the timeline significantly
So Now I have elements that cover 80% of the app UX and the 20% include cards, tables, graphs that are going to be a part of the projects and dashboard. This would've taken like 2-3 days to sketch and finalise and then 1-2 days to individually implement.
Though I mentioned implementing the components before I decided the stack the reason is because the stack is actually decided after a prototype phase which I've explained about quite a bit in previous posts1.
The prototype gives you an idea of what needs to exist and what doesn't and where it would create an issue, in my case I've built enough todo apps to know what's going to break where and TillWhen gave me the remaining needed knowledge for the scaling issues.
So the stack was already in my head thus implementing the components was going to be in React and that's what I did. The stack phase is inclusive of the setup that needs to be done for the same.
This includes the codebase setup, the configurations , CI/CD for the same and environments that you'd be deploying the project on.
In my case
The codebase setup can be a time taking process if you're setting it up for the first time but if you've done it before you can manage or create templates on GitHub to reuse, i'm not sure how many people know about this so I'm just mentioning it here. I have quite a few templates up and I picked up my mono repo template , made a few modifications to the folder structure, added the needed dependencies and then got onto the configuration phase.
A big misconception developers have is that there is to be different branches
that maintain different configurations, like master is to maintain the
configurations for production and dev will maintain the development
environment config. NO!
The codebase and configuration are to remain the same, the values of these configuration change based on where you are deploying and thus remote configs can help you with this but you are better of understanding how to implement this yourself. The branch approach adds up additional overhead of making sure you have the right config before you deploy and if you are using CI/CD for everything that is a disaster when your un-checked configuration deploys to prod. Don't add that headache to your work.
I can be blamed for telling people to do that but in my defence the meaning of maintaining different branches is to make sure that the code on those branches are based on what you want to deploy.
Example
master is to have the code that's been tested and can be sent through to the
prod
dev is the codebase you add untested merges to and what deploys to the staging
environment
this doesn't mean you add hard coded configurations in each branch which differ,
a wrong git rebase commit and boom your configurations need to be setup again.
Make it easier for yourself to handle such cases before you even start coding the project.
The decision on the actual stack can vary based on requirements, so that can be a long post but I think I'll write about it sometime. To just go through what needs to be checked would be,
There's no Developer's Involvement section here since the developer is going to be doing this part. Though make sure you add the project setup time in the timeline as a developer, people don't realise that it's a good amount of work and its your responsibility to make sure you don't forget about this.
This is all for this post, the next post should be out soon in the next few days.
Adios.