81–90 of 130 posts
The only software that is ever "done" is code that has been abandoned and is no longer in use.
Earlier quoted context omitted.
yes you have. you've moved it into the subjective by requiring pleasing aesthetics
Perfection is subjective because flaws are subjective. Aesthetics are part of the code. If a piece of code is functionally perfect but ugly or inelegant by some measure, then it is imperfect by that measure.
I see things a bit differently. Some domains are well understood and it's relatively easy to write perfect code (e.g. mathematical functions, list manipulating functions, etc.), while in others it may be much harder (the file uploading example he mentions). To me a good aim of writing code is to move bits and pieces from the latter camp to the former, so that more and more of your codebase is well understood (and per…
Those are good examples of things that seem easy to write perfectly until you change some requirements that seemed like they would never change.
Take your list manipulating library and throw in a requirement that all node allocations have to be pooled, or that it needs to work in a multi-threaded environment. All of a sudden you have to rewrite them all. (for example, see: STL vs EASTL)
Someone already mentioned floating point, but math can definitely get tricky if you have to be exact. An example from my own past experience - it's really easy to write code to cut a 2d triangle using an arbitrary line as the cutting axis. It almost always works, and it usually works flawlessly. Until you get close to degenerate cases, skinny triangles or overlapping vertices. Throw in a requirement that degenerate cases must resolve correctly, and suddenly you have to start over and use a different representation of numbers. Make it a little more general to handle 4+ sided polygons, and before you know it, you spend a decade trying to get it right. (for example: http://www.complex-a5.ru/polyboolean/comp.html)
Earlier quoted context omitted.
Great link! But also, the mean is itself an imperfect summary of some distributions. Any single-number summary will be misleading in some cases.
Anscombe's quartet is a great illustration of that. https://en.wikipedia.org/wiki/Anscombe%27s_quartet
I still haven't learned this lesson well enough. Code I think is near perfect always turns imperfect over time. The main corollary for me is that I can spend every waking second of my life making my code better, and I'll never be happy. I want to better figure out how to enjoy 'good enough'.
Improving code beyond the point where it gives material benefit is not really a problem except for the fact that it deprives you of the opportunity to work on crappier code. Especially when working with new code, I find it useful to concentrate on process rather than end product. If you write tests like X and refactor like Y, how does it affect the result?
In some ways this is really freeing because you get over the fear of writing crappy code. If it's crappy, you just get to improve it. It also allows you to explore ideas and ways of doing things without worrying so much about the result. Concentrating on producing good code can often (in my experience) lead to achieving a local maxima but not does not allow you to kick out of it to achieve something better.
One of the depressing things about code is that it is astoundingly easy to build something that does amazing things in controlled circumstances but is otherwise practically garbage. Promotions, venture capital, and all other manner of rewards can result from said garbage. The “real work” is in figuring out how to move forward from something like that, and lots of stress comes from trying to do so without breaking any…
What you say is indeed important, but I wouldn't say the work before that is not "real work". It's just different types of work. Ask any successful startup founder what their initial codebase was like and they would say--if they're honest--it was shitty. There's a reason for this. The "real work" you mention comes into play only after the product has reached product market fit and needs scaling. Before that phase, it…
I see things a bit differently. Some domains are well understood and it's relatively easy to write perfect code (e.g. mathematical functions, list manipulating functions, etc.), while in others it may be much harder (the file uploading example he mentions). To me a good aim of writing code is to move bits and pieces from the latter camp to the former, so that more and more of your codebase is well understood (and per…
Actually, I'd say writing perfect code in the mathematical domain is extremely hard - floating point types are a minefield and infinite-precision arithmetic is a minefield also if you consider the possibilities for running-times exploding. For example, code for the mean of a list of numbers is a hard problem when looked at in its full generality [1] - and that's using forgiving definition of "perfect" - alway correct…
I see things a bit differently. Some domains are well understood and it's relatively easy to write perfect code (e.g. mathematical functions, list manipulating functions, etc.), while in others it may be much harder (the file uploading example he mentions). To me a good aim of writing code is to move bits and pieces from the latter camp to the former, so that more and more of your codebase is well understood (and per…
> Some domains are well understood and it's relatively easy to write perfect code (e.g. mathematical functions, list manipulating functions, etc.), Those are good examples of things that seem easy to write perfectly until you change some requirements that seemed like they would never change. Take your list manipulating library and throw in a requirement that all node allocations have to be pooled, or that it needs to…
That list manipulating library might still be based on concepts which are understandable and communicable to their users, allowing us to reason at different levels on their internal and external behavior. This in turn allows us to say, at a certain abstraction level: this code is complete. Thinking of Occam we might continue: given our preconditions, our abstractions, our algebra: this is the simplest.
It is fair to believe that 'perfect' means that all unnecessary complexity is removed. But, I would like to argue againts its usage, as the word carries too much emotional baggage in this context.
I see things a bit differently. Some domains are well understood and it's relatively easy to write perfect code (e.g. mathematical functions, list manipulating functions, etc.), while in others it may be much harder (the file uploading example he mentions). To me a good aim of writing code is to move bits and pieces from the latter camp to the former, so that more and more of your codebase is well understood (and per…