>16. The previous people who did a similar analysis did not have a direct pipeline to the wisdom of the ages. There is therefore no reason to believe their analysis over yours. There is especially no reason to present their analysis as yours.
>19. The odds are greatly against you being immensely smarter than everyone else in the field. If your analysis says your terminal velocity is twice the speed of light, you may have invented warp drive, but the chances are a lot better that you've screwed up.
Learning how to better thread the needle between these two is been one of the most important things I have learned in my career. Just because this is the way it was always done doesn't mean we have to do it that way, but the people who did it that way probably had some reason for it that is worth exploring and fully understanding.
Assume everyone is an idiot, including yourself. Verify everything (your own work and other people's work) using robust testing protocols. Don't use your own judgement; you're not smart enough for that. Gather evidence. But test your evidence-gatherers to make sure they're doing their jobs, too. Assume every component of your system-of-people is half-fallen-down and just barely limping along at all times. Make a system that works in the face of everyone coming to work with a concussion.
(And, if some component isn't barely limping along, then people are probably being too naive about its potential failures, so inject some chaos [monkeys] into it to get its reliability down to a level where routing around it has to be operationalized, too.)
In WWII, bullet holes in planes had to be repaired. But the damage wasn't uniform - some areas got badly shot up, some areas were never damaged. So they added armour to the undamaged areas, because the planes that got shot there never came back.
Similar idea from another angle: superficial design flaws obscure fundamental design flaws (Douglas Adams on the Sirius Corporation Complaints Depatment)
Didn't know that principle had a name, but I love it.
Once I have seen a project manager who's project didn't deliver much insight, so he had this brilliant idea to advise to replace some software which was built with some old technology. He didn't have the slightest clue how that software worked, he just knew what the purpose of the software was and his advise was to rebuilt it with newer technology to make it better (whatever that means).
When I told him, that the software wasn't as trivial as he might think and that I am against replacing it, as long as it wasn't clear how the new version would be better (besides being built with that new technology he was suggesting) he started looking for some other findings his project could deliver.
I first read "direct pipeline to the wisdom of the ages" as referring to the internet. But now I am guessing it means that just like you don't have all relevant past information and analysis, neither did they.
> 40. (McBryan's Law) You can't make it better until you make it work.
This has been my credo for developing software for as far back as I can remember. If you approach creating something new as purely experimentation, you'll get to something workable sooner. You can then either polish your newly created turd or choose to scrap it for something new that builds on what you learned.
As an entrepreneur and software consultant, it's more of a "make the good people pay". Here any improvements made must be obviously useful to be worth the money. I'd redefine it like this, where usefulness is the prime motivator:
1) Make it work, if that's important and worth the time
2) Make it correct, if that's important and worth the time
3) Make it fast, if that's important and worth the time
Most of the time is spent hunting for what the software is supposed to be. Prototype, prototype and prototype until you get even close to what it's supposed to be. Treat everything as temporary until then, before applying any real importance on any of the above. Even then, you'll rather be rewriting it anyway, focusing on what's important, because your assumptions at the beginning were most likely wrong. You shouldn't hang yourself for those early decisions just because you invested too much time and effort on making them work.
There's turds and turds. I've seen many of them and no two turds are alike:
1. A long time ago, we had this turd of a hardware abstraction layer that is every systems developer's nightmare. Windows drivers behind a middleware, with COM and whatnot. Support for USB devices, spanning back to Windows 98. No one dared touch it unless absolutely necessary. Fortunately, no one needed to touch it too often. The functionality it offered was rich enough that the trickier logic could be implemented at application level; it decreased code reuse to some degree, but then again, this was a critical enough piece of software that the time wasted by duplicating some logic among applications was offset by the testing effort required for changes in the HAL behemoth. Most of it was okay-ish, too; it crashed under a few circumstances, but not mysteriously -- we sort of knew where the bugs were, but workarounds were available and they were generally deemed good enough.
This was a reasonable kind of turd. I mean, yes, there was technical debt in it, Jesus, it had comments like "TODO: This looks ugly but for some reason it's the only way to make it work on <some Windows 2000 build>. Maybe figure out a cleaner way?", but it didn't really bother anyone. The code was architected so that technical debt piled up on separate shelves, too. The PCI (not -X. PCI. Plain PCI) stuff, in particular, was only touched by one or two people -- but it was perfectly possible to work on other pieces of that code without breaking the drivers for those weird PCI peripherals.
2. I was responsible for one of these turds. A while ago, we had to do a lot of fancy, detailed documentation for a custom logic design. This was going to be implemented in an FPGA which was going to sit in a pretty advanced medical device -- so you spec everything before writing a single line of code.
One of the things I wrote to help me was a tool that sucked in the timing diagrams in our docs (docs were in LaTeX, diagrams were in some markup language) and generated the Verilog code that put out those signals. This was a bunch of Python code, not too hairy, but it hardcoded every single assumption I could make. It started as a tool I'd made for myself; it was reluctantly promoted to a tool that everyone used.
Some folks tried to adopt it in other projects as well but honestly, the damn thing just wasn't up to it. I suggested to (my, by this time, former) colleagues that they'd probably be better off picking a standard markup language for the timing diagrams (maybe TDML?) and write something that was going to be useful forever, more or less from scratch. Or, if not, get a commercial, off-the-shelf thing that does exactly that, written by people who were paid to write exactly that. The time, people and resources for either of these options turned out to be pretty hard to secure, though, so they ended up polishing the half-bad Verilog code by hand. Still better than writing it all by hand, I suppose.
Frankly, this was at least an excusable turd. It was never meant to be used for so much. It got promoted from "a developer's hack" to "project infrastructure" through a combination of short-sightedness, lack of awareness of better options and bad communication, mine included. But it did provide some value and, honestly, removed none -- it sucked in the end, but it still sucked less than the other alternative that was actually available.
3. And then there's real turds. Like, there was this module I saw a while ago, as part of a bunch of firefighting meetings because the original developer had quit.
When it was initially written, it was rushed in, and the first thing that got crossed out from the list was IPv6 support. And fortunately for the schedule, it turned out some bits and pieces of another feature could be reused here and there.
The end result was a massive 30,000-line... thing, that not even its creator really understood by the time he was done. A good chunk of that code was there to glue the bits that could be "reused" to the new feature. There was no abstraction layer -- when IPv6 support had to be added in, what happened was another massive dump of maybe 10,000 lines, that was interleaved with the other one via a thick forest of if-this-is-ipv4-do-ipv4-stuff-else-do-ipv6-stuff.
After humongous amounts of testing and bugfixing, it actually made its way out through the door. which effectively marked it as "too expensive to rewrite", and that was it.
Unlike the thing at #1, there was no way to extend it, in any way. Adding even the tiniest feature took weeks and spawned dozens of bugs. Unlike the thing at #2, this wasn't some internal tool, it was production code.
Truth is, it works, or at least it worked the last time I had anything to do with it. But in terms of investment it was a really bad thing to do. It was so hard to extend that there was no way to accommodate customer requirements in any sort of realistic timeframe. Keeping up with the competition basically required two engineers working full-time, on something that wasn't necessarily a critical feature but you couldn't not have it.
This turd probably removed way more value than it added. Or, if not, it certainly prevented way more value from being added. It's my standard for turds.
Yes, that’s “value” in an important sense. But people rarely add in the opportunity cost.
We make decisions every week about what can be done based on the tech debt involved. Every time we punt on an improvement, that’s a real cost. These boondoggles that forever wall off parts of the product as immutable have a cost week after week. What’s the net value after you subtract that cost? Is there any?
I meant it more like a recollection than a lamentation, but it was cathartic here and there :-).
I don't know if it's obvious from it, so I'd rather spell it out -- there are times when "turds" are useful and not to be disdained, much like their real-word cousins: cow dung can be a good construction material and a useful fuel. Certainly worse than concrete and uranium but if that's all you can find or all you can afford, it sure beats eating raw meat and sleeping under the stars.
This isn't true of every piece of software shit in existence, though. Sometimes, "but it works" is just a bad excuse.
Yeah, I guess like most things that's true to a degree. But, those turds have a way of coming back to haunt a project in the form of technical debt.
It would really be interesting if you could calculate how much the technical debt ends up costing on the average project, and whether it's worth the savings gained from leaving the turds in place.
That's an excellent question. It depends, to some extent, on the question if a solution with less technical debt would've been possible at all.
Often, the "turds" were either the only thing possible at the time, or the savings there opened up other opportunities. Not always - sometimes the "cost savers" simply insist on digging a grave for the project.
But that's the main distinction - if it's bad and yet lives on, there has to be value in it. No company spends money on something that doesn't provide value. I suppose what you are arguing is that the product doesn't necessarily provide the maximum value possible. But that's a pretty high bar to meet.
There's always a "good enough". In a perfect world, engineering and product "good enough" coincide. If only one is good enough, you get either a badly engineered financial success, or a financially disastrous monument to engineering.
All other things being equal, only the former lives on. And hence, "turds live on" - and make money, and pay paychecks. And if their maintenance costs exceed their revenue, they usually get shut down.
(I'm deliberately ignoring all projects that can afford to ignore money. The rules are different there.)
Plenty of companies spend money on things that provide no value - which is why msrketing is a thing.
I’ve sometimes wondered - not entirely ironically - if development teams would be understood as a revenue source instead of a cost if they hired their own micro-marketing sub-team to do internal marketing to management.
my company has three pieces of software. one is an antiquated turd full of weird and incomprehensible design which, once you fully understand it, is even worse than you imagined. The other is modern as of a few years ago, and the third is modern as of next year and follows every possible best practice.
The antiquated turd is so profitable that it supports the entire company, the mostly-modern one is about at a break-even point of profitability after 6 years of development, and the modern one hasn't made a dollar yet.
My favorite as an engineer/scientist who has sat through tons of terrible presentations:
20. A bad design with a good presentation is doomed eventually. A good design with a bad presentation is doomed immediately.
If people can't understand your ideas, you're counting on them to shrug and say, "Boy, this guy sounds smart! I guess we should do what he says!" If they're doing their job, they won't.
It's sad, really. In a perfect world, you'd have an awesome design coupled with awesome sales pitch. In reality, a lot of people realized that almost the entire ROI comes from the sales pitch, so you can half-ass the design part (or even skip it entirely, if your sales person is good).
its also probably a supply/cost issue. People that are good at sales are more common, and cheaper to employ than people that are good at designing complex feats of engineering.
It could also be caused by the evaluation of candidates by (typically) business types. They think they can recognize a great sale (because it sold them), but evaluating engineering talent is hard. Even for other engineers, much less suits.
People that are great at sales are very rare, though. And people that are great at sales and have great platform skills are the ones who make it past director level to the executive suite.
Engineers do well when they spot such people early and make friends with them. "Early" is important, because by the time they make it to the executive suite, they (hopefully) already have trusted "technical advisers" who will tell them when their idea sucks before it gets sold and propagated throughout the organization. If they don't, then they will rely on their secret sales intuition and their defenses against common sense will be impenetrable.
This is usually the highest executive function of engineers / "technical advisers" in large enterprises. Not so glamorous, but critical to the health of any organization.
> 30. (von Tiesenhausen's Law of Engineering Design) If you want to have a maximum effect on the design of a new engineering system, learn to draw. Engineers always wind up designing the vehicle to look like the initial artist's concept.
I suppose a lot of new ideas come with a lot of "filler" details that weren't consciously decided on but end up as a permanent fixture of the design, and that whoever tries first to communicate the idea to others has a lot of unintentional influence over the final product.
This was the best advice I got in undergrad (as an EE). We had a seminar from a mechanical engineer who argued that the best thing we could do for our careers was take a drawing class or otherwise get to a point where we were competent at sketching an idea.
People, especially the non-technical, are so visually oriented that, no matter the engineering field, the ability to draw a coherent picture of a concept can be enormously valuable.
There used to be more emphasis placed on technical drawing. I came in at the tail end but I still worked with a lot of blueprints for a number of years.
When I was in Middle School, my shop class had a large unit devoted to mechanical drawing / drafting with pencil and paper. It was fun but also frustrating because the teacher was very particular about the details. If two lines were supposed to meet at a corner, and either one of them extended a little too far, he would mark down for that. Also any erasures prevented a perfect grade. Yes this was before computer drafting was practical, at least in schools.
When I was in high school, we also had a drafting class. Half of it was devoted to old-school pencil-and-paper drafting. (The other half was Autodesk Inventor.)
Tangentially related: every now and then I do some graphic design, and I've seen this "okay I'll just throw down a quick mockup → the client likes it so it basically becomes the final version" progression so many times...
This approach comes with hidden cost of adding unnecessary complexity. Think about B2 bomber design: it looks like some "artist" wanted to recreate a Batplane, or other sci-fi spacecraft and then it took a lot of engineering effort to make the thing of such ridiculous shape to actually fly in stable, predictable manner.
Actually the shape of a B2 is very much influenced by it's function and only mildly by the desire to "look cool". (Though that is important too, apparently the F35 contract went to Lockheed Martin instead of to Boeing because the specs of both proposal were nearly identical but the LM one looked much better)
A "stealth" aircraft is not stealthy from all directions (nor does it need to be) but is optimized for bouncing the radar waves away from the direction of its target. The best shape for this would be to build the plane in the shape of an infinitely long flat surface, but since those are too expensive the "infinitely long" part is usually scrapped. Even shorter flat surfaces have terrible aerodynamical properties though, so there's often a compromise to make it more like a triangle. Then of course it needs to carry stuff like pilots, engines and bombs, so it can't be extermely flat but has to be bulbous. The engines need air intakes but radar waves bouncing off the rotating blades of a jet engine compressor have a very distinct signature in the frequency spectrum, so it makes sense to move the air intakes to the top of the plane where ground based radars can't shine into them. A similar thing goes for the outlets, but those need to be extremely heat resistant as well. To prevent the hot gases from flowing over an extended area of the fuselage you move the trailing edge of the triangle a bit forward. Then there are some more requirements like visibility for the pilots during take off and landing that put bounds on where the cockpit can be. Looks were very much a last consideration for the B2 and pretty much all of of its shape is due to its mission requirements :)
> apparently the F35 contract went to Lockheed Martin instead of to Boeing because the specs of both proposal were nearly identical but the LM one looked much better
People love to repeat this, but it's wrong. Yes the Boeing plane was ugly with the large air scoop, but it also was a great plane whereas the Lockheed Martin plane was a terrific plane. At the time of selection, the Boeing plane could not VTOL with all the bodywork in place (landing gear doors for instance) yes the LM plane had just completed a vertical landing after a supersonic flight. Also, not since the age of propellers had Boeing designed a combat aircraft, whereas Lockheed did the SR71, U2, F117, and a host of other innovative aircraft.
The one thing that the Boeing aircraft had going for it was the single-piece wing. The JSF competition was primarily to design an affordable plane, and the Boeing probably would have been much less expensive to build and qualify.
just on that.The B2's design is mostly about decreasing its radar footprint and nothing else. its curvy because they finally had the computers to design it that way. The nighthawk was all angles because they didn't have the computing to build the thing in a more aerodynamic fashion.
I wish I had gotten good at sketching early in my career. Too late for me now, but not too late for my kid as I involve him in STEM education activites. Interestingly, learning how to sketch is featured in several robotics curriculums for kids, for example Carnegie Mellon's Robotics Academy.
> Any run-of-the-mill engineer can design something which is elegant. A good engineer designs systems to be efficient. A great engineer designs them to be effective.
This is awesome. I don't know how many times I've seen over engineering in the field. It's crazy. Well we may one day want to do X.
I like the way Ben Horowitz puts it in his good pm, bad pm document:
Good product managers focus the team on revenue and customers. Bad product managers focus team on how many features Microsoft is building. Good product managers define good products that can be executed with a strong effort. Bad product managers define good products that can’t be executed or let engineering build whatever they want (i.e. solve the hardest problem).
As an engineer, I want to find the demons that are out there in the problem space and assault them, I want to eliminate all weakness from my precious software. But from the business POV I know we need to provide value to customers quickly and efficiently with the available resources, which is usually not the same thing.
Sometimes I lay in bed at night thinking about the deficiency I haven't had time to address or that isn't a current priority, or the obscure bug I found a while ago that is laying in wait ... then I end up taking a melatonin capsule because my brain won't stop trying to plan/reorganize my next few tasks to squeeze in enough time to solve these issues.
Personally I've never seen a truly great elegant system.
The real world is messy, ugly, full of edge cases, and convoluted.
An elegant solution will solve 70% maybe 80% of the problem, but never all of it.
Realy great engineering, which I feel I have yet to achieve, is managing that complexity and this edge cases and the mess that is the "real world" in a way that is maintainable and manageable and works for all.
In software, these three are not exclusive, they're in fact three rungs on the same ladder. In the words attributed to Kent Beck: make it work (effective), make it right (elegant), make it fast (efficient). http://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast
Elegant but inadequate is common (to name just one combo.) "Not elegant for this purpose" perverts the meaning of elegant. You can say it's not an elegant solution 'cause it's not a solution, if you like, though.
I think you've made a "No true Scotsman" statement, in other words - just swapping "elegant" for "Scotsman."
I disagree. Elegance is fundamentally tied to purpose and... if not efficiency of operation, efficiency of material and structure. A car which is awful to drive and breaks down all the time, but which has simple clever solutions to problems and clean lines is not elegant at all. Or at best it is half elegant.
Elegant is a superset of effectiveness.
Also, side note, I would be happy to never see this “No True Scotsman” argument ever again. 9 times out of 10 it’s just used to demonize ideas: “Your idea was used in this horrible way once”/“That mistake is not inherent to the idea”/“No true Scotsman!” That’s not what you did here. So you’re the 10th. But my point is it’s just used as a rhetorical trick, from what I’ve seen.
Not all that weird if you look at it this way: elegance is that which solves the problem at hand with the minimum amount of fuss and materials. That's strongly tied to purpose.
This whole thread talks about efficient and elegant and effective. Good engineering is mostly in the domain of how a system handles failure. Either by making it a really low likelihood or making it graceful.
Elegant = using magnetic paint and magents on the back of the picture. You thus do not need a nail, can hang the picture where ever you want, and remove it without leaving a trace.
You just have to repaint the house to be able to use it.
See I think of elegant as "set the picture on a table".
The engineer might think it solves the problem and does so in a way that is seen as cheaper, easier, and faster. But in reality it's not what was needed and the elegance of the solution will come back to bite them when the first user wants the picture a bit higher (which is normally met with "why would you want to do that?")
Hm, I think elegant here does not mean classy or fancy. It instead means "ingenious and simple" so an elegant solution is in fact a hammer.
Likewise, I think of efficiency as the resources used to accomplish something. While a nail driver would be fast, it isn't really efficient. An efficient solution is also a hammer.
And of course the hammer is the effective solution.
How does a glass cube drive a nail into the wall for hanging up a picture?
If used as a hammer it is just another hammer (and an ineffective one at that because it is going to slide off the nail and cause you injury or shatter and cause you injury).
It is an actual solution, you can get a nail in with a cube, it probably won't break 'till the fourth or fifth nail. (I have used glass bottles to drive nails.)
Actually, I think SpaceX as a satellite launch company is living this advice as well as one could. You need at least one engine and one launch vehicle, so they built Merlin and Falcon. The rest of their LV development has been steady iterative improvements to those platforms. This strategy enabled them to achieve reusable boosters, because building sophisticated autonomous flight controls on top of a known, proven, reliable LV is much easier than doing it on top of a newly minted one.
SpaceX as a Mars colonization venture on the other hand...
NASA insistence on the human-rating for their own commercial crew spaceflights greatly increases the cost. If I recall right two falcon 9 have been lost to accidents, one on the pad, another 150 seconds into the flight. But the overall ratio of rapid unscheduled disassemblies to successful flights is looking promising.
Compare the predicted likelihood of fatalities with how many FAA licensed amateur/kit built "experimental" airplanes crash each year, killing their sole occupant pilots...
The FAA seems to be relatively OK with that fatality rate, on an ongoing basis, but spacecraft are held to a much higher standard.
If there had been a human in the very first Dragon flight carrying a wheel of cheese, years ago, they would have survived and had a nominal flight.
I also wonder how many of NASA's own human launch vehicles would have actually passed the "human rating" requirements they're now applying to everyone else.
Few, considering the 1+0 lack of redundancy for major life support systems on the Mercury, gemini and Apollo. Their test method seemed to be "fly it unmanned a couple times, if it didn't explode or lose pressure, put some people in it".
And don't forget the space shuttle which had a lot of possible single-point-of failures during launch and landing (e.g. no way to do a survivable launch abort during the first phase of flight; no way to survivably compensate asymmetric thrust when one booster were to fail; no way to shut down or eject boosters until burned empty; no way to perform ballistic reentry and landing when orbital control thrusters damaged).
Depends. Do you want to rule out NASA ever being allowed to evolve its requirements based on what it's learned from past failures? Or out of a sense of fairness, do you demand that what we knew about safety at the start of the 1960s is all we're ever officially allowed to know?
Neither, I do think they should have extensive safety qualifications for new craft, but the process should be faster. I just find it interesting that the us agencies responsible for road+highway safety and small aircraft safety will "accept" up to tens of thousands of fatalities a year, mostly due to operator error... While something like the dragon that has the low risk of killing 4 or 5 people (who have willingly signed up for the risk), takes such a long time to qualify.
His advice predates all private spaceflight. Any launch vehicle was destined to be a sprawling, overbudget federal project back then. Not a lean, for-profit enterprise like Musk has developed.
I think you can make an exception when you haven't developed a new launch vehicle in 50 years, and NASA doesn't plan to launch a human mission until 2035, 15 years after SpaceX will start using its BFR for other types of missions.
I believe NASA is currently planning on launching a manned mission in 2023 or so. There was a push to put humans on the first SLS launch (2019 or 2020) but I think that was motivated by political concerns.
And product management. The cheery slogan there is 70 percent of what you do will fail, the remaining 30 percent will need at least 3 or 4 goes before you get it right.
> 33. (Patton's Law of Program Planning) A good plan violently executed now is better than a perfect plan next week.
In case anyone's wondering about the use of "violently" - this is supposed to be General Patton's law about military plans. Just so happens to apply to other fields.
Except the "violently" here does not actually refer to the use of military force.
It's in the sense of "vigorously" or "forcefully". No hesitation. No hesitation, no waffling, no debate - "just do it". Or, as Amazon calls it "disagree and commit"
I agree that you shouldn't spend a lot of effort going beyond the requirements, but sometimes you will reap huge benefits because you happened to go somewhat beyond the requirements in a given instance. It's like the property of brittleness - you don't want to spend too much time making everything adjustable and bendable, but neither do you want to make everything as hard and precise and brittle as possible.
Someone linked an article elsewhere on HN about the true meaning of mediocrity that I enjoyed and really made me think about this:
A real life example - client discovers that users cannot actually get into the system. Contractor says: "Ah, you wanted a login screen? This wasn't in the specs! You need to pay me more to implement a login screen."
That is true, but the phrasing is a little aggressive. Assigning "lines of blame" makes it sound like it is about having someone to point to after the fact. It is really about every part of a project having a single owner who is accountable so nothing slips through the cracks of bureaucracy. A way to rephrase that without the negative connotations of "blame" is "when everyone is responsible, no one is responsible."
>Of course, the phrasing was meant to be a little aggressive, otherwise it isn't memorable.
That is totally true and was something I missed. A law is of no value if no one remembers it. I bet we could even find one of Akin's laws to explain why that is the case.
Side note, HN blows my mind sometimes in that I can make a comment on a term and within minutes the guy who coined the term is on here responding.
I mentor a high school robotics team. Oh man does it apply to them! I like to run the laws past them at the start of every season. They still stumble over many of them. :-O
The laws I stress:
14. (Edison's Law) "Better" is the enemy of "good".
40. (McBryan's Law) You can't make it better until you make it work.
The law that they are really good at (especially in the middle of a competition):
34. (Roosevelt's Law of Task Planning) Do what you can, where you are, with what you have.
I saw a $96M startup fail, not because the product failed, but because the distribution function for the yield was not understood. It was too sharply peaked to be practical. There’s a lesson there.
> 29. (von Tiesenhausen's Law of Program Management) To get an accurate estimate of final program requirements, multiply the initial time estimates by pi, and slide the decimal point on the cost estimates one place to the right.
I was going to complain that Cheops' Law ("it always takes longer and costs more" is my version) was missing, but that's a useful elaboration providing a new target.
15. (Shea's Law) The ability to improve
a design occurs primarily at the
interfaces. This is also the prime
location for screwing it up.
This is the problem with the information hiding approach of ADT, OO and even APIs: makes it easy to change the module internals, but hard to change the module interfaces.
I'm not an engineer, but i can relate a lot with that:
19. The odds are greatly against you being immensely smarter than everyone else in the field. If your analysis says your terminal velocity is twice the speed of light, you may have invented warp drive, but the chances are a lot better that you've screwed up
As an engineer I don't understand "engineering is done without numbers". All engineering revolves around math. Granted, estimations are needed when your doing analysis on something with no simple formula or that 12 inch pipe has some unknown amount of grime between 1-4 inches.
This has to be one of the worst advice lists of its kind I've seen.
- Too long to be remembered
- Half of it is clever quips and not actual insights
- A lot of the points contradict each other
A list like this mostly serves as a feel-good piece for experienced engineers rather than useful advice for inexperienced ones, since they don't know which part of the list to take how seriously and how to interpret the contradicting ones.
Yeah it’s a bunch of inside jokes from building spacecraft the same way many times with varying degrees of success. There is little to no practical advice. The bit about never exceeding the requirements is great if you want to build something once and wash your hands of it. The “advice” on not building new launch vehicles sounds like someone had a bad time building a launch vehicle and I guess we should double down on the shuttle?
Yes. Now imagine being at a design review meeting with someone with the “gift” of being able to crank out these truthy quips as justifications. If they happen to be right, great. But if not, you are at their mercy.
Any list of advice without contradictions is bound to be a poor representation for full reality. "Experience" is precisely the ability of resolving these contradictions properly in a given situation.
If you want some actual advice, read Rechtin and Meier
"The Art of Systems Architecting" ISBN-13: 978-1420079135
Appendix A Heuristics for systems-level Architecting. While the issues of mutual inconsistent advice remain, at least the rest of the book gives enough guidance in navigation through the political technical and economic issues of systems engineering.
Note: systems engineering not software engineering.
(I have a first edition and haven't seen the current 3rd edition.)
Quite easily: Star Trek being a work of fiction, its contents are unconstrained by any aspects of reality other than the limitations of its medium (in this case, live-action television).
Same here. Also this one:
13. Design is based on requirements. There's no justification for designing something one bit "better" than the requirements dictate.
To what level this is true depends on the complexity of the system I suppose, and how accurate the requirements actually are.
This also though could be applied to any system that just happens to have a massive amount of work to get it even above the ground as well. Just change the language to the behemoth in your field of choice and it applies.
There's a lot of fantastic nuggets in there, that's for sure, but I have a nasty feeling that in a few years time this one will have become firmly entrenched in the vile lexicon of management wank-speak:
31. (Mo's Law of Evolutionary Development) You can't get to the moon by climbing successively taller trees.
I heard something similar from people who worked on Navy subs - an engineering assistant fresh out of college was told "you may have gotten partial credit in school, but a sailor at the bottom of the ocean doesn't care if you did your work partly right".
> (Mo's Law of Evolutionary Development) You can't get to the moon by climbing successively taller trees.
There's no gradual path to some goals. It's annoying beyond belief to only know something well enough to solve toy problems, and not have any way to see how you can extend your knowledge so you can solve non-toy problems.
I read it as the other way. Acknowledging that iterative improvements on fixed assumptions goes nowhere is quite liberating.
Perhaps I have been watching too much Gurren Lagann lately, but my corollary to rule 31 would be: if you are underground, you can only find sunlight by digging up.
Actually that image perfectly represents the concept. To get to the moon they had to abandon puller rockets (like the one in the image), and use pusher rockets instead. That isn't just a higher tree, that's completely re-imagining the way a rocket works.
So "higher trees" might be a good way to learn how to re-engineer the idea so that you can get to the moon.
God I started saying that one pretty early. I may have still been in college when I started saying it. Working while going to school is a very different experience than doing them in order.
>19. The odds are greatly against you being immensely smarter than everyone else in the field. If your analysis says your terminal velocity is twice the speed of light, you may have invented warp drive, but the chances are a lot better that you've screwed up.
Learning how to better thread the needle between these two is been one of the most important things I have learned in my career. Just because this is the way it was always done doesn't mean we have to do it that way, but the people who did it that way probably had some reason for it that is worth exploring and fully understanding.