Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This cycle usually ends too early though, sometimes at the first iteration, and the code will be pushed to production. Usually the spec is lacking and the customer (internal or external) doesn't really know what he wants. After that, feature requests and bug fix hacks will deteriorate the condition of the code base to the point where things break if you look at it. Rewriting will be difficult because instead of formalising the requirements in a specification, with all the hacks and features added the existing code base is the spec. So you end up with something very fragile and not so agile. At the bottom lies a first iteration model which the original developer (who left the company a couple of years ago), have been given some time to reflect on things, now knows to be a model which can't possibly scale.

Sometimes (not always), it's best to release when ready. Shipping is important for a company, but for a dev team/individual it should be further down on the list and more importantly, development is not done after the first release and features don't maintain themselves.

I don't like the whole 'ship as soon as possible'-thing.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: