Code evolution vs Intelligent design | Hacker News Reader

Code evolution vs Intelligent design

appgrill.tumblr.com

28 pointsmarakas10 comments

Every time I try to do this, I end up having to rip it all up anyway when the requirements change. As John Gall famously said:

"A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work."

Over the years, I've gotten much better at writing components in such a way that I don't end up painting myself into a corner and can easily add/modify functionality later.

The important word in the the Gall quote is "complex". I still like to believe that a perfect non-complex system designed from scratch can spring forth from its creator's imagination. The "complex" threshold will vary by programmer.

The component strategy is like meeting the complexity dichotomy somewhere in the middle... limiting the scope of one component to a complexity that can be reasonably understood, while still taking part in a more complex whole.

"To implement the next step you are going to have to go back and dig up all that perfect code you have just finished writing..."

"This sounds nice, but nothing has really changed - we have just shifted the problem from the coding to the design stage."

Things have indeed changed.

- If I spend 4 hours designing something and then have to throw it away due to realizing the next piece of functionality doesn't fit in with the design, then I have to throw away 4 hours work.

- If I spend 2 weeks programming something, and the then have to throw it away due to realizing the next piece of functionality doesn't fit in with it, then I have wasted 2 weeks.

yeah but in practice you can't just design without at least writing test program to gather intelligence. I mean you can but it would be like living in a fiction world.

I disagree. Unless you are an inexperienced software developer, or it's a completely new domain or technology, or a very experimental problem, you can indeed design the software up-front. Why wouldn't you be able to?

And even if it's an experimental problem or algorithm that's not well understood, and you have to write some test programs, it's still better to spend a day writing test programs and 4 hours doing a design (then throw it away if you encounter a problem with it), than spending 2 weeks actually writing the real code, with documentation, error handling, performance testing, and so on (then throw that away if you encounter a problem.)

True, but besides this there are time constraints to any project where money is on the line. You need to get something out quickly that satisfies the market requirements (which usually start off pretty low when you're first entering said market).

So you build the minimum viable product, measure demand (one measure is how many people care enough to complain about your product being so crappy), and then iterate. If you have lots of unit tests, refactoring becomes a less risky proposition, even to the point of re-architecting large chunks of functionality to meet emergent requirements.

Is it slower than building the perfect product up front? In the long run, yes, but in the meantime, you've already tapped a paying market and have gained valuable insight into how people use your product, which guides your further design refinements in ways that cannot be anticipated up-front. And if it turns out the market is dry, you can fail quickly with less resources invested.

That's not to say you should eschew up-front design, but rather the up-front design should be done with the understanding that you're only going for "good enough" with some suppleness built into your architecture for the inevitable refactoring.

There is experimental evidence that computer programs are insteligently designed, as opposed to real lifeforms:

http://blogs.discovermagazine.com/loom/2010/05/03/linux-vers...

The problem with this analysis is that it seems to analyze the subject with the assumption that the intelligent designer does not have bounded rationality. If we want to use articles like this to truly reject declarations of intelligent design of lifeforms, we must then attack intelligent design's declaration that the designer does not suffer from bounded rationality. Otherwise, it's constructing a strawman to take down intelligent design. The debate needs to be more rigorous, if there is to be a debate.

The point of the article was to show that Linux works differently then a real life form. E Coli being a product of evolution is already a settled issue, as far as biology is concerned.

All systems evolve, if they can change at all. Systems with intelligent actors (software, language, economics, etc) involve more factors than biological evolution does. Biological evolution is mainly through variation and selection. Intelligent evolution also involves borrowing (acquisition) from outside the "genome", planning of future changes, analogical reasoning between "lineages", and other means of generating and fixing variations.

Reply on news.ycombinator.com