This is a universal problem, it's so universal that there's even a field of development which solves the problem - Domain-Driven Design.
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).
Sounds good, but I can see several obstacles to this, especially when it's not an internal tool (and most of the time it isn't, unless you're Amazon): e.g. that the people talking to the customer are not the same people developing the application (maybe the people on the customer's side are not the real domain experts either); or that the customer has a mentality of "we hired these guys to develop a shiny new system for us, but our guys are much too busy to act as counselors for them" etc.
> that the people talking to the customer are not the same people developing the application
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.
This always baffled me. Rocket science is basically F = GMm/d^2 with m changing over time as you burn fuel and also thrust vectoring. Where is the complexity?
If you just model rocket science as a point mass with variable m then yes…
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 can see how you can think of me that way based on this discussion.
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).
You simplified to an absurd level that does not reflect reality in the slightest.
You did that to sound smart, and refused to concede when actual domain experts showed up to slap you down.
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.
HN has a vast amount of random talent. If you’re going to speak with authority, you’d better know you’re right!
And if somebody comes in and upgrades your knowledge, be cool about it. They just did you a favor.
Thank you so much and I am so sorry for what I did. I didn’t realize there were domain experts on HN. That’s amazing and I can’t believe I spoke on this subject without first checking if I was the smartest person in the room. What you added to the discussion is invaluable. You are a saint.
The "rocket scientist" became a metonym for a very intelligent and skilled professional during the Apollo program.
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.
The hard part about rocket science is not the equations of motion.
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.
From a similar point of view, you could say fluid mechanics is basically just F=ma.
Even 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."
You're right, but I think the hard part is still to find people to bridge the gap between the system experts and domain experts.
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).
As someone who has done this a few times from pen/paper/excel to actual DDD software, it's really not that hard to shoulder surf and ask lots of questions about edge cases. At least initially. Though my favorite answer to those questions is: "never happens." Thus you end up with `BobSaidNeverHappensException` just to be cute.
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.
Usually this is solved by including domain experts on the development teams. Their responsibility is not to program, but to document and verify that the test cases are adequate. This is well known, but often ignored because it's expensive.
Sorry, but domain-driven design is actually when you have "class Licensor; class Licensee; class RoyaltyPayment". What you're describing is competence and attention to detail, and that's too much to expect from development teams.
> that's too much to expect from development teams
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.
And that's why DDD doesn't just involve development teams. It explicitly calls for people who are competent in the domain and know the details that need attention to be involved in the design process.
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).