Hacker News new | past | comments | ask | show | jobs | submit login

Oh, I don't claim that complexity is impossible to recognize. It's really important to do so. But how?

Most judgments of complexity we currently make have a lot to do with familiarity. (Is the 40-line spreadsheet program at http://www.nsl.com/k/s/s.k complicated or simple?) You assume something similar when you say "obviously more complex than it needs to be". When is complexity obvious? When it exceeds what we habitually consider ok.

What we really need is an objective measurement. Do we have one? We sort of do, insofar as the research on this seems to point in one direction: shorter programs are simpler. That doesn't answer every question - you still need a way of measuring program length and defining what a program is - but it's the beginning of an objective answer.




It boggles my mind every time I see that spreadsheet program. It's probably one of the tersest bits of code I've ever seen.

Here's an overview of the spreadsheet program that's implemented and a walk through a bit of the code:

http://www.nsl.com/papers/spreadsheet.htm


For evaluating a refactoring or using a library/framework, you can compare the number of statements that would be used to add a given feature before vs. after the refactoring.

What's harder is to evaluate the effect of adopting a certain pattern or framework will have on the cost of future refactorings. I don't think people do even a back of the envelope estimation of even just the first number. The number of statements put in can probably be used to estimate the cost in man hours.


My preference would be to put it in when it pays for itself (i.e. makes the code smaller) and not before. Otherwise it's too easy to fall victim to one's own spin.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

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

Search: