2 ms·

>The requirements will be ridiculously complicated (have to do everything all the projects to be replaced do), One of the biggest problems in this type of proj

• teh_klev 10y ago
  I'm working on a project exactly like this. I'm merging two billing systems. One of these is a legacy mudball of classic ASP and it's a veritable snake pit of nested includes and globally defined variables that just magic themselves into existence out of no-where. It's been very hard to define tasks and timescales because there are little dark corners and special edge cases in the legacy mudball that don't immediately jump out at you when trying to review the code and work out what the hell it does, and why. The original developer is long gone and there's not much way of commentary in the code. A lot of the code is illegible because somehow the original dev's indentation went mad at some point in the past. Then there's the database....
• codr4life 10y ago
  Oh, there have been plenty of attempts to write down exactly what that is. The problem is that more than half of it will inevitably consist of bullshit ceremonies, bike-shedding and marketing. Given enough experience to cut the right corners and knowledge about actual use cases for the old software, rewriting is not the horror story that's currently on auto-repeat.