?

Log in

No account? Create an account

Previous Entry | Next Entry

It had to do with our roles within the company.

GUI guy was trying to make the point that as software engineers, it is not our job to develop the "intelligence" of the system, but to take the groundwork of other specialists and essentially create that in software. I vehemently disagreed, as I am (and have been) a systems engineer, and it is my belief that I need to understand the system as a whole and design the software to meet the needs of the system.
I was perfectly okay with making this an agree-to-disagree kind of thing, but GUI guy believes that my thinking on this is not only wrong, but dangerous to the longevity of the company as a whole.

I think this is a fundamental difference of view between an application developer and an embedded systems developer. Applications rarely deal with physical systems, they almost entirely deal with abstractions of the physical, or purely virtual systems (like a database) that have fairly static and structured delineations of interfaces. Embedded guys have to deal with the nitty-gritty and dirty details of the real world: things like friction, backlash, nonlinear resistance, boundary conditions, limited resources, and the like.

I've noticed this trend in other places as well. It's really similar to the difference between a physicist and a mathematician (in a rather crude undergraduate sense): a physicist uses math as a tool to try and deal with real-world situations, where a mathematician works in a virtual world that is generally well-behaved. If you've ever taken a physics lab course, you know that the actual numbers that you get almost never correspond to the exact thing that is modeled by the mathematical formulas.

Case in point: terminal velocity. The mathematical formula essentially pits the acceleration of a body due to gravity (9.8 m/s^2) with a function that is based on velocity and area of the object (wind resistance). When the two are equal, the body no longer accelerates, and reaches a steady state velocity. Of course, in practice, the actual terminal velocity changes because of things like air currents, different atmospheric densities, different gravitational fields (distance from the center of the earth, tides, etc.). All of those things can be modeled with a sufficiently complex equation, but those complexities are added to explain real-world ideosyncracies.

It's also reminiscent of the split that I have with a certain brainy type who has a major interest in AI, where I pursue things like emergent behavior as being key to understanding consciousness, and he abhors emergent behavior as an abberation in his otherwise clean understanding of "intelligence". I embrace chaos, he sets his boundaries so he doesn't have to deal with it.

For me, understanding how a system works is crucial to designing the code which makes the system function. Otherwise, I'm just a code monkey.

Comments

stark0228
Sep. 18th, 2006 08:50 pm (UTC)
His argument is EXACTLY what people say is the problem with off-shore contractors. They don't understand the whole system, so instead of being partners (i.e. working with the "experts" and possibly finding logic holes or thinking of a better way to represent the idea), they just code what they are told (or what they "think" they were told).

I have yet to see a case where this situation resulted in the "idea" being represented correctly.
magicmarmot
Sep. 18th, 2006 09:03 pm (UTC)
This is pretty reminiscent of my time in The Gulag. Same mindset, which is probably effective at the level where you have 50 or more coders, a software architect, a team of analysts and so on. GUI guy comes from that atmosphere, too.

I always kind of get the taint of "not my problem" from that kind of thinking, which is really not where I want to be.

Latest Month

April 2012
S M T W T F S
1234567
891011121314
15161718192021
22232425262728
2930     

Tags

Page Summary

Powered by LiveJournal.com
Designed by Tiffany Chow