2013.11.08 - project delay(s)

once upon a time, in a project, deep in a distant past, an interesting discussion took place. me and one of my colleagues, from the same project, had an argue about doing things right vs. doing things fast. after having some discussions he asked me “do you know how 1 year project delay is done?” and give immediate answer “every day.”. he's point was that ppl are trying to do everything more efficient and/or generic thus are wasting time every day, which in turn accumulates to a large delay, in a scale of a project.

the more i work in the IT the more i agree with his original quote, and yet more and more disagree with the proposed conclusion. my experience is in direct contrast here. the delay is made every day, with a little steps/falls. the problem is that it is so, because most of the time ppl are either lazy or simply lacking knowledge/experience to do things right the first time (prepare tests, code, refactor…). so instead they go “the fast way” – add hack here, add if(my_special_case) there. thanks to this they do work faster… in a short term. problem with this approach is that it backfires over a time, when code complexity literally explodes, and no one can any longer reason about what's going on in the system. at this point a “Legacy system” (with capital “L”!) is born.

entropy, by itself, can only grow. doing “small fixes to prevent blue screens” does not change the big picture – systematic approach does. local optimizations fail and can lead you in a very wrong direction. however, when this is done in a small steps, on a daily basis, it's harder to notice. some ppl do not notice it until they start maintaining brand-new-legacy-system…