It's not exactly rocket-science either - you basically involve domain experts in the development proces directly, and codify their knowledge in a form that they can understand (be that very explicit models, or focussed domain-specific languages).
In the second case: that is a massive smell and time to find a new job. Which from the comments regards turnover at Amazon seems to be the case :-)
I think there can be some slack in this. I've had great success when product managers and UX designers worked closely tightly with engineers but were the only ones talking to customers/users. As long as their focus is on deeply understanding the domain and user needs it can work really well. I think XP describes this as something like a standin customer.
> It's not exactly rocket-science either
I'd imagine that occasionally "rocket science" is exactly what it is!
But it’s more than that. To name a few: * How does one raise the thrust temperature as high as possible without melting the engine to maximise thrust? (The burning temperature IS already higher than the engine material melting point) * how does one reduce the redundancy (both system wise and material wise) to minimise weight while ensuring the rocket won’t fail?
I studied physics in undergrad and in classical dynamics we covered “rocket science” in these terms. The term is more or less a misnomer as science implies trying to understand how the universe works. Building rockets is engineering but studying their motion does rely on both the equation I gave above and also on fluid dynamics. From the point of view of “science” it is pretty simple. From the point of view I’d actually building a rocket the engineering is very hard. Since that time I’ve always had a bit of a chip on my shoulder about the “it’s not rocket science”. It also doesn’t help that both my parents studied aerospace engineering in undergrad and grad school and tried to impart a decent chunk of it on my as a kid (which I resisted very hard).
I worked on a ballistic missile tracking software that would calculate areas of uncertainty given coverage of various defense mechanisms.
It very much involved rocket scientists from JPL.
You are wrong in every measurable sense of the word.
1. If HN had a friend system/social graph, you'd have a pending request from me based on this comment alone.
2. Fantastic domain name in your profile.
Sounds like I lost the asshole measuring contest :)
Does that unbaffle your baffles (oh, yes, rocket scientists do have to deal with baffles! You left that out) or should I elaborate? Bless your heart, but it isn't exactly rocket science.
It takes sixty-five thousand errors before you are qualified to make a rocket.
-Wernher von BraunEven just orbital mechanics has a decent amount of complexity. Transfer between celestial bodies in general requires solving the three-body problem (or four for transfer between planets). And it's one thing to solve for just the trajectory of an object given some initial conditions, and another to figure out the correct initial conditions to give to get the trajectory you want, all the while staying within a fuel budget. Then you have to contend with not having instantaneous impulse in real life.
A simplification here is that you can get a decent approximation to the three/four-body problem with patched conics, which is where you assume that the gravity outside of a celestial body's 'sphere of influence' is zero, and within that SOI, all of the gravity comes from that body; in this way, you can treat it as a series of two body problems, where you 'patch' together the solutions (which are conic sections) for the orbital trajectories of the all the bodies involved. This is by no means a perfect approximation, though, and in practice I would expect that one would want to check a given solution found with patched conics with a more complete n-body simulation.
Even simpler than this, though, at least mathematically, is orbital rendezvous. Here, you only have to contend with the gravity of a single body. Yet it's very difficult to get the timing right, and the first couple attempts by the USSR and the US failed, and Buzz Aldrin even submitted a doctoral thesis based entirely around orbital rendezvous (two spacecraft meeting in Earth orbit):
> In its first human spaceflight program Vostok, the Soviet Union launched pairs of spacecraft from the same launch pad, one or two days apart (Vostok 3 and 4 in 1962, and Vostok 5 and 6 in 1963). In each case, the launch vehicles' guidance systems inserted the two craft into nearly identical orbits; however, this was not nearly precise enough to achieve rendezvous, as the Vostok lacked maneuvering thrusters to adjust its orbit to match that of its twin. The initial separation distances were in the range of 5 to 6.5 kilometers (3.1 to 4.0 mi), and slowly diverged to thousands of kilometers (over a thousand miles) over the course of the missions.[1][2]
> In 1963 Buzz Aldrin submitted his doctoral thesis titled, Line-Of-Sight Guidance Techniques For Manned Orbital Rendezvous.[3] As a NASA astronaut, Aldrin worked to "translate complex orbital mechanics into relatively simple flight plans for my colleagues."[4]
> First attempt failed
> The first attempt at rendezvous was made on June 3, 1965, when US astronaut Jim McDivitt tried to maneuver his Gemini 4 craft to meet its spent Titan II launch vehicle's upper stage. McDivitt was unable to get close enough to achieve station-keeping, due to depth-perception problems, and stage propellant venting which kept moving it around.[5] However, the Gemini 4 attempts at rendezvous were unsuccessful largely because NASA engineers had yet to learn the orbital mechanics involved in the process. Simply pointing the active vehicle's nose at the target and thrusting was unsuccessful. If the target is ahead in the orbit and the tracking vehicle increases speed, its altitude also increases, actually moving it away from the target. The higher altitude then increases orbital period due to Kepler's third law, putting the tracker not only above, but also behind the target. The proper technique requires changing the tracking vehicle's orbit to allow the rendezvous target to either catch up or be caught up with, and then at the correct moment changing to the same orbit as the target with no relative motion between the vehicles (for example, putting the tracker into a lower orbit, which has a shorter orbital period allowing it to catch up, then executing a Hohmann transfer back to the original orbital height).[6]
> As GPO engineer André Meyer later remarked, "There is a good explanation for what went wrong with rendezvous." The crew, like everyone else at MSC, "just didn't understand or reason out the orbital mechanics involved. As a result, we all got a whole lot smarter and really perfected rendezvous maneuvers, which Apollo now uses."
It is that rockets that can send payload into orbit are operating at the limits of what materials are capable of. You have extreme forces, pressures, temperatures, and some of the nastiest chemicals, all that while being as lightweight as possible. There is something called the Tsiolkovsky rocket equation. The equation is simple, but the implications are that space rockets are not like fireworks, and it is what makes rocket science rocket science.
An extreme example would be if you're trying to introduce a logistics management system in a shop that was exclusively using pen and paper. You'll need someone with a foot in both world to even get to the point where they can look at your models and/or documentation and say "yes, it matches the business".
Or one of the participant in the project will need to become that person (ideally the client, we can dream).
But really, the software is there to solve a problem, so you end up shoulder surfing while the "expert" uses both systems simultaneously, and they're asking you questions and you're thinking about how you may rearrange the UI from their feedback. It's extremely iterative. The "domain expert" also becomes an expert with the software as they learn about all the things you implement.
Wut? The development team is capable of dealing with that just fine. It’s the business unit throwing requirements over the fence and hoping it’ll magically be OK that’s the problem.