capnbuckle: (Default)
[personal profile] capnbuckle
This past year, I have been thinking quite a bit about how "programmers" and "system administrators" are viewed in an organization (at least in my experience). Regardless of which group of professionals are more valued by an organization, they are nevertheless often viewed differently.

Philip Kizer, president of the League of Professional System Administrators, noted that programmers may well be included in the umbrella of system administrators. Conversely, I believe system administration could be viewed as a specialized type of programming.

Programmers produce a system by writing code in one or more languages, which interact with users, operating systems and other applications through clearly defined protocols. (An example: coding an application that interacts with databases through API library calls, or code that interacts with a display and human interface through other API library calls, etc.)

System administrators produce systems by writing "code" to configure one or more component applications which interact with users, operating systems and other component applications, again through clearly defined protocols. (An example: configuring a service to authenticate users via SASL accessing an LDAP directory that stores user data in a database replicated across a network...etc., etc.)

If you abstract both of these roles away from the specific technologies involved, and agree to view configuration files and source code files as a similar expression of directives to the system, I believe the two roles will match at least 90%.

Thus, I propose that system administration _is_ programming, but the "languages" are just abstracted one level higher than what is commonly accepted as a "programming language".

It could be said that system administrators do not require the knowledge of algorithms or complex data structures that a programmer might routinely need. But I think that would be a misconception. A system administrator _could_ produce a system without some algorithmic knowledge or experience, but even dealing only with configuration files (many of which support abstract data structures), knowledge of data structures or algorithms vastly improves the flexibility and efficiency in producing a desired system.

Also, the basic cycle for either role to produce a system is also the same, approximating the following: collect requirements for, design, prototype, develop, test, deploy and support the system, optionally leading into the requirements for the next "version" of the system.

(In truth, you could widen the net much more than just this, as one example: electricians and electrical engineers working with banks of relays or other forms of "programmable logic controllers".)

Date: 2011-01-03 09:57 pm (UTC)
From: [identity profile] cipherpunk.livejournal.com
I'm going to disagree here, mostly because I think you're being glib with the word "programming." Systems administration and software engineering can definitely be seen as kissing cousins, yes: there are enormous parallels between the two fields. Systems administration and programming, though, not so much.

At heart, programming can be described in formal mathematical logic. There are very robust mathematical foundations to programming and any program, however complex, is ultimately just a really big lambda expression. There is no such mathematical heart to systems administration, not that I've seen. That's why I think programming and systems administration are fundamentally different.

Date: 2011-01-04 02:27 pm (UTC)
From: [identity profile] capnbuckle.livejournal.com
Just to state this first and foremost: If we are to draw a distinction between a "programmer" and a "software engineer", then I would agree that "programming" should be more accurately replaced with "software engineering", and "programmer" with "software engineer". However, I'm not certain such a distinction really exists if you look at job postings or job descriptions from most companies. In fact, the more cynical side of me tends to think a company will re-label many of their "programmers" as "software engineers", depending on whether they think it makes them look better to have more than one of the other on their roster.

But moving on...

Admittedly, I had to research lambda calculus on Wikipedia and still may not have a full grasp of the subtleties. But I would argue that any _system_ is ultimately just a really big lambda expression, mapping a domain of inputs to a range of outputs. I think the systems created by system administrators certainly _can_ be represented with lambda calculus, without "resolving" the system to a lower level of abstraction. But I believe that topic of study is largely unexplored, namely because though there may be some benefit in formally defining systems that are created and maintained by system administrators, no one has thought of any way to make more money doing so than they are already making now, without it.

Also, I'm not talking about programming and system administration in academia. I am referring to programming as the activity performed by self-professed "professional programmers", and system administration as the activity performed by self-professed "professional system administrators". So in that respect, perhaps I am being "glib" with the word programming, just as many "programmers"..._and_ many "system administrators"...are being glib when labeling themselves as such.

I would wager at least 50% of self-professed programmers couldn't write a lambda expression to balance their checkbooks. I will grant that perhaps 95% of self-professed system administrators wouldn't know what a lambda expression is, at all! But that is not to say that such knowledge would not improve their effectiveness, and improve the practice of system administration as a whole, were it more common.

Date: 2011-01-04 04:20 pm (UTC)
From: [identity profile] cipherpunk.livejournal.com
In terms of formalisms, system administration is not representable in the lambda calculus. System administration may have inputs and outputs, but more than that it has global state, side effects, and all manner of things that cannot be represented (and must not be represented) within the calculus.

If you mean programming as done by "professional programmers," well, there you're on a little bit stronger footing. The problem there is I wouldn't call them either professionals or programmers. :)

Most "professional programmers" are, in reality, half-assed software engineers.

Date: 2011-01-04 06:46 pm (UTC)
From: [identity profile] capnbuckle.livejournal.com
I do mean 'programming as done by "professional programmers"'. ;)

The problem there is I wouldn't call them either professionals or programmers.

In fairness, I concede the same sentiment to be true of many system administrators, as well.

Profile

capnbuckle: (Default)
capnbuckle

January 2012

S M T W T F S
1234567
891011121314
151617 18192021
22232425262728
293031    

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 21st, 2017 04:47 pm
Powered by Dreamwidth Studios