I found this looking for the source of "climbing higher and higher trees to reach the moon" It's Mo's Law (#31 on Akin's list)
31. (Mo's Law of Evolutionary Development) You can't get to the moon by climbing successively taller trees.
Some other good ones for software products:
1. Engineering is done with numbers. Analysis without numbers is only an opinion.
7. At the start of any design effort, the person who most wants to be team leader
is least likely to be capable of it.
9. Not having all the information you need is never a satisfactory excuse for not
starting the analysis.
23. The schedule you develop will seem like a complete work of fiction up until
the time your customer fires you for not meeting it.
More of the same is not enough to get you to some other faraway place.
Making a better car will not result in an airplane.
That does not mean that making a car first is not an worthy endeavor for gaining experience to build an airplane - should you need e.g. machining, metalworking and general engineering experience. But it won't give you ANY aerospace background.
Or as Alan Mulally famously put it:
"An automobile has about 10,000 moving parts, right? An airplane has two million, and it has to stay up in the air." (on being asked "How are you going to tackle something as complex and unfamiliar as the auto business when we are in such tough financial shape?")
Some problems require a revolutionary approach. For example, managing the info in a departmental system for 100 users is very different from an Internet application serving a million users. You can't just evolve from one to the other, you need to radically re-design for fundamentally different requirements.
Iterative development is good at getting the details right. But you're never going to make a huge leap with iterative development, you need to make such leaps intentionally and with significant planning, even if you iteratively fine-tune after that.
The three keys to keeping a new manned space program affordable and on schedule:
1) No new launch vehicles.
2) No new launch vehicles.
3) Whatever you do, don't decide to develop any new launch vehicles.
From a design/user experience point of view I think this one is the most profound.
2. To design a spacecraft right takes an infinite amount of effort. This is why it's a good idea to design them to operate when some things are wrong.
Designing for perfect means designing for perfect context. But perfect context never exist. In most cases your customers are using your service/product in sub-optimal circumstances.
> 30. Engineers always wind up designing the vehicle to look like
the initial artist's concept.
I find it really helps to have a picture in my mind of what I'm building.
> 34. Do what you can, where you are, with what you have.
Relevant for me this day, as it includes acknowledging my own inabilities, lack of knowledge, low-quality of prototype code etc, then accepting that that's how it is right now, and acting instead of hand-wringing.
I was going to say: An ideal spacecraft is not one in which everything is perfect, but one in which it gets hit by something unexpected, everything explodes, while all people manage to evacuate to some escape capsules, combine into a giant robot and save the universe (note anything after "combine" is optional as long as all people survive)
Was a fun read. Works well in software development, just know when to draw the line at ensure it works (people might not die due to our failure, unless you are writing pacemaker code)
Some other good ones for software products: