[jacquesm]

As someone who does this too: it depends. If you take time out every now and then to completely refactor your code base it can actually be surprisingly effective. I've done exactly that on my last project and I'm pretty happy with the end result, you can have a look for yourself:

https://gitlab.com/jmattheij/pianojacq/-/tree/master/js

This project will likely never be finished, there are always nice new things to add or requests from people, there is no commercial pressure because it is a hobby project and I don't have a boss to answer to. And even if such refactoring operations take me two weeks or more (this one I did while I was mostly just working on a laptop without access to a keyboard so it was sometimes tricky to ensure that nothing broke) in the end it is worth it to me because I am also paying the price for maintaining the code and if it is messy then I would stop working on it. Project dependencies are the absolute minimum that I could get away with.

The project moves forward in fits and starts, sometimes I work on it for weeks on end and sometimes it is dormant for months. In a commercial setting or in a much larger team I don't think this approach would work.

[samwillis]

> If you take time out every now and then to completely refactor your code base it can actually be surprisingly effective.

So much this!

Current project I'm on, I own the entire front end for a major modernisation (AKA rewrite) of a legacy application and we are working in 4 week "sprints". I'm giving myself two days every month just to refactor the code I wrote that month.

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).

On another tangent, before pivoting into software development I used to be a mechanical/industrial engineer. The parallels between coding and CAD are enormous. With CAD you also need to be spending 10% of your time "refactoring" your model. It's almost exactly the same from a maintainability perspective and leaving the model with good hygiene for the next person to work on.

[jacquesm]

> 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.

[samwillis]

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.

[jacquesm]

Neat, is this a public project. You make me curious what it is that you are hacking away at!

[samwillis]

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.

[jacquesm]

And super useful too. Wow. Thank you, I will definitely have a look.

[Timon3]

I looked through your code a bit, and there are a couple of things I'd flag in a code review (e.g. use of non-local variables). Ironically these are things that are a lot harder to do, and easier to spot, if proper modules are used.

[jacquesm]

I'm sure you would, and if you looked at earlier versions of that same code you'd see mountains more of those.

I'd love for everything to be perfectly pure though and side effect free. The pressure is always on to improve it further. As for code review, feel free and open tickets for whatever you spot and hopefully one day I'll get around to it. Better yet: submit pull requests.