Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Code evolution vs Intelligent design

appgrill.tumblr.com

Post reply on HN
Print view View original

11–14 of 14 posts

Re: Code evolution vs Intelligent design

#11

Post by adrianmsmith »

majmun wrote: post #10
adrianmsmith wrote: post #8

"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…

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.)

Re: Code evolution vs Intelligent design

#12

Post by cleaver »

RyanMcGreal wrote: post #5

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…

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.

Re: Code evolution vs Intelligent design

#13

Post by kstenerud »

adrianmsmith wrote: post #11
majmun wrote: post #10

Earlier quoted context omitted.

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 desi…

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.

Post reply on HN