Am I the only one that has problems seperating the 2 in conversations? I reckon older(insert your own definition) developers would have no problems with this, but to me, it’s tough. Hypothetical example being:
“Let’s talk about solving this server architecture problem. What is the best way to keep a service that we can talk to client side without having to worry about the service being clustered?”
Now, the second someone says, “We’ll in Web Logic, you can write this Java class, blah blah blah…”, that’s considered an implementation detail. It’s like, if you veer off the path of audiotorial UML diagram in your speech, and actually talk about how those things work, game over, go to jail, do not pass go, do not collect $200 dollars. Know what I mean?
I had to submit a paper at work today and discuss it’s findings in terms of defining facts and opinions, clearly seperated, and how they apply to finding a technical solution to a problem. I still, however, think I failed. I mean, in the facts, I tried not to reference technology solving THE problem, but rather solving THEIR or “a problem related to this was solved this way”. I don’t know if that violates the programmer ettiquete…
Like, if I asked you I need an animation on the web, most of you (I would hope) would immedately blurt “use Flash, yo”. I’d counter with, “that’s an implementation detail”. That feeling is what I’m talking about. It seems the correct answer is, assuming you know all of the details behind what the web animation needs to do, you’d simply respond by stating the facts of how the animation needs to run, look, and the target platform that the user needs to view it on. At that point, once there is no fuzziness in terms of what really needs to happen, you can then pick the technology that will solve the problem, vs. having technology drive the problem. Make sense?
It sounds simple, elegant, and a great process, but to me, it’s hard. It feels the same way research projects go. You don’t actually solve the problem… you merely research possible solutions and “sound” objective in your conclusions.
Is this something developers are taught in college or something?
