Sun Ray Thin Clients

Last week I made a comment on Paul Murphy's blog about how the thin-ness of Sun Rays is really up to interpretation. Today he's decided to dedicate an entire blog to explaining why I'm wrong, because he figures if I have an incorrect understanding of Sun Rays, then a lot of people have an incorrect understanding of Sun Rays. He's probably right, although I don't think my understanding is that far off base, and he's been kind enough to let me see a draft copy of his blog so I can get a head start on the response. Here's what I said:

Smart, Thick, Thin, Display

It's all word games. Depending on how you define "processing," there is processing going on. It still has to render graphics, translate keyboard and mouse events, etc. A SunRay is just a compacted Sun workstation of yesteryear without a harddrive and special firmware designed to work solely as an X-Windows server.

The problem is the attempt to make "smart displays" seem more fundamentally different from other similar solutions just muddies the waters. People like me groan because yet another term has been introduced that means almost the same as other terms that will need to be explained to the higher-ups. The higher-ups get confused and either latch onto it or, more likely, have their eyes glaze over.

Anyway, enough with our industry's incredible ability to make sure words are completely meaningless...

The problem with Sun Ray and other similar solutions is that they are really a local optimum based on today's technology and practices for a relatively narrow range of priorities. Change the priorities and the solution is no longer optimum. Introduce distributed computing techniques with the same low administrative overhead and they lose out entirely.

As far as I can tell, the first part is technically accurate. Older Sun Rays ran a 100Mhz UltraSparc II, had 8mb of RAM, and ran a microkernel. See here and here. Newer ones use an even beefier system-on-a-chip.

So the Sun Ray client is obviously processing something, and actually has a fair amount of processing power. Just because it is not maintaining any application state, doesn't mean it's not doing anything. Murph asserts that a Sun Ray is not an X-Terminal, but he'll have to explain the difference to me. He could be right...I don't know. It's been about 7 years since I've used a Sun Ray, but from what I remember it felt just like using Exceed on a PC under Windows, which is quite common at my employer. He did mention this:

Notice that the big practical differences between the Sun Ray and PC all evolve from the simplicity of the device in combination with the inherently multi-user nature of Unix. In contrast the differences between the Sun Ray and X-terminal arise because the X-terminal handles graphics computation and network routing -making it more bandwidth efficient, but marginally less secure.

But the Sun Ray quite clearly has a graphics accelerator and talks over the network, so while there is probably a subtle difference in there that I'm not grasping, it doesn't seem particularly marterial. But that's not really the meat of the debate, it's just a technical quibble over what consitutes processing and an operating system. He's dilluting the debate by calling Sun Ray's "smart displays" instead of "thin clients" and thus drawing a false dichotomy, and I'm doing the same by pointing at internal technical specs that have little to do with actual deployment. The real debate is: "Where should processing take place?" I'll give you a contrite answer - as close to the data as possible. Any computation involves a set of inputs and a set of outputs. It makes no sense to shuttle a million database rows from a database server to an application server or client machine in order to sum up a couple fields. It makes much more sense to do it where the data is, and then ship the result over the network. Likewise, if you have a few kilobytes of input data and several megabytes/gigabytes of results, it makes sense to do the computation wherever the results are going to be needed. So this is my first issue with the centralized computing paradigm. Right now I'm typing this blog in Firefox on Linux, and my computer is doing a fair amount of work to facilitate that interaction with Blogger. I've also got a dozen other Windows open. Most of the memory and CPU I'm consuming is dedicated to the local machine interacting with me, the local user. Only a couple pages of text are being exchanged back-and-forth with blogger. So why not let the Sun Ray run Firefox (and an email client, a word processor, etc.)? The new ones have the processing power. They probably would need $100 worth of RAM or so to keep a stripped-down Unix variant in RAM, which could be loaded from the network. Intelligent configuration could make the client smart about whether to run an app locally, on a server, or on an idle workstation down the hall. Murph gives seven reasons: 1. portability Murph asserts that with Sun Rays you gain portability, because you can halt a session one place and immediately resume it another place. I don't doubt that is true, but I don't see any technical reason why the same could not be accomplished with a distributed architecture. All that happens is your terminal becomes the processing server for a remote application. Remember, in Unix, there isn't a fundamental difference between a client and a server. I'm not going to address the laptop debate right now. Murph has made some very good arguments against laptops in the past based on the security concerns of them being stolen, despite strong encryption. I think he underestimates the value of laptops and is probably wrong, but there are a substantial number of people who could live with a "portable terminal" because their homes and hotels have sufficient bandwidth. 2. reliability This is where the distributed model really shines. In my experience, networks just are generally one of the less reliable portions of the computing environment, especially WANs and my own internet connection. A pure thin-client solution simply stops working when the network goes down. In the past, Murph has asserted that everyone needs network connectivity to work, so this doesn't matter. But in my opinion most professionals can continue working for several hours, possibly at reduced productivity, when disconnected from the network. That buys time for IT to fix the network before the business starts bleeding money in terms of productivity. Keeping processing local, along with caching common apps and documents, increases the effective reliability of the system. 3. flexibility Murph lists nothing that cannot be done with a locally-processing workstation. 4. security Don't use x86 workstations, especially running Windows. The security gains are from a more secure operating system on a processor architecture designed for security and reliability. Eliminating permanent storage from the client does buy some security, because there is then no way to walk out the door with all the data, but distributed processing doesn't preclude centralized permanent storage. There are, of course, substantial advantages to having local storage, like being able to make a laptop that can be used in an entirely disconnected fashion. But I think that's a separate debate. 5. processing power There's nothing about a distributed computing model that says you can't install compute servers. Heck, this is done all the time with Windows (both to Windows servers and more commonly to Unix servers). Murph's example of a high-performance email server has nothing to do with the thin-client architecture, and everything to do with properly architecting your mail server. 6. cost There aren't significant cost savings in terms of hardware when switching to Sun Rays. Hardware is cheap, and you can throw out a lot of pieces in the common PC to reduce the cost. In fact, I bet Sun Rays cost more because of the servers. I don't doubt that when effectively administrated they cost less to keep running than a Windows solution, but that's mostly because of Unix. I'll admit that it is probably cheaper to administer Sun Rays than my distributed model because I think it will require greater skill and discipline (meaning higher paid admins), so in abscense of detailed numbers I'll say it's a wash. 7. user freedom This is partially a consequence of using Unix instead of Windows, and mostly a consequence of changing culture. So as I said before, Sun Rays, and centralized computing in general, represent a kind of a local optimum for a given solution and today's practices. But I don't think they make a solid generalized approach. Distributed computing can be successfully with all the advantages of Murph's Sun Ray architecture using today's technology, it just isn't common. Now I've ignored the elephant in the room: Much essential software only runs on Windows, and the minute you introduce Windows into the mix (local or centralized), you start compromising many of the advantages outlined above. Of course, what good is a computing environment if it won't run the desired software? Consequently, I think it will be a long time before anything like this flies in most enterprise environments.

Sphere: Related Content

Creators, Hounders, and Processors

There are three types of people in a corporate environment:

1. Creators
2. Hounders
3. Processors

These are really a continuous spectrum, and people can occupy more than one location on the spectrum, but I think those are the large buckets into which most people fall. I'm very tempted to say that creators are the people who produce most of the value, but that probably would be my creator-self talking. Creators are the people who create something of value from almost nothing. They are the engineers, scientists, researchers, and marketers who create the ideas that advance an organization. They are both the most coveted and most annoying employees, and generally compse a very small percentage of an organization. Within an IT organization, creators tend to be architects, analysts, and software developers; although most people in those roles aren't really creators. I'll talk about hounders later. Processors are the people who take something, apply some known method to it, and spit out something of greater value. In law, a litigator is most likely a creator. The guy who puts together your will is a processor. A processor's job is to keep things neat, complete, well organized, and most of all conformant to any important rules and regulations. Without processors we would live and work in total chaos. Processors are the people who take the mess produced by creators and turn it into something that is geniunely useful and widely appliable. They are the people who continually apply it so that is becomes part of our lives. In IT, QA people, system administrators, database administrators, application administrators, configuration managers, help desk staff, and countless others are generally processors. Management often wishes everyone (except them) could be a processor, because they are predictable and their work usually has immediately apparent value. Processors make up a very large portion of most organizations. So creators like shiny new things. They hate forms and anything else that seems to constrain their ideas. They only really believe in deadlines for other people, because creativity cannot be hurried, and often times even have trouble pushing deadlines on others because the last thing they want are half-baked ideas. They don't want to be bothered with the extraneous details required by processors. Processors often claim to believe in deadlines, and to be very predictable in the time it takes to process work. However, they exclude from this time they spend waiting for responses that the need from others. If you don't believe me, go see how many help desk tickets your IT organization has that are in a state like "waiting for user response," quite likely to a question like "Is your computer plugged in?" The result is processors are only concerned about deadlines when they can't blame someone else, and creators are prima donnas who can be bothered neither by deadlines nor by a processor's need for additional information. Consequently creators are the perfect scapegoat for processors (he hasn't responded to my email asking for more information), and processors for creators (I sent it to him last week, what do you mean he needs more information? I'm busy. It's his fault this is late, not mine.) Now enter hounders to solve this problem. They exist to overcome the impedance mismatch between creators and processors, and they may be as numerous as the other two groups combined. Salespeople are all hounders. Most managers are hounders. Everyone who emphasizes (or randomly inserts) the word "manager" in their role or title is a hounder. Hounders are the people who constantly talk about action items and religiously send out meeting minutes. They are also often the people who lack the technical skills to be creators and detail orientation to be processors. Just like you need some bacteria in your body, you need some hounders in your organization. But too many is a sign that your organization is diseased, as most don't directly produce anything. Also, without day-to-day observation, it can be very difficult to distiguish a hounder from a creator or processor, because they tend to confuse (intentionally or otherwise) making somebody do something with doing it themselves. And they tend to make organizational problems worse. Often times if the creators and the processors are having a really hard time communicating, it's because one or both sides has been allowed to become too extreme. When processors get in trouble, their first instinct is to create more rules for getting tasks out of their queue and off their clock. Creators, when they get in trouble, tend to avoid disclosing details, especially when they aren't yet sure of them. Consequently, all the hounder has to do is encourage these behaviors, and the hounder becomes (in the short term) more critical to the organization, because now the only place the processor can get his details is from the hounder, who either tricks the creator into providing them or takes responsibility for any problems that may arise. In extreme circumstances, processors may even stop communicating with other processors, by simultaneously declaring items in each-others' queues, making hounders necessary to make what should be a smooth interaction work. All three types are needed in any organization. When properly balanced they compliment each other. I've picked on hounders here, because I think they are the most opportunistic, but creators and processors can be quite detrimental as well when they gain too much influence. P.S. Now, you might be wondering what happens to the people who lack the technical skills and creativity to be creators, detail orientation and technical skills to be a processor, and the personality to be a hounder. Some fake it, usually by obscuring their lack of skill or creativity, for example by parroting something they heard/read or calling "buy IBM" an IT strategy. It's amazing how smart a person will think you are if you consisntely agree with them.

Sphere: Related Content

Random thought on functional programming

Right now I'm trying to learn Scala and functional programming, particularly not using any mutable state. I'm going cold-turkey on mutable state. It's hard. I've noticed a few things:

1. It takes me forever to work out functions that build collections despite the fact that I can clearly envision to mutating-version of the algorithm
2. Once the functions actually compile, they tend to "just work," or at least any flaws are design flaws, not simple coding mistakes. This is very much like the Python experience, only it takes longer.
3. The functions continue to work, unlike the Python experience where a combination of edge cases and type errors generally crop up as the complexity of inputs increases

I'm not sure if this means I'm more or less productive. Right now I'd say probably not, but maybe I'll learn to "think functional" and stop thinking in terms of how I would mutate a collection to make it what I want.

Sphere: Related Content

Software Engineering and IT Professionalism

A few weeks ago I was reading the chapter on Philip Greenspun and ArsDigita in Founders at Work and some of his comments really rang true for me. On a number of occasions I've been in debates with advocates of both agile and traditional software development methods, as well as people from other IT-related disciplines. In my opinion, the argument usually boils down to this question:

How important is it that an IT Profesional take responsibility for ensuring his work delivers value to his customer/client/employer in a cost effective manner?

No one would argue with the idea that it is important to deliver value. No one would argue that it is important to be cost effective. So why would this be such a contentious topic? Well, I think it boils down to an old addage to predates information technology by an awfully long timer...

The customer is always right.

The glaring problem with this is that he is not always right. Not by a longshot. If he were, he would most certainly not be hiring you to apply your brain to create something for him. He would simply apply his omnipotence to quickly creating the perfect software, running on the perfect operating system, on failure-proof hardware. Ok, yes, we all know that. The customer has hired us for our technology expertise. He knows what he needs, and we know how to create it. Right??? Nope. He doesn't. And no one is surprised by that. No self-respecting text on requirements development starts with "The customer/user knows exactly what he needs. All the analyst needs to do is take detailed notes, and the customer/user will precisely, consistently, and completely describe the application that will be his needs." It's all about how users don't know what they want, they have conflicting desires, they tell you what they think you want to hear instead of what they really mean, and so on. I doubt there's any disagreement so far. So what did Mr. Greenspun say?

We had this idea that programmers could be professionals, like doctors or lawyers, and, to that end, we wanted the programmers to be real engineers - to sit down face to face with the customer, find out what was needed, come up with some suggestions or changes based on the programmer's experience with similar services, and then take a lot of responsibility for making it happen.

So what does this mean? Here's my take:

1. A professional will tell a customer when he has reason to believe that the customer needs something different from what he is asking for.
2. A professional will inform his customer when he believes his services will not deliver value in a cost effective manner.
3. A professional will speak in the customer's language, or at least close enough so that the customer can understand.
4. A professional will take the time to understand the customer's need, not just the customer's request.
5. A professional will express "engineering trades" in terms that the customer can understand
6. A professional will make commitments in terms of cost and schedule, and take responsibility for meeting them.

Most "IT Professionals" I know regularly practice at least a couple of these. Very few practice all. Most don't have much trouble trying to make helpful suggestions, and are very conscious of cost and schedule. They try their "best" to communicate effectively, but usually are too concerned with their own specialty than learning the basics of their customers'. Very rarely will they state that their services are not really required, especially in consulting or contracting situations. The end result is exchanges kind of like this:

Customer: We would like our customers to be able to order replacement parts and lookup technical information securely over the internet. Under no circumstances do we want unauthorized people ordering parts or viewing information. Do you have anything for that? IT Guy: We have this piece of off-the-shelf software called WebSphere. It can be used to create an integration hub among enterprise applications. It can also be used to host portals, and can be combined X and Y to implement federated security using two-factor authenitcation and strong encryption.

So let me translate into something the customer would actually understand:

IT Guy: We know of the technology required to do what you want, and have some of the infrastructure already in place. However, we will have to build the website, which we call a "portal," along with the software to connect is to Z, which is our internal system that handles orders. Fully automating these transactions will cost an arm and a leg, and data regarding who is authorized to order parts and access data will have to be extremely well maintained to prevent inapprioriate transactions. The last thing you want is for the factory to build something that the customer won't pay for, because the person who ordered it shouldn't have been able to. Do you think it would be better if we enabled customers to communicate with internal representatives in a highly structured way? Perhaps if that worked well we could add more automation later on. This would be both safer and much less expensive. What do you think? Customer: Oh my God! Of course I want a real person to be involved.

Now the IT Guy just passed up a resume building project in favor of something rather unglamorous. I can think of many other situations where customers have asked for applications dependent on data that didn't exist, direly flawed mathematics, grossly unrealistic assumptions about intended users, and highly exaggerated availability needs stated by customers who didn't want their application to seem unimportant. Faced with this problem, many IT providers hide the techie from the customer. Instead of placing someone who can't communicate in front of the customer, they place someone with no technical skills in front of the customer and have that person communicate with the techies. The problem is this is just miscommunication via proxy. In other words, it is worse. The problem is that professionals are inherently at least partially generalists, while the IT industry has a nasty habit of trying to create line workers. A lawyer can be disbarred for pursuing a frivolous lawsuit (ok, the bar the frivalous is pretty low, but it can still happen). A doctor can be sued for malpractice and lose his license for ordering inappropriate treatments. Entire accounting firms can be destroyed for allowing financial numbers to be misrepresented. These are professionals. They are responsible for their clients, even if it means acting against their client's immediate wishes. But a programmer who hacks together a barely functional piece of software is rewarded for being efficient. An architect who designs a system full of unncessary components is respected for his experience. A system administrator who bypasses proper security to make something work is heralded as a hero. Massive cost and schedule overruns while under delivering functionality are considered perfectly normal. IT people are actively encouraged to be like 15 minute oil change technicians: Suggest a bunch of unneccesary work, while failing to properly do the basics like clean the windshielf or vacuum the floor mats. So more often than not we are not true professionals. Philip Greenspun was right. IT people tend to avoid professionalism, and it is exactly what we need. Innovation in IT can only be achieved by effectively applying technology in novel ways to business problems. All the easy problems have mostly been solved. The only way future innovation can be attained is through a close, effective working relationship with customers. But you can see how that isn't happening. More and more work is being sent offshore. Job posting focus on very specific techincal skills while ignoring the business context. New methodologies place make developers slaves to what customers think they want rather than providers of what customers need. New "innovations" are mostly ways of delivering the same old services - or often diminished services - in a less expensive way. Maybe the tide will turn. I'm sure it will eventually. Progress must progress. Let's hope we can speed it up.

Sphere: Related Content

Number Parsing in a "Functional" Style

A few days ago David Pollak did a blog showing the differences between a simple function to parse a string and return a number written in Scala in an "imperitive style" and in a "functional style." I commend the post and think many more like it are needed. It is very difficult for a person accustomed to imperitive programming to think in a functional way, and without simple examples comparing the code for common programming tasks, I think most programmers loose patience with functional programming. That all being said, I don't like David's example functional function:

1. I think the conversion of the string to a list obfuscates what the function is doing, not to mention consumes resources unnecessarily.
2. I find his use of pattern matching confusing, especially the way list operations are mixed in with it. I spent more time than I willing to admit trying to make sense of it.
3. His nested function, p, has too many parameters.

So, being that criticism of code without code in return tends to be rather pointless, here's my attempt at the function. I obviously like it better, but I'm neither as familiar with functional programming nor as familiar with Scala as David is.

object Parsely {
 def erikParseNumber(in: String): (Long, Int) = {
   if (in eq null) (0L, 0)
   else {
     val tin = in.trim()
     if (tin.length == 0) (0L, 0)
     else {
       val sign = if (tin.charAt(0) == '-') -1L else 1L
       def p(cur: Long, pos: Int): (Long, Int) = {
         if (pos == tin.length || !tin.charAt(pos).isDigit) (cur * sign, pos)
         else p((cur * 10L) + tin.charAt(pos).toLong - '0'.toLong, pos + 1)
       }
       p(0L, if (tin.charAt(0) == '-' || tin.charAt(0) == '+') 1 else 0)
     }
   }
 }
}

So I've done the following:

1. I'm using the "pos" parameter as an index into the string, instead of making a list.
2. In the nested function, I'm accessing some of the values from the enclosing scope instead of passing them as parameters. This reduces the number of parameters from 4 to 2.
3. I'm using if/else expressions instead of pattern matching

So what do you think? I find my version more readable, and I think it is a little more efficient. However, I haven't tested it much, so maybe there's a bug. If so, please point it out and I'll fix it.

Sphere: Related Content