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?
Dude.. I know totally what you are talking about. Most people who think like that are “architecture managers” that think if they aren’t around the whole infrastructure will fall to pieces. Arsewipes the whole lot of ’em in my books ;) But in truth it is better to think of it high lever before going on to the details of “what” will be used to do the task. It’s a hard way to think but once you get used to it, even though you already know the answer, it’s better. You’ll find yourself opening up to new things and ideas, and on the other hand you’ll also become a bit more proficient in steering the conversation towards what you want the end technology to be. I’ve got some more thoughts on this, but gotta fly to a meeting so hopefully I can post a bit later.
LOL – that’s just the dumbed down API for the bizniz peeps so they don’t get too fucked over by the technology they are too lazy to grasp the intricacies of.
If you talk technology…they lose control of the situation. If they can keep you talking abstract process concepts they feel safer and less threatened.
The best applications out there are designed and developed by the peeps who have a solid grasp of the technology and can leverage the intricacies against the business objective they understand.
Fuckin bollox.
Definitely, people get hung up on the implementation details and skip the bigger picture. But, you can/should do both. Just do it in the proper order.
In fact, sometimes implementation details affect the original objectives. Take the Iraq “war” for example. Apparantly there were objectives now, as it’s being implemented, those objectives shifted. Maybe that’s a bad example. But, in programming, if someone says they want an “animation” that is actually an implementation detail–before you even get to Flash. An objective’s are more general goals and messages. An animation might solve the task to communicate a particular message.
Quite often I get clients who’ve jumped to the implementation way to early. Similarly, whenever someone begins to explain a project by telling me the opening animation sequence I know we’re in trouble. Actually, the best way to tell a story is to write the first part last. That way, you know where you’re headed.
Thanks,
Phillip
P.S. There you go again with the “old” thing.