> How you plan to structure a project never works out, you always find better ways as you go and as the objective and priorities change (they always do).
I always joke I write everything three times. The first time to get a feel for the space, the second time because I think I now understand it and then again when I finally really understand it. Most of the times these three look absolutely nothing like each other.
I think that even extends over longer time periods to projects as a whole and an evolving team. Sticking to my current project which has a nearly 20 year legacy and looks nothing like what it was when it started:
V1: Perl CGI, HTML forms, very little js
V2: Perl CGI, JQuery, Ajax (done badly with js code generated by Perl code)
V3: Perl backend rest API (will be "public"). TypeScript+Vue front end.
Each time a transition has happened as the application features have outgrown the architecture, and more has bean learnt about how people use the product and therefore what it needs to do.
In this case it has now grown the the point that Node and build tools are required.
Avoiding Googleable backlinks, if you search for "integrated antibody sequence and structure tool" you will find it.
I'm the first "product" person without a bioinformatics background to work on it. The new version isn't out, but is a significant rewrite with an aim to massively extend its functionality in future. (Current "public" version isn't even the current commercial version, and very 90s in style!)
Backend is a very large Perl codebase implementing a significant amount of algorithms from academic research.
It's been awesome to work on, my ideal sort of project where I can bring a technical product focus and learn about interesting technology and science at the same time.
I always joke I write everything three times. The first time to get a feel for the space, the second time because I think I now understand it and then again when I finally really understand it. Most of the times these three look absolutely nothing like each other.