I would like to be able to share this, amiably, with a few of my colleagues and bosses who are not programmers, as we recently had to judge a $half-million piece of software with 2 600 line cashflow functions and I was the only one complaining.
But, yeah, look, the article is 'fine', but not much more, and very unfortunately.
Does anybody know of a similar article re modularisation with a more transparent example, and a more detailed transition between hypothesis and conclusion? He just seems to say 'less complexity', ???, 'profit'.
There is this "Working Effectively With Legacy Code" book by Michael Feathers that talks primarly about various ways of transforming very messy code to make it testable.
Comments
I would like to be able to share this, amiably, with a few of my colleagues and bosses who are not programmers, as we recently had to judge a $half-million piece of software with 2 600 line cashflow functions and I was the only one complaining.
But, yeah, look, the article is 'fine', but not much more, and very unfortunately.
Does anybody know of a similar article re modularisation with a more transparent example, and a more detailed transition between hypothesis and conclusion? He just seems to say 'less complexity', ???, 'profit'.
There is this "Working Effectively With Legacy Code" book by Michael Feathers that talks primarly about various ways of transforming very messy code to make it testable.
s/\?\?\?/'Less time fucking around debugging stupid errors'/