Windows Foolishness

If you want an example of pure Windows foolishness, check this out.

In order to change the hostname of a linux machine, you'd do something like this

echo -n newHostname > /etc/hostname

To do the same thing in Windows from the CLI you first have install netdom.exe from the installation CD (it doesn't install by default), and then issue the following command

netdom renamecomputer machine  /newname:new_computername  /userd:domainname\administrator_id  /passwordd:* /usero:local_admin
/passwordo:* /reboot:seconds before automatic reboot

Which OS was supposed to be easier to use and administrate again?

Now, the enterprising Windows users who might be reading this may counter and say "you can do this very easily under Computer Management". They would be correct, you can point and click your way in to changing the hostname and restarting in about 20 clicks. But try doing that over 50 or some servers and let me know how your RSI is treating you if you continuously use that as your mechanism for administrating your systems.

Pet Peeves

The following is a list of my top five pet peeves that I encounter in the software engineering field. It is meant to be a completely childish exercise in vetting frustrations with things I encounter on a weekly, if not daily basis. Without further ado:

#1) Learned helplessness - or "I'm too lazy and/or selfish to take five minutes to try and find the answer myself or learn to do it myself.

This takes the cake, in my opinion, as the single largest time suck any software engineer faces when working collaboratively with a team that is guilty of this foul. It is also probably my biggest pet peeve not only in software engineering but in any facet of life - I despise it when perfectly capable people resign themselves to asking for someone's help or advice without first having tried to do something or figure something out themselves. In our field, it generally takes 5-10 minutes tops to write a test case to answer a question or even less time to determine if there is documentation to answer it through this wonderful invention called google. If one can't find the answer in that amount of time by themselves, then it's time to ask someone. People learn more by finding the answer themselves than they ever will by having fed by others - and in doing so they don't risk interrupting the precious flow of their co-workers with questions they haven't bothered finding the answer for. Doing so is a selfish act and completely disrespectful of others who have strived to teach themselves so much.

#2) Anything involving a Microsoft product.
Yes, I'm quite biased - but for a good reason. Having to deal with anything Microsoft related when working as either a developer of applications or working with applications in a server deployment is just an absolute pain. For starters, a software engineer worth his or her salt will spend a sizable amount of time in a console while doing their work. Unfortunately for folks stuck administrating and or using windows machines, you have to install a combination of cygwin + Console just to have a halfway decent console experience... and even that experience is half-baked.

Furthermore, most applications and tools from Microsoft assume you are a complete buffoon and offer you only wizards and menus to configure your applications. These might be great when initially setting up an application but they often come with absolutely no way to configure them outside of said wizards and menus - thus meaning it is near impossible to script and automate changes to them.

Altogether, the user experience is just awful, full of interruptions, and a pain to do anything quickly in. The only way I could justify owning a dedicated Windows machine again is if I were to get back in to full time gaming... and even that is changing now with things like crossover.

#3) Calling directories a "folder"
This one annoys me to no end, but it's hard to explain why. If you are a non-technical end user, this is perfectly excusable. The whole folder/desktop terminology and graphical presentation was created as an analogy to make computers easier to use for the masses. However, if you are an engineer, you obviously don't fit that bill. So call the thing by its real name - they are directories, not folders.

I equate this to my mother-in-law, who can't name a single position on a football outside of quarterback, calling a 4-3 defense in football "a bunch of guys trying to tackle the ball". That's excusable because she has never played and doesn't know the lingo. However, if you were my teammate on the offensive line and you called a 1 technique simply a "Nose Tackle" when trying to identify alignment, then you ought to be smacked upside the head.

For those of you who don't know, what typically gets referred to as a Nose Tackle can be aligned in about 5 different positions in a down position (2, 2i, 1, shade, 0 - all of which make a world of difference), so simply calling that person a Nose Tackle is horribly uninformative, misleading, and just wrong. And for that matter, so is calling a directory a folder.

#4) Meetings that include brainstorming but with no actionable items or plan associated

See here for a recent diatribe against this.

#5) Using Email to Debug and Collaborate on Work

Email might be the single worst communication method possible to debug and resolve problems - outside of using a conference call with no textual methods to aid. Yet, pretty much every shop I've ever worked in (aside from my present shop) uses it as the primary means in which to collaborate. Email is intrusive, asynchronous, not fit for working on code, forced upon unwilling audiences, and encourages grandstanding and long drawn out replies. Really, what most folks need is a synchronous pub/sub communication mechanism, like irc.

See here also for a previous post on my adoration of irc for teams.

What ChromeOS Will Really Do

Hint: It won't be revolutionary.

Since the general press announcement regarding Chrome, Google's new cloud based OS, hit the presses, I've seen all kinds of articles from the media and bloggers discussing how huge of an impact Chrome will have on the computing landscape.

Yeah yeah... we've heard it all before.

Don't get me wrong, moving disk storage and applications and nearly all computing resources to the cloud is a desirable thing. But, this isn't exactly new stuff. Businesses are already doing this with things like Amazon EC2/S3 for storage and machinery, using distributed processing with MapReduce based architectures, and both offering and consuming Software as a Service (SaaS) applications.

They certainly aren't the first OS vendor who's made this vision their modus operandi for what their consumers should experience either. Sun Microsystems for the longest time has been spouting off "The Network is the Computer" as their mantra. Even Apple has been offering MobileMe (formerly .mac) for cloud based storage and synching between desktops.

Here's what Chrome OS will really do - it'll really just drive the existing OS stalwarts to adopt using the cloud faster... much like the Chrome browser did. When Chrome was released, it upped the ante for how performant a browser a should be in regards to speed and responsiveness. Not too long after the release of Chrome, the public is given Safari 4, Firefox 3.5, and IE 8... which are competitive in speed with Chrome and are arguably much more functional (especially in the case of Firefox). So while Chrome introduced new competition, it didn't exactly establish, let alone maintain, a competitive and differentiating advantage over the existing products.

And so it will be with ChromeOS. It will not be the savior of "desktop" computing. It won't come even remotely close to bringing Microsoft down (something not even Google's search has been able to do to MSN/Bing). It will just push the existing OS's to move more intrinsic capabilities to the cloud, which is something Apple has already been doing and something Microsoft definitely has the capacity to support, while achieving and stagnating at a very small and limited share of the overall OS market.

Brainstorming Done Wrong

Brainstorming - a group problem-solving technique in which members spontaneously share ideas and solutions.

Notice that the definition doesn't use the word critique anywhere in it. That's because brainstorming is meant to be an activity in which all participants, even if it is just one person, are meant to throw out as many ideas as possible without shooting any down under existing premises and allow the organization and planning of those ideas be placed on the back burner.

Sounds like a wonderful way to come up with new ideas and possibilities, eh? It is the day dreaming portion of being a knowledge worker - where you get to think without reality. But that's the part where brainstorming can go awry, if you let it.

Brainstorming must be done in the overall context of a plan or a project. If one is just brainstorming willy-nilly and simply for the sake of brainstorming alone, it is a rather pointless activity that is orthogonal to anything that we as knowledge workers should be focusing on. In fact, if brainstorming is conducted without the results of sessions being used to impact an already existing project or goal then it is, in the best-case of a single person, a huge waste of time and waste of mental energy used to flutter out ideas that most likely will not be used. In the worst case, it can demoralize a whole team if they are coerced in to a highly collaborative activity that sucks up double-digit man hours all to produce nothing if no actionable steps or follow through is executed on the residual items left over from a brainstorming session. One can guarantee this does not happen if brainstorming is put in to the context of an overall plan or project and is used as the basis of forming next steps in a project.

An experience I have had at the professional level involves a brainstorming session close to the initial launch of a highly visible web development/services project I was a part of. Toward the end of that project, when frustrations were high and deadlines were starting to slip, management thought it would be a good idea to have all of the key participants gather in a room and have a brainstorming session on identifying problems in the project and how to correct them. As an exercise in how to conduct a brainstorming session it was executed well. Someone in management had been doing his/her homework on the subject of how to conduct a successful brainstorming session. Lots of ideas and thoughts were shared and displayed wonderfully as sticky notes on a whiteboard - there were literally hundreds of them. Unfortunately, what management did not do was use this brainstorming session in the context of the full project. There were no actionable items created as a result of the session and no follow up meetings were held - contrary to the lip service given by those organized the affair. It was as if hundreds of good ideas and thoughts suddenly cried out in terror and were suddenly silenced. The voices of all who participated were just simply ignored.

This particular session ultimately did more harm than good. To this day, that brainstorming session still gets mentioned in the office in very negative connotations as a useless waste of time and no one today wants to engage in any formal brainstorming sessions out of distrust from the original. This is due to the fact there was no follow-through - the brainstorming was not done in the larger context of a project plan or goal. Had the ideas used in that brainstorming been used for actionable items immediately as part of our project plan, two things might have occurred: 1) the rest of project may have gone much more smoothly (it did not, no problems were addressed) 2) the folks doing the work would have had confidence in brainstorming activities and would have engaged in more.