Pour recentrer un peu le sujet, je vais répondre par rapport à mon expérience personnelle (que ça soit pour des projets strictement persos ou pour le travail, ça revient un peu au même dans la mesure où je n'ai pas à travailler avec un "client" à proprement parler, mais que j'ai toujours été laissé extrêmement libre dans ma conduite de travail - ce qui a des avantages, mais aussi d'énormes inconvénients dès qu'on aborde des projets importants).

Je n'ai jamais travaillé sur des langages aussi bas niveau que de l'assembleur, donc j'espère que ça va quand même t'aider.
Le premier point, c'est de lever les doigts du clavier. Essayer de dessiner une trame de ce que va faire ton programme. C'est à dire, dans ton cas, les différents flux à traiter, en entrée et en sortie (code source, code compilé), puis en fractionnant de plus en plus pour avoir une granularité de plus en plus fine (séparer en traitements primaires, puis à l'intérieur de chaque traitement, etc.). Ca, ça peut très bien se faire sous forme de schéma avec des flèches, des cubes, des ronds et des bidons. Il existe un certain nombre de normalisations mais, à part pour du gros travail d'équipe, je pense qu'à peu près tout le monde adapte les normalisations à ses besoins. Donc crée ta normalisation. Une fois que tu auras la méthodologie, si tu as à l'appliquer dans une autre norme, ça ne sera pas tellement compliqué.

Ensuite, il faut rédiger ou noter en français les processus de ton application. Les numéroter et les associer aux schémas que tu as fait précédemment. Ca te permettra, si tu reprends ton projet dans 6 mois ou un an (un nouveau bout de chou ou autre, on ne sait jamais ^^) d'avoir un support. Je sais que c'est ce qui m'a sauvé à plusieurs reprises quand j'ai bossé au taff et que j'ai dû reprendre des projets laissés en suspens pendant un ou deux ans.

Là, tu peux déjà commencer à écrire des bouts de codes. Sépare les bien par processus (là, par contre, je ne sais pas dans quelle mesure c'est applicable à l'assembleur... faire plusieurs fichiers ? faire une bibliothèque de fonctions ? j'avoue que ce n'est absolument pas mon domaine ) et documente ce dont tu as besoin en entrée et en sorties (dans un langage procédural, ce sont les paramètres et les retours d'une fonction ; là encore, je ne sais pas comment c'est géré en ASM...).

Ensuite (ce conseil t'es proposé uniquement parce que tu fais de l'ASM, c'est vraiment pas un truc que je fais), tu peux soit garder une organisation bien découpée et structurée (plus facile à maintenir), soit incorporer dans un seul fichier de projet toutes les petites briques que tu as construites. Un peu comme un maître d'oeuvre qui a fait construire ses portes d'un côté, ses chapes de béton d'un autre et qui, petit à petit, assemble sa maison. Cette seconde façon peut - peut-être - te permettre de faire des optimisations sauvages une fois que tout est bouclé.

Bon, je ne sais pas si j'ai répondu à la question. Le handicap principal est que je connais très peu les asm et leurs possibilités (j'ai bien dû écrire trois programmes en x86 et cinq en 6809, et encore c'étaient des TP à la con, autant dire que ça n'est rien par rapport à ce que tu fais).