Ken Arnold

From Wikipedia, the free encyclopedia

This article or section is not written in the formal tone expected of an encyclopedia article.
Please improve it or discuss changes on the talk page. See Wikipedia's guide to writing better articles for suggestions.
This article or section does not cite its references or sources.
Please help improve this article by introducing appropriate citations. (help, get involved!) This article has been tagged since October 2006.

Arnold posing spontaneously for a photo.

This article discusses a well known programmer/software architect. For other uses of the term, see Ken Arnold (disambiguation).

Ken Arnold (Kenneth Cutts Richard Cabot Arnold, Kenneth C.R.C. Arnold) is a computer programmer well known as one of the developers of the 1980s dungeon-crawling computer game Rogue, contributions to the original Berkeley (BSD) distribution of Unix, books and articles about C/C++ (e.g. his 1980s/1990s Unix Review column "The C Advisor"), and high profile Java work (Jini, JavaSpaces).

Contents

[edit] Java, Jini, JavaSpaces at Sun Microsystems

Formerly senior engineer at Sun Microsystems Laboratories, Ken is a leading expert in object-oriented design and implementation, C, C++, Java, and distributed computing. He was one of the original architects of the Jini technology, oversaw Jini future development as Jini Technology Community Coordinator/Source Lead, the lead engineer and main implementor of Sun's JavaSpaces technology, and worked with Jim Waldo on the Remote Method Invocation and object serialization team.

[edit] Other Background

Ken was part of the original Hewlett-Packard architectural team designing CORBA, several user interface and UNIX projects at Apollo Computers, a molecular graphics programmer in the Computer Graphics Lab at UC San Francisco, and served as a member of the UNIX Review Software Review Board.

[edit] U.C. Berkeley and BSD Unix Contributions

At U.C. Berkeley, Ken was President of the Berkeley Computer Club and of the Computer Science Undergraduates Association, and made many contributions to the 2BSD and 4BSD Berkeley Unix distributions, including:

  • Curses (programming library) and Termcap: a hardware-independent library for controlling cursor movement, screen editing, and window creation on ascii display terminals, based on termcap (based on Bill Joy's vi screen control code). Curses was a landmark enabling technology that made it possible for a vast number of new applications to create full screen user interfaces that were not dependent upon particular display terminal brands.
  • Rogue (computer game): (co-author with Michael Toy and Glen Wichman) a full-screen role playing game that presented a then-novel view of the "dungeon" from above (rather than via textual description as in the older Zork and Adventure, and that spawned an entire genre of Roguelike games.
    • Note that despite occasional confusion on the topic, it was a different Ken Arnold (a "Ken W. Arnold") who contributed to the game [Ultima].
  • Fortune (program): a fortune cookie program. Although Ken's quote-displaying program was not the first in history, as the BSD standard it became by far the most widely used, and Ken's database of quotes was voluminous. It also standardized a plain-text text file format that was philosophically aligned with Unix philosophy and thus became widely used both for other fortune programs as well as non-fortune purposes.
  • Other BSD Unix games by Ken Arnold: Cribbage, Hangman, Hunt, Mille Bourne, Monopoly, Robots.
  • Ctags: a very early special-purpose hypertext link generator that essentially turned the vi editor into an IDE (Integrated Development Environment). It indexes program objects (such as functions) in a way such that the vi editor (and its clones such as vim) knows how to navigate to an object/function definition starting from any instance of the object's name elsewhere in the source code.

He received his A.B. in Computer Science from U.C. Berkeley in 1985.

[edit] Books and Articles

[edit] Selected Ken Arnold Quotes

Ken has an irrepressible (and oft-misunderstood) sense of humor.

  • "Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, it is evident that every program can be reduced to one instruction that does not work."
  • "First you listen to the users; then you ignore them."
  • "I think that the terseness of Unix programs is a central feature of the style. When your program's output becomes another's input, it should be easy to pick out the needed bits. And for people it is a human-factors necessity -- important information should not be mixed in with verbosity about internal program behavior. If all displayed information is important, important information is easy to find."
  • "Simplicity has real value on its own that makes the system more usable. It's the difference between reading a 100-page manual and reading a 500-page manual. It is more than five times the size." Taste
  • "Someday this will no doubt be a vivacious page, brimming with fascinating information, penetrating analysis, and the most succulent links. Until then, this will have to do."
  • "Now that we have all this useful information, it would be nice to do something with it. (Actually, it can be emotionally fulfilling just to get the information. This is usually only true, however, if you have the social life of a kumquat.)" Curses

[edit] Ken's Little Red Book

At a previous job, some of us put together a list of how to understand Ken, who enjoys good phraseology well enough to sometimes let easy comprehension slip away.[original research?]

If it's that complicated, it must be wrong
KISS. Perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away. (Antoine de Saint-Exupery)
The two rules of debugging are (1) Don't think, Do! (2) Don't do, Think!
The trick is knowing when to apply each rule. In general, when thinking hard has you frustrated, you need data, and when the data isn't telling you much, you need to think.
You're thinking too hard
When your problem seems complex, try pretending it's a simple problem. You are likely to find this makes it so.  The same is true when someone (often Ken himself) suggests something that seems to require hard thinking or a complex answer.  They may have been thinking of something much simpler, if you only step back and look at
What makes you so smart?
Also "All the smart people don't work here. " If other people have a solution to your problem, why do you think you're smarter than them? And why do you think we should spend your time proving you're smarter than them? We only build things that we can't find that make us valuable to our customers. For everything else, we borrow someone else's smarts, work, and support.
You can train smarts, but you can't smart trains
There is a reason why "train" is a verb and "smart" isn't. The longer form of this is: "You can hire smart people and train them, but you can't hire trained people and smart them."
First you listen to the users, then you ignore them
You need to listen through what users say to what they ought to have said. They know they have a problem, but why do they have it and what really should be done? If it's hard to adjust the frobnitz, you could do what they ask to make it easier. But it may be better to make frobnitz adjustment less finicky or, better yet, unnecessary.
That's an implementation detail
That is not part of the public API, and it might be done many different ways. The more things you can say this about and still satisfy the design goals, the better the design on average.
That's what we're paid for
We get paid to do the hard stuff to make the user's life easy.
Hardware is free
Compared to writing, debugging, and maintaining some fancily optimized wad of code, it is usually cheaper to require a more capable machine.
Trust Moore's Law
Moore's Law (chip power doubles every 18 months) has been a reality for decades. Take it seriously. When you design for the future, don't fight today's limitations.
All the code you don't write works
Every line of code you avoid writing is a line of code without bugs. Consider the full cost of owning the code. Write clear code and let the compiler or machine make it faster. Tools that do a lot of your work for you makes your code smaller.
Any organization with two or more people is dysfunctional
Successful organizations succeed despite their dysfunctions. After all, by definition they're not competing against functional organizations. The game is to find yourself a place with compatible dysfunctions.
Programmers are people
Think of the programmers who use your stuff as humans, and apply human factors principles.
Good programmers are creatively lazy
Doing things twice is painful, and more than twice is anathema. This is related to a well-known fact of computer science: There are only three numbers, 0, 1, and "many". When you get past 1, you have just discovered that you will need this "many" times. Don't ignore this discovery.
Why make things simple when they can be complicated?
This is sarcastic. When Ken says this, duck.
Design from the outside in
Write the pseudo-code your users wish they could write. Then make it work with as little change as you can. Design from their viewpoint inwards, rather than from your implementation concerns outwards. If this makes your work harder, that's what we're paid for.
Ain't nobody here extra
Why do we hire someone to answer the phones? So other folks don't have to. If you're one of the other folks, remember: That person makes you more effective. And if that wasn't important, we wouldn't have them answer your phones for you, would we? When it's time to ask who makes our success possible, the answer is "everyone".
Do one thing right.
Each tool/component should do one job right. That's hard enough. This is the Unix tool philosophy.
Names matter
Names are critical building blocks in cognition. The name and the thing become intimately intertwined in the mind. Picking a good name is crucial, and worth investing time in. Not just for products, but for naming components of a design (types, methods, etc.). Until a name is relied upon by others, we can change names fairly easily: That's what a good IDE is for. Or sed, depending.
Who needs that?
Systems that let you do everything make doing anything hard. Systems that do only what you need make doing needed things easier. Much easier. We can all imagine someone wanting a feature. The hard question is whether anyone really cares (even if they say they do, first you listen to the users, then you ignore them). [Note: This really is a question, not a way to so "no".]
"surface area"
"Surface area" is Ken's term for the amount of stuff you need to know before you can use something. The larger the surface area the more complexity in the usage model. Surface area is increased not only by the number of explicit things, but also by the number of ways things interact. Not surprisingly, less surface area is generally better than more, which is one reason we ask "Who needs that?"
Accept failure
Things will fail, especially in distributed systems. Any design that works when nothing goes wrong does not work. Any failure that is too unlikely to happen will. You cannot add failure recovery after the design, at least not done well. You design for failure. "It's not a distributed system unless the failure of a computer you have never heard of can screw you."
State is hell
Managing state in a distributed system introduces complexity, especially when dealing with failure, and we have to accept failure. Minimize the role state plays, and how many components own state (as opposed to using state, which is someone else's problem).
Don't be perfect
Also, "A decision is a valuable thing." There is no such thing as a perfect design. There are only good designs. Over time, striving for perfect designs becomes decreasingly effective and eventually it's work avoidance. Academics call this "publish or perish".

[edit] See also

[edit] External links

Retrieved from "http://en.wikipedia.org../../../k/e/n/Ken_Arnold_0270.html"