Fear driven programming




Fear driven programming:
 
/fɪə(r) draɪvn prəʊgræmɪŋ / noun

definition: copy-paste, add a new flag and a new IF, never change/delete code, put new classes in a new project/code repository










Treatment:
  1. To enable code-base-wide refactoring and deletion of unused code: merge all repos in one repo, replace unnecessary Reflection abuse and replace IoC (and similar) harmful XML Config files with plain simple code, put all projects in one VS solution

  2. To surface existing duplications and avoid adding more: merge together most of projects and instead use namespaces to highlight logic structure and group object by responsibilities.

  3. To enable safe changes and evolution of the existing code: make main classes of your architecture testable, break major dependences from the Db and from the GUI




Dosage:
  • Three Craftsmen developers very skilled and experienced in large legacy code-base, refactoring, tasks automation and TDD, with the cooperation, collaboration and support from the whole team

  • For 1 month and half 
    - plus two weeks when the team is new and need to be gelled
    - plus 1 month when there are external disruptions and entropy generators

  • For a 500KLOC code-base, half code, half commented code or useless comments




Side-effects:
  • no bugs added to the code-base when merging projects, reorganizing namespaces and project references, making main classes testable

  • no interruptions and problems for the other developers, instead a smooth incremental transition from the multiple repo and projects to the new single repo and merged projects

  • no delays to the deployments in productions because all the changes done

  • SSD HD and Windows7 or 8GB of RAM require do keep load and build the big solution fast


Print | posted @ domenica 16 maggio 2010 00:05

Comments on this entry:

Gravatar # re: Fear driven programming
by Antonio Ganci at 17/05/2010 11:57

Bel post! Sono pienamente d'accordo tra l'altro è una delle cose che mi sono trovato a fare.
Aggiungerei: creare un sistema di build automatico che non risieda sul pc dello sviluppatore.
Tra qualche mese secondo me dovrai aggiungere non abusare dei tipi dynamic del c# 4.0.
Comments have been closed on this topic.