Refactoring in a large code base

[Rustom Mody]

On Friday, January 22, 2016 at 1:59:15 PM UTC+5:30, Marko Rauhamaa wrote:
> Ben Finney :
> 
> > The author points out there are times when a code base is large and
> > complex enough that refactoring puts the programmer in a state of not
> > knowing whether they're making progress, because until the whole
> > refactoring is complete the errors just cascade and it's hard to tell
> > which ones are relevant.
> 
> I've been there. I think the root problem is to have a code base that's
> so large and complex.

Bizarre comment... Are you saying large and complex code-bases should non-exist?

> 
> It *could* be avoided if the engineering director only cared.

Some problems are trivially solvable... for those who have the knowhow
Some problems are inherently hard but easily detectable as such... once again for those who have the knowhow
And some are literally (and ironically trivially) unsolvable

The CS-trinity: 'normal' problems, problems in NP, undecidable problems is a classic example of this.
However applying that in real-world practice can be highly non-trivial,
requiring from specialized knowledge to intelligence to genius.

IOW "engineering director does not care" is likely true but also a gross oversimplification