Now, I’ve been finding Behaviour Driven Development fascinating in a geeky kind of way (kind of like functional programming languages, and programming paradigm debates), but BDD has left a gnawing uneasiness in the back of my mind - generally this mind chewing begins when I’m missing the bigger picture or when something just isn’t right. I got a chuckle out of Spolsky’s writing as he discusses specification frameworks:

the geeks … focus on things they can see in the code, rather than waiting for the users to judge. They’re programmers, so they try to automate everything in their life, and of course they try to automate the QA process. This is how you get unit testing … In order to mechanically prove that a program corresponds to some spec, the spec itself needs to be extremely detailed. In fact the spec has to define everything about the program, otherwise, nothing can be proven automatically and mechanically. Now, if the spec does define everything about how the program is going to behave, then, lo and behold, it contains all the information necessary to generate the program! And now certain geeks go off to a very dark place where they start thinking about automatically compiling specs into programs, and they start to think that they’ve just invented a way to program computers without programming.

Now, this is the software engineering equivalent of a perpetual motion machine. It’s one of those things that crackpots keep trying to do, no matter how much you tell them it could never work. - Talk at Yale: Part 1 of 3, Joel Spolsky

Hehehe… Anyhow; I need to cut this post short. My DIY Nuclear Fusion Reactor and perpetual motion machine are calling my name. Errrr… I mean, I need to continue working through the RSpec book and playing around with other specification frameworks, because there’s always value in learning something new.

When you encounter a large system that is poorly factored, where do you start? In the XP community, the answer tends to be either one of the these:

1. Just start anywhere, because it all has to be refactored.
2. Start wherever it is hurting. I’ll refactor what I need to in order to get my specific task done.

I don’t hold with either of these. The first is impracticable except in a few projects staffed entirely with top programmers. The second tends to pick around the edges, treating symptoms and ignoring the root causes, shying away from the worst tangles. - Domain Driven Design, Eric Evans

I can think of many times where developers (myself included) have really just been gold plating under the guise of refactoring, or other times when refactoring activities contributed superficial cosmetic changes while the real mess lies beneath - getting to the root of the problem requires significantly more time and work than we’re often allocated and the cosmetic changes give us a sense of motion without moving. Then there are the occasions where seemingly superficial refactorings lead to an insightful break through.

Of course Evans isn’t suggesting that we stop refactoring altogether, instead he suggests that we think about what we’re refactoring, and that we focus on the parts of our software that provide the most value - in the context of Domain Driven Design this would be our Core Domain.

I like the RubyGem system just as much as Ruby, it makes a developer’s life easy.

For example, let’s say I want to design a new class:

• Install Ruby
• Install the Test-Unit Gem (along with a couple automatically installed prerequisites):

C:\>gem install test-unit
 Successfully installed test-unit-2.0.2
 Successfully installed hoe-1.8.3
 Successfully installed rubyforge-1.0.2
 Successfully installed rake-0.8.3

• Create a new test.rb file along with a new class.rb file (alternately we could have used the Interactive Ruby Shell directly from the command line)
• Run the test (test.rb):

C:\>ruby test.rb
 Loaded suite test
 Started
 .
 Finished in 0.001 seconds.
 1 tests, 1 assertions, 1 failures, 0 errors

• ???
• Profit! :)

Contrasting this to the Java / C# world: I’d be installing a compiler (or slower yet an IDE), then installing / configuring a testing framework. I’d also probably be installing a build process tool (like ant / nAnt), then I’d need to create a build file.

Similarly if I wanted to install Rails at the command line I specify gem install rails or if I want to use  RSpec gem install rspec.

The Ruby tools, ecosystem, and community is fantastic.

Some people advocate frequent backups - and some go so far as to suggest making use of offsite storage, duplicating their DVD/CD collections, and so on. This fixation on personal data redundancy seems multi-compulsive for an individual or a family (running a company is obviously a different situation).

I personally do not have a data backup plan - aside from online storage like Google Docs, Flickr (for photos and videos), and source control. I have lost years worth of files a number of times, and every time my hard drive comes screeching to a halt, I feel that burning pit of anxiety deep in my stomach, but guess what? It doesn't last long. Seriously, over the years there has never been a case where I lost something that I absolutely needed (again, personal pictures and videos are an exception). After losing data, I find myself pining for a couple recently created / used files, I then recreate the files in a quarter the time it took me to do the first version, then I forget about the heaps of digital baggage I was hording over the years.

Personal data loss might be part of a natural regeneration process - like a forest fire, it makes way for new growth and forces us to focus on the present.

Stop fighting nature, forget about a data backup plan, involuntary random data purging might be good for all of us. Perhaps a digital natural disaster is in order for you. :)

Can you let go of your bits? What is your backup strategy? Why do you backup?

The Law of Two Feet is just as applicable to life, as it is to Open Spaces.

The Law of Two Feet:

If at any time during our time together you find yourself in any situation where you are neither learning nor contributing, use your two feet. Go to some other place where you may learn and contribute. - Open Spaces, Wikipedia

By applying this philosophy to software development (programming languages, operating systems, and development ecosystems), I’ve really been been re-igniting my passion as a software developer. I am foremost a software developer and the tools and products I choose are secondary, but I lost sight of this over the past couple years. I was buying into being a [insert your choice of ecosystem, language, operating system here] developer.

Anyhow; this isn’t to say I won’t be raising my concerns (running away), I’ll continue to make noise (because I believe it has value), but when change doesn’t manifest. I will (like so many people before me) use my own two feet and move towards a situation where I can continue to learn, contribute, and be the change I’d like to see .

GUY KAWASAKI: Okay. … so it was like in the ashtray of your Lexus?
STEVE BALLMER: I’m a Ford guy, and I’m slightly offended by that. My father who worked for Ford would be offended, but nonetheless …

Fair enough, Ballmer likes Ford, but what kills me is that he apparently made his choice by association. Like Ballmer, my extended family are (were) also employed by Ford in the US Rust Belt. However, I still value quality and the economics of a purchase over my family affiliations. Of course, this is a broader issue - many people favour historical affiliation / brand loyalty over critical thinking and this may never change, but Ballmer is the CEO of Microsoft!

Now Ford, GM, Chrysler are on the verge of bankruptcy, and while many factors contribute to their situation. I think most people agree that these automakers kept making poor decisions for short term revenue gains - they kept making bigger expensive, less efficient cars, they were inward focuses and failed to look at possible future scenarios (like a global economic recession, skyrocketing oil prices, doomsday, blah-blah-blah). Basically, the big three automakers have been out of touch with the rest of the world. People like me (and probably you too) have never owned a domestic car. For myself, imports offered better value for my money (better fuel efficiency, a higher resale value, and a longer life). In addition, imports felt safer, sturdier, and were more aesthetically pleasing. Imports offered quality over quantity, and they looked nice too - imports made me a happy satisfied consumer.

Like the big three automakers, Microsoft (or Ballmer at least) is out of touch with their community (their developers). For myself, the community oriented / collaborative communities outside Microsoft are continually drawing me in. The openness of these communities and their open solutions is one part of the interest, but I’m also growing tired of working in an ecosystem (and with developers) that literally lag years behind the rest of the software world. Down here in the trenches Microsoft centric developers bear a striking resemblance to the unionized American autoworkers - inflexible, arrogant, and inward focused.

I want a development stack I can be proud of, that embraces quality over quantity, to work with developers that share my values, and an environment that offers more aesthetics. In short I want to be a happy satisfied developer.

In all fairness, it’s great how Microsoft is opening up (i.e. IronRuby, IronPython, MVC, etc…), but there are already more open established and mature communities outside Microsoft. I also really like C#, WCF, ASP.NET MVC, and Server 2008, but it’s all the baggage associated with the Microsoft ecosystem. It’s also fair to mention that the ALT.NET community is making great strides, but it is fundamentally discouraging that ALT.NET had to be formed in the first place. I mean, where are all the ALT.Rails, ALT.Ruby, ALT.Linux, ALT.Java communities?!

good programmers tend to cluster in some organizations, and bad programmers tend to cluster in other organizations … (Demarco and Lister 1999). - Steve McConnell

Can we draw the corollary that:

Good programmers tend to cluster away from traditionally closed development ecosystems like Microsoft, and bad programmers tend to cluster toward Microsoft like ecosystems?

Following Robert Glass’s train of thought:

The most important factor in software work is not the tools and techniques used by the programmers, but rather the quality of the programmers themselves. - Robert Glass, Facts and Fallacies of Software Engineering

Could we conclude that:

Good programmers tend to realize that an investment in their personal development is more important than learning the latest tools? Are product / tool based ecosystems like Microsoft’s at direct odds with the core values of a good programmer?

My hunch is that exceptional developers are versatilists. These developers cluster around organizations that embrace knowledge over tools, open technologies, open communities, and these great organizations also embrace vernacular culture. What do you think?

Listening to Yegge, Spolsky, and Atwood really brought up this uncomfortable memory of projects past.

[Yegge] some people … they can’t handle [a failed project]. They’re out on the ledge, you have to talk them down real slow, it’s usually more junior people. 

[Spolsky] I don’t know about junior, but … that they identified with the project, and that is kind of important. … People are going to be … devoted to a project that they identify with.

[Yegge] … identifying with anything so strongly that it starts to give you emotional reaction is really bad. You never know when your language is going to be obsolete or your project is going to get canceled or your favorite framework is going to be replaced. - Steve Yegge, Joel Spolsky, stackoverflow podcast #25

I can certainly relate.

My experience was a lesson learned, which resulted in a couple personal changes:

• No overtime at the expense of personal life or prior commitments.
• A quest for a more outward facing perspective on projects and the industry in general.
• A need for remaining emotionally detached from the project - as well as the frameworks, technologies, and the languages that I use.
• An aversion towards organizations that encourage the type of situation I had gotten into.
• Skepticism towards company loyalty, brand loyalty, etc…

There is no “I” in “T-E-A-M”. A team falls apart when members begin participating in backstabbing, which often results in negative alliances being formed between members - while a sense of self preservation and distrust creeps around the otherwise neutral team members. Soon the team digresses into a group of individuals operating in silos. I don’t think it’s possible to put a finger on the catalyst for the entire process, but it could boil down to a combination of: an overly cynical team member, a preexisting alliance between team members, lack of leadership on the project, a team member with an unexplainable need for political control (perhaps lack of confidence in their abilities), a dysfunctional working environment, or human nature?…

No individual is a success who hurts the team, and no individual is a failure who helps it. - Software Project Survival Guide 

How can we cope? Bottom line: RESPECT. Treat your team as family, recognize that everyone has different strengths and weaknesses. Don’t participate in backstabbing, be transparent and honest, if you have an issue with a team member then make it a point to discuss your concerns with that member. Anyone participating in backstabbing is hurting the team.

Nobody on the team should feel unappreciated or ignored. This ensures high level of motivation and encourages loyalty toward the team, and the goal of the project.  - Respect, Extreme Programming Values

A project’s success hinges tightly on the team. Being a team player and having great interpersonal skills can be more important than technical skills - most people can rapidly learn new technical skills, but being able to function within a team might be an ingrained personality characteristic.

If you’ve ever landed on Amazon then you’re probably familiar with their reviews and wish lists. Amazon provides access to these items (and many-many more) through their extensive web services - the Amazon web services can be complex and overwhelming when all you want is a review list and a single user specific wish list. For this site I wanted to pull in my reviews and wish list - displaying them alongside my blog. It’s fair to note, that user reviews are available via an RSS feed (but this feed doesn’t include all the details I wanted) and the wish list page still doesn’t provide an RSS feed. So a custom Amazon web service request was in order.

Let me try to make this story short.

If you want to request your reviews and your wish list you need the following:

• An Amazon Account: http://www.amazon.com/gp/css/homepage.html with at least a wish list or a review.
• An Amazon Associates tag: https://affiliate-program.amazon.com/gp/associates/join/ (this will be your AssociatesTag).
• An Amazon Web Service (AWS) access key: http://aws.amazon.com/ (this will be your AWSAccessKey).

Once you have a wish list or review, you then need to:

• Get your CustomerId for the reviews. I found my CustomerId by navigating to my reviews (http://www.amazon.com/gp/cdp/member-reviews/A2JM0EQJELFL69/) then pulling out ‘A2JM0EQJELFL69′ (the last element of the url).
• Get your ListId for your wish list.  I found my ListId by navigating to my wishlist (http://www.amazon.com/gp/registry/registry.html/?id=3JU6ASKNUS7B8) then pulling out ‘3JU6ASKNUS7B8′ (the identifier after id= from the url).

Once you’ve collected all those bits, you need to:

• Checkout and download the source code for the project and build the assembly or download the pre-compiled assembly.
• Add the assembly reference to your project (remember, I’m assuming you’re using .NET).
• Make a call to the application which will generate XML files containing your respective reviews and wish list.

Setting up the call would look something like this:

IAmazonRequest amazonRequest = new AmazonRequest() {
 AssociateTag = "adamkahtavaap-20",
  AWSAccessKeyId = "1MRF________MR2",
  CustomerId = "A2JM0EQJELFL69",
  ListId = "3JU6ASKNUS7B8"
};

IFileParameters fileParameters = new FileParameters() {
  ProductFileNameAndPath = @"Products.xml",
  ReviewFileNameAndPath = @"Reviews.xml",
  ErrorFileNameAndPath = @"Errors.xml"
 };

IAmazonApplication amazonApplication = new AmazonApplication(amazonRequest, fileParameters);

amazonApplication.Save();

And Viola!

If you’d like to provide some design guidance, fix a bug, or request a feature, then visit (or join) the project on Google Code.

Alternatively, you might also be interested in the LINQ To Amazon source featured in the book LINQ in Action.

the obvious … is never seen until someone expresses it simply. - Kahlil Gibran

The preface of Object Oriented Software Construction literally introduced me to the three-step sequence:

the well-known three-step sequence of reactions that meets the introduction of a new methodological principle:

(1) “it’s trivial”;
(2) “it cannot work”;
(3) “that’s how I did it all along anyway”.

(The order may vary.) - Bertrand Meyer

Naturally people consider themselves smart, which sometimes translates into knowing everything, and these three reactions are probably a manifestation of thinking you’re overly enlightened. If we put ego aside - along with our natural predisposition for being lazy (trying to avoiding learning new things) - we often change our views altogether.

Looking back at my technological naivety: I was once wrongly convinced that client-side languages would never work and server-side languages / frameworks would dominate (until I really learned JavaScript), I had also mistakenly assumed that I was already doing TDD (until being introduced to the concept of Mocking), and I even thought that HTML table based design was the future (until I really learned CSS). With a little bit of knowledge and some experience I changed my views altogether.

Reflecting on these incorrect assumptions and decisions promotes growth - with every experience we grow. Which of my latest assumptions / reactions will change over time?

Now, developers can be pretty skeptical, and getting them to agree has been likened to herding cats, but a couple core considerations / values seem to surface when the decision is being made.

Considerations for choosing a JavaScript / AJAX Framework:

• Transparency - Who are the framework’s development team and why should we trust them? Do these developers blog? Attend conferences? Are they featured on podcasts / videos? Is there a high or low turnover within the team? What are their passions? Is this just a job, do they like what they’re doing, are they a cog on a wheel? Are they experts in their field?

• Competency - Based on the information gathered in the consideration above (transparency), how competent do we feel the development team is?

• Community Support - How well is the framework supported on forums and blogs? If something were to go wrong can we gain access to the framework’s development team? Are there widespread experts using this framework readily available?

• Reputation - How popular is the framework in the industry? Who uses it? Are there any white papers, success stories, case studies available?

One of the easiest ways for a developer to choose a framework is by looking at the developers that built it (and talking with those that are using it). As developers our day job will be stepping into someone else’s code for the duration of the project, working with a framework created by competent developers makes our jobs easy. Frameworks without transparency don’t allow us to gauge the competency of the developers or the framework.

Transparency is essential for JavaScript / AJAX Framework teams, JavaScript itself is open and transparent (not compiled yet), it follows that JavaScript / AJAX Framework along with their teams should also be transparent. When the decision for choosing a JavaScript / AJAX Framework is placed in the hands of developers the frameworks that don’t meet the above criteria sink to the bottom of the list.

The only way to succeed now is to be completely transparent, everything is exposed, everything you do - Gary Vaynerchuk 

Through all these experiences I was convinced that I was unique. Then I started becoming part of the bigger conversation. While engaging online I began learning that there were thousands of people like me: weened on computers, interested in good software design, and passionate about what they do.

Imar Spaanjaars’ signature always reminded me of this lesson:

Everyone is unique, except for me.

Yegge’s recent post brought up this thought again:

people like to think they’re unique and special, and that their tastes aren’t necessarily widely shared by others. This is what drives fashion: the need to differentiate yourself from “the crowd”, by identifying with some smaller, cooler crowd. … The reality is that for any given dimension of your personality, there are oodles of people just like you. - Business Requirements are Bull**** 

David Heinemeier Hansson reiterates this:

it’s somewhat counter intuitive … for a lot of developers …  it’s counter intuitive for humans in general to think they’re not that special, but when they do think they’re special … they kind of get these assumptions that they need very unique and special tools that will only work for them … We as programmers aren’t really unique or that special. - David Heinemeier Hansson, 37signals: “Friday Keynote”

Remember you’re not really special. :)

Working in a noisy work environment and listening to music is counterproductive for intellectual demanding work. For example: we don’t write exams in busy cafeterias, or write resumes through loud movies, and Libraries are quiet for a reason. Noise; whether it be music or background noise does negatively affect your ability to get things done.

DeMarco and Lister (in Peopleware) present the results of an interesting experiment:

During the 1960s, researchers at Cornell University conducted a series of tests on the effects of working with music. … They put half of each group together in a silent room, and the other half of each group in a different room equipped with earphones and a musical selection.  Participants in both rooms were … given a programming problem …

They discovered that the majority of the people working in the silent room could pick out a pattern in the programming problem and could come to a quick clever creative solution. Whereas the people working with music playing were able to solve the problem, but didn’t make the creative leap.

They go on to explain:

Many of the everyday tasks performed by professional workers are done in the serial processing center of the left brain. Music will not interfere particularly with this work, since it’s in the brain’s holistic right side that digests music. But not all of the work is centered in the left brain. There is that occasional breakthrough that makes you say “Ahah!” and steers you toward an ingenious bypass that may save months or years of work. This creative leap involves right-brain function. If the right brain is busy listening [to music], the opportunity for a creative leap is lost.

In their book they also make the point that open space work environments and cubical farms are not conducive to knowledge work, and that all employees (or at least groups of employees) should have the ability to close their door. Great companies do follow these guidelines, but many of the smaller companies or transitional companies (at least the ones I’ve worked in) tend to air on the dilbertesque side (the noisy cubical farms / open concept).

To compensate for the noise in the work place I’ve resorted to wearing noise canceling earphones without music. These earphones double as a metaphoric door - it indicates to those around me that I’m hard at work and not to be disturbed. Noise canceling earphones let me create my own personal audio walls, but eventually I become the weird guy with the earphones that aren’t plugged into anything guy.

As a lowly developers it’s hard to make the case to management for a quieter work environment (let alone an office with a door), but we can keep our eyes out for companies that share these values, start our own company, or take opportunities that let us work from home. In the meantime thank goodness for ear plugs (err.. I mean earphones).

My heuristic approach to naming conventions:

New Development / Greenfield Work:

• Follow the conventions of the language, or the standards used within the larger community, and pay attention to the API. For example: If you’re programming in .NET follow the naming conventions outlined in MSDN, in JavaScript look at the DOM API, in CSS look at the definitions.
• If a formal naming convention exists for the organization and these conventions makes sense (they aren’t too far off the language APIs) then follow them. If it feels like the naming conventions were created in the dark ages by a very-very senior COBOL Developer then start asking questions.

Maintenance / Brownfield Work:

• Follow the conventions of the existing code if you’re modifying an existing module.
• If you’re creating new modules then consider following the conventions of the language and API.

This post was inspired by a podcast by Donald Belcham and Kyle Baley on Brownfield Applications.

Most languages and technologies used in web applications come with their own unique naming conventions - which is unfortunate, but necessary, because diversity is important. Languages like JavaScript and PHP use camelCase, CSS uses-hyphenated-delimiters, and ASP.NET / Java / and the like adhere to the conventions used in their respective libraries and frameworks. Managing the different naming conventions in a web application can be difficult, but with discipline, embracing each language’s conventions can provide some great benefits.

A common mistake I’ve made in the past, was trying to make all languages adhere to a single convention. As a budding PHP / ASP developer I took the-single-convention-for-all-languages approach. In retrospect, I used this approach because I didn’t completely understand the language I was using, and in order to compensate for this lack of knowledge, I’d try to meld the languages into the mental model I understood best. This was a mistake.

Today, I find that working with the conventions of the language facilitates re-use (experts in the language understand what I’m doing), promotes portability (modules can be used across projects regardless of server-side technologies), encourages global collaboration (open source modules and plug-ins can be easily consumed and contributed to), and helps to a nurture a more maintainable application (developers from other language domains can easily maintain the application with a relatively small learning curve). Like a carpenter working with fine material, I embrace working with the grain of each language. It’s also fair to mention that breaking free from the monocultured (one-size-fits-all) approach to naming conventions provides a broader perspective, and also makes your development skills more universal - it might even open the door to different development domains in the future.

Then there’s the discussion on name length, verbosity, and using meaningful names. Steve McConnell suggests that the optimum name size for a variable or function is between 8 and 20 characters (Chapter 11, Code Complete), but with tools like ReSharper (for renaming / refactoring etc…) I find myself using names well over 30 characters. So names like GetApproveeTotalFromNamedBasket are a common occurrence in my code. However, like most things, verbosity does need balance (everything in moderation right?). In the business layer, descriptive names are a godsend - they jog my memory as I rediscover what the module I wrote last month was supposed to do. But… in the presentation layer languages (like JavaScript, CSS,  ASP.NET, or XHTML) you may want to reconsider using long descriptive names. Since verbose, long running descriptive names in the presentation layer are passed over the network and can degrade performance. Often times these verbose names are combined together - throw in ASP.NET name mangeling, start hooking in verbose CSS definitions, and then start inserting JavaScript events. All this compounds quickly and result in large page payloads filled with elements like the following:

<div id="ctl00_ContentPlaceHolderForAllTheBestImprotantContent
 _PanelForTheBestReviews"> 
<a onclick="LinkButtonClick_ThankYouForTakingTheTimeToReadThis();" 
 id="ctl00_ContentPlaceHolderForAllTheBestImprotantContent_
 RepeaterForAllMyFavoriteBookReiews_ctl00_
 LinkButtonMarkReviewAsFavorite"
 class="LinkFormatingCssClass SelectedLinkFormatingCssClass" 
 href="javascript:__doPostBack( 
 ctl00$ContentPlaceHolderForAllTheBestImprotantContent$ 
 RepeaterForAllMyFavoriteBookReiews$ctl00$LinkButtonMarkReviewAsFavorite'
 ,'')">Mark As Favorite </a> 

Note: That mess of code above would fire a JavaScript event then an ASP.NET event. It’s the result of placing an ASP.NET LinkButton, inside a Repeater, inside a Panel, inside a Masterpage, and adding a JavaScript event along with some CSS. We can see that using long names in the presentation layers results in a mess of text. It’s also fair to mention that the ASP.NET MVC Framework lets developers write cleaner presentation code.
Sure, everyone cites premature optimization as the root of all evil, and we do live in a world of gzip file compression and JavaScript minifiers. But… keeping names short in CSS, ASP.NET, and XHTML isn’t hard as long as you’re mindful of the final goal. Smaller names in the presentation layer will reduce the amount of data transferred over the network which increase the performance of the application.

Joseph Smarr of Plaxo.com once said:

Web applications are only slow if you let them get slow - Douglas Crockford, Alex Russell and Joseph Smarr: On the Past, Present and Future of JavaScript [30:00]

My preference (project requirements warranting) is to keep things short and concise in the presentation languages while using longer descriptive names outside the presentation languages. What’s your preference?

Politics, religion, famine, pollution, and relationships; these are parts of our world. I'm messy, my hair falls out, and yours might too. The world is messy and complex, so what would make software different?

During my first real job after graduating College / University, I was horrified by the state of my project's source code. The code was spaghetti; it looked like someone crammed a stack of poorly written technical manuals through a blender that funneled into our source code. Regions (#region) were running willy-nilly, negated values were passing conditions; delegates were calling properties which were in turn calling delegates which were creating infinite loops… SQL rows were being sent across TCP/IP, centralized build servers were taboo, unit testing and TDD was unheard of. Each of the members of our team were build / release masters, developers, and ninjas.  Our job was to maintain this juggernaut and affirm the stakeholders that everything was OK.

But were things really that bad? Remember, I was a recent grad; I was used to creating pristine frameworks (like elevator simulators) crammed with design patterns and fascinating abstract data types. In a way, I was an architecture astronaut being rudely ejected into a toxic tailings pond. The courses I had taken in school, the projects I completed, the languages I used were a great start, but not a valid representation of the real world. In the academic world things were clean; out here (like the rest of the planet) everything is a mess.

I started coming to the realization that, producing software is more about managing people than science, technology, or math. Mistakes and human flaws are the norm, software entropy is inevitable, and technical decisions are often based on nontechnical considerations: time constraints, politics, religion, and relationships rather than sound research and science.

There is hope; realize that you can't control everything, that the one-size-fits-all solution and silver bullets are myths. Then focus on what and how you can change yourself, your software, and your situation. Developing good software (like living a good life) is about making informed decisions, choosing opportunities that encourage growth, reducing complexity, and having a long term vision or goal. Today I still think software is messy, and I'm still horrified by most source code, but abstractions, n-tiered design and testing sufficiently help me manage the chaos.

Science often exists in a pristine clean vacuum, whereas software deals primarily with people. Software is not a science, and humans (like software) are inherently messy and complex.

One of my biggest pet peeves is trying to efficiently complete development work on a slow machine. In my mind, trying to work quickly on a slow computer is like asking a marathon runner to wear snowshoes then demanding they WIN the marathon. What ensues, is painful for the runner, painful for all who watch, and reaching the end goal feels impossible - bottom line good equipment matters. However, many client’s overlook the relationship between getting stuff done and a slow machine, or they don’t care, or they can’t do anything about it.

Maybe they find it thrilling (in some sick way) to watch your soul fizzle away as you spend 300 minutes a day compiling your application (or running your tests). :)

In great organizations slow machines aren’t an issue. According to the The Programmer’s Bill of Rights: “Every programmer shall have a fast PC”, and from the Joel Test: “[Organizations should] use the best tools money can buy?” But reality is often a different beast, and in my experience you have to make the changes you want (or “be the change you want to see…” - Gandhi).

I’m sure in Silicon Valley, good computers would be mandatory for most organization, but I live in Canada - we suffer through black flies, mosquitoes, 8 months of winter, and organizations with poor resources. :) Did you know that Canada’s population is roughly equivalent to the population of the state of California alone!?

Anyhow, I started working from home full-time this year - up to this point most of my work has been done onsite using whatever machine the client provided (some with outdated hardware). My home desktop was a six year old PC that would make Frankenstein look sexy - it was a collection of old and new parts. I needed a new computer.

I based my specs on Jeff Atwood’s and Scott Hanselman’s specs for the Ultimate Developer Rig. The machine turned out to be economical, the prices have come down significantly since the initial post was published, and to top it all off, I was able to chop shop my old machine and sell every single part through eBay and Kijiji - for a surprisingly decent price too (who would have thought a 6 year old Sound blaster Audigy would sell for $50?).

Contrasting my setups:

Working on my new machine is enjoyable. I find myself more productive without being distracted by the frustration of a slow machine, and having dual monitors also contributes to my productivity (Does More Than One Monitor Improve Productivity?). My favourite parts of the new setup are the monitors, the Ergotron stand, the speed, and the case. You really get what you pay for with LCD monitors, the SyncMasters are easy on the eyes when compared to my old economic Acer, and the case is dead silent.

In the future, if I’m provided with a substandard PC, you can expect to see me hauling my new machine into the office. :)

Take a look at my old desktop setup in my older post: Something About the Cobbler’s Children Having No Shoes

Have you ever had to use an outdated machine as a developer? How does working on a slow machine effect your work? What are your thoughts on taking matters into your own hand (like purchasing your own computer to replace the slow one at work)? Have you ever installed additional resources in the computer you use at work?

The topic of our discussions reminded me of something David Heinemeier Hansson said when talking about software development:

You don’t need to be a f***ing genius to make any of this stuff work, it’s not rocket surgery! - David Heinemeier Hansson at Startup School 08

DeMarco and Lister also echoed this outlook back in the 80’s, and publicized: the High-Tech Illusion:

the High-Tech Illusion: [is] the widely held conviction among people who deal with any aspect of new technology … that they are in … high-tech business. [These people] are indulging in this illusion whenever they find themselves explaining at a … party, say, that that they are “in computers” … The implication is that they are part of the high-tech world. [These people] usually aren’t. The researchers who made the fundamental breakthroughs in those areas are in the high-tech business. The rest of us are appliers of their work. - Peopleware : Productive Projects and Teams

If we were in the High-Tech business, then we’d be the bottom feeders (the parasites, the grunts), because our daily activities revolve around consuming other peoples research and work (programming languages, platforms, frameworks and the like). We are consumers, we’re not on the cutting edge nor are we in the high-tech world.

Perhaps building software could be much like outfitting yourself for a day in the snow. You head off to the local shopping mall, you acquire the functional items to keep yourself warm, but brands and store choice don’t really matter. Whether we’re buying winter boots or choosing a programming language, technology doesn’t really matter. There are an infinite number of ways to solve any problem, as well as an infinite number of technical permutations to form a solution. If we can solve the problem within the constraints of our problem domain then we’ve succeeded.

The High-Tech Illusion often permeates my world - I work as a Web Developer in the Microsoft realm. I continually see the High-Tech Illusion manifests itself in these situations:

• Colleagues talking in vague opaque high-level metaphors that patronizingly shield you from the inter working of what they assume is beyond your comprehension
• Fixations on specific tools, hardware, platforms, and methodologies while the problem that needs to be solved is diluted and any combination of these items could solve the problem
• Colleagues that assume superiority and can’t acknowledge that knowledge is acquired through research and a continual efforts to improve

Pretentiousness in the software realm (in teams, organization, and so on) is usually the byproduct of someone that’s living the High-Tech Illusion.

I’ve been guilty of subscribing to the High-Tech Illusion. How does the High-Tech Illusion permeate your world? How can we get back to reality?

The classic geek haircut. I still sport this cut today. :)

How old were you when you started programming?

Somewhere around the age of 8 or earlier, computers were always just there - they’d been in my life since I can begin to remember.

How did you get started in programming? What was your first language?

My dad went to College for robotics when I was around 8 years old. His robotics program involved lots of programming and together we worked through a couple BASIC programming books. I continued to mess around with BASIC and wrote scripts so I could get at my favourite games. Later I was frequenting BBSs (The Fisherman’s Scroll), and surfing the internet through lynx (a text based browser). I eventually became a Script kiddie - being a Script kiddie was what really turned me on to programming. My friends and I would write IRC war scripts, play MUDs, and try to figure out how Trumpet Winsock, networks, and HTML worked - those were the days of Netscape 1 (the version with the big glowing ‘N’). Later we tried writing our own version of NetBus with the help of C / C++ programmers on IRC - the fragments of the C language these programmers exposed to me were magical, and sparked an genuine interest in computer programming. In addition to all this my dad kept a constant supply of old and new computer parts funneling into our house, my brothers and I would build computers from the parts - today my closest brother is a Linux fanatic, evidently all this sparked his interest too.

Programming has always been a part of my life, BASIC was my first language.

What was the first real program you wrote?

I followed a couple game tutorials from my BASIC books, but my first real program would have been Pacman programmed in Turing - in my final year of high school I enrolled in a computer course, where the instructor let us write any program we wanted for half a school year I chose to write a game.

What languages have you used since you started programming?

I’ve spent most my time in C, C++, C#, JavaScript, SQL, and the mark-up languages. I primarily program for the web or at least for the network, but have used many other languages like COBOL and so on…

While using multiple languages are great, I really believe that we you should completely understand the fundamentals of at least two languages (like say a static language and a dynamic language), because:

Once a programmer realizes that programming principles transcend the syntax of any specific language, the doors swing open to knowledge that truly makes a difference in quality and productivity. - Steve McConnell, Code Complete 2nd Edition. 

What was your first professional programming gig?

I would have been 18. It was my first year of College, I needed a part-time job in order to pay rent, I initially worked on an assembly line, but would occasionally help the office workers troubleshoot their IT issues. I soon found myself working as the company’s network admin / computer gopher. I went on to develop their cataloging system and a website. At the time I was going to school for Electronic Engineering, but decided to switch to a Computer specific program. Previous to this, I had freelanced a couple websites for local businesses while in high school.

If you knew then what you know now, would you have started programming?

Absolutely! The industry continues to instill a sense of wonder in me. I can’t imagine doing anything else.

If there is one thing you learned along the way that you would tell new developers, what would it be?

• Read! You’d be surprised how little progress has been made in the software industry over the past 30 years. By reading we can learn from the mistakes others have made.
• Don’t be intimidated by code or frameworks handed down by large organizations, their code isn’t any different than yours.
• Hard work always pays off, or as Thomas Edison said: “Success is 10 percent inspiration and 90 percent perspiration.”

What’s the most fun you’ve ever had … programming?

Collaborative programming is always fun whether it be paired programming or working together on a project. It’s hard to pinpoint the most fun I’ve “ever” had, because it’s all fun. :)

This post was in response to Michael Eaton’s initial post on: How did you get started in software development?

Now it’s your turn to answer: How did you get started in software development?

All or Nothing thinking … is part of the most primitive of human responses: The Fight or Flight Response. When faced with a life-threatening situation, we must make a snap decision and act on it. There is no time for ‘maybe this’, or ‘maybe that’. -All or Nothing Thinking

Some Polarized Views

Views or labels that seem to be commonly applied to people, organizations, and people:

• A Pessimist or an Optimist
• A Cynic or an Proponent
• A Skeptic or a Dreamer
• A Pragmatist or an Idealist
• A Tigger or an Eeyore

These labels are generally mutually exclusive - you’re usually labeled a Pessimist or an Optimist, but not both. Then there’s this general acceptance that Skeptics are Pessimists and these are Curmudgeons, and Eeyores (but everything in moderation). Switching between views is healthy and advisable (be a Skeptic and an Optimist), because inherently “[a]ll programmers are optimists” (1) and too much Enthusiasm, and Optimism often results in Hype, and “Hype is the plague on the house of software” (2).

Why not embrace all these views? Take on the role of a Skeptical Dreamer, then an Optimistic Cynic, or a Pragmatic Idealist. Let’s throw off these polarized thinking models and fill in the gray areas. As Fred Brooks once said: “Skepticism is not Pessimism”, and critical thinking is also not Skepticism.

(1) Fred Brooks, The Mythical Man-Month (2) Robert Glass, Facts and Fallacies of Software Engineering

The ASP.NET AJAX Framework is an embarrassing server-side centric approach to DHTML / AJAX web development. While most programming languages and frameworks come with both good and bad parts, the ASP.NET AJAX Framework is an example of a bad part - on the contrast the ASP.NET MVC Framework looks to be a good part.

What’s wrong with the ASP.NET AJAX Framework?

1 .NET Developers are DUMMIES!
The ASP.NET AJAX Framework appears to have been designed under the assumption that .NET developers are dummies and can’t learn or don’t want to learn JavaScript. That .NET Developers would rather hobble along with their familiar languages, then to learn something new. I understand that the ASP.NET community’s only real problem is education, so let’s ask: What is wrong with the ASP.NET Community? Then educate ourselves rather than becoming the .NET Developer statuesque. It’s patronizing to use a framework that assumes learning a new language is beyond our capabilities. Many of these other programming languages are more expressive than statically typed languages like most of the .NET languages. 

2. The “don’t write a line of JavaScript” abstraction leaks like a sieve
The Framework is intended to shelter .NET Developers from the JavaScript language. Which, like driving a car across North America without knowing how to pump gas, stops you dead. Either you depend on someone to pump your gas - depend on a 3rd party (vendors or the ASP.NET AJAX Control Toolkit) and their many authors to write your JavaScript - or you stop moving. As Web Developers, sooner or later learning how to pump your own JavaScript becomes a mandatory skill.

3. Client-side programming from the Server-side is a absurd
The AJAX Framework does back flips to translate server-side code into JavaScript, and then requires that you write JavaScript anyway. Save yourself the pain, learn JavaScript. One day The Law of Leaky Abstractions comes into play, the gas station attendant fills your gas tank with diesel - the AJAX Control Toolkit blows requires debugging and you have to learn JavaScript anyways.

4. Bloated, poor performance, bad user and developer experience
The AJAX Framework extends many of the native JavaScript objects as it attempts to turn JavaScript into a staticly typed programming language, and tries to hook into the ASP.NET life cycle, but all these features are unneeded as they are ALL already achievable through the native JavaScript language - if it walks like a duck and quacks like a duck, then… err… could someone remind me why we need typed languages in a web browser? Anyhow; all these object extensions, enhancements, and upgrades, contribute to more scripts that need to be downloaded and increases the number of scripts running in your browser. Then there’s partial-page rendering and Update Panels which do full page post backs under the guise of AJAX. BAD! Client-side scripting is supposed to enhance the user experience not make it worse. Other AJAX Frameworks are built with performance as their number one goal, but in the ASP.NET AJAX Framework adding more widgets to JavaScript seemed to be the first priority, and performance an after thought.

5. Working against the grain is a waste of time
The AJAX Framework works against the grain, it would be nice if it embraced the JavaScript language. Very few of the concepts and metaphors used in the ASP.NET AJAX Framework transcend AJAX techniques or frameworks - your time is probably better spent learning how JavaScript works or how the other AJAX frameworks work.

6. Disconnected from the ASP.NET MVC Framework
The ASP.NET MVC Framework throws the ASP.NET life cycle away leaving more dead weight ASP.NET AJAX Framework script and rendering many of the AJAX Framework techniques moot.

7. The ASP.NET AJAX Framework almost over looks the ‘J’ in AJAX - ‘J’ stands for JavaScript (that’s GOOD)
JavaScript is the glue of the web, even the ASP.NET Framework depends heavily on JavaScript, it is not something to shy away from.

8. Aside from local intranet sites, no one really uses the ASP.NET AJAX Framework.
The AJAX Framework isn’t widely used. The ASP.NET AJAX site showcases 25 sites using ASP.NET AJAX. None of these applications appear to be high-traffic or moderately high-traffic applications. On the other hand, the YUI site showcases 89 sites, out of these sites, 6 sites (flickr, Slashdot, Linkedin, Paypal, O’Reilly, My Opera) could be considered high-traffic. Other AJAX libraries like jQuery, and Dojo compare similarly. Your time might be better spent learning one of the other AJAX frameworks.

If we (as .NET Developers) are going to claim we know AJAX, then let’s focus on the core of AJAX (JavaScript) and stop obscuring it in poor frameworks. Frankly the ASP.NET AJAX Framework is embarrassing, the web development community is laughing at the ASP.NET AJAX Framework and the Developers touting it.

When choosing a book I follow this heuristic approach:

• Ask experts in the field (friends, forums, newsgroups) for recommendations
• Ask these experts to differentiate between the high level books and the books that take a technical deep dive.
• Filter out (discard) the high level recommendations.
• Filter out (discard) all recommendations that contain the following keywords in their title:
• Cookbook
• Problem - Design - Solution
• Hacks
• Tips
• Learn X in 24 hours
• Look for recognizable authors.
• Cross reference these recommendations through Amazon's Reviews:
• Books with over 100 excellent ratings on Amazon are instant winners - the Amazon community is rarely misleading.
• Books that haven't received more than 50 ratings should be considered with skepticism - visit a local book store and skim through the text in question before making the purchase.

Here's a running list of the technologies, and concepts you'll encounter when digging into ASP.NET AJAX:

• ASP.NET
• The Page Life Cycle
• The Control Life Cycle
• Web Controls
• User Controls
• View State
• Session State
• Events
• .NET / Classical Language
• Interfaces
• Inheritance
• Delegates
• Multicast Delegates
• Assemblies
• Properties (Get / Set)
• Constructors

In addition to these, you also have the technologies universal to all JavaScript libraries:

• JavaScript:
• Closures
• Object Literals
• JSON
• Events
• DOM Manipulation
• Prototypical Inheritance
• Constructors
• XMLHttpRequest
• Cascading Style Sheets (CSS):
• Web Services

The ASP.NET AJAX Framework is more complex than other AJAX frameworks, I'm continually lost in it's ambiguity as it attempts to skirt around the JavaScript language - I think this learning curve (and all it's confusion) is precisely why Silverlight has so much potential.

I'm still diving into the low-level details, but my first impressions of the ASP.NET AJAX Framework are:

• Obscure, ambiguous, no clear vision - it offers multiple (resource intensive) ways to avoid writing JavaScript, but then requires that you write JavaScript anyways
• Too server centric
• Too heavy weight (I'm not appreciating how they're trying to turning JavaScript into a Java, C#, .NET clone, the overhead within the browser for these conversions seems like a huge performance bottleneck)
• Has the potential for poor performance

Most of the other AJAX libraries have been written with performance, browser responsiveness, and User Experience as their number one priorities - I'm still not sure about ASP.NET AJAX.

How many ways can we try to avoid writing JavaScript? If an AJAX library doesn't enhance the User Experience then why use it? Regardless, I'm still digging deeper.

The great employees will be devoted, sure, and it’s completely reasonable to expect them to work their butts off. But unlike founders, employees are concerned about what their jobs are like today. They’re not as excited about making sacrifices for the long run. I can always tell the founders who haven’t figured this out yet, because they’re disappointed in all their employees, firing good people left and right and constantly asking, “Why hasn’t Joe (or Jane) gotten this work done yet? I could have finished it in one weekend!” - Joel Spolsky: How Hard Could It Be?: Lessons I Learned in the Army

Both these articles highlight the differences between Employees and Founders, but what about Consultants?

Consultants can often fall under the full-time Employee umbrella, but probably have an even shorter term interest in their client. Part of a consultant’s job is to maintain objectivity, to distance themselves from becoming financially, emotionally, and personally invested in their client - objectivity is lost when an attachment or investment is made.

According to Janet Ruhl a couple of the biggest Gotchas in consultancy work can be:

• Investing in your client - purchasing shares in your client or agreeing to software royalties rather than a pay cheque.
• Being manipulated into working for free.

Consultants are kind of like Employees, but different. Consultants probably have an even shorter term interest in the company they work for then Employees do. I think it’s important to highlight these differences.

Why Namespaces? Well… :) When a browser loads a document, it loads ALL the JavaScript into the browser. Objects that are not enclosed within a Namespace are Global, and Global Variables are Evil because they run the risk of interfering / overriding / clobbering previously defined objects (variables, functions, etc…). The JavaScript language, in its current form does not have native support for Namespacing . So, as pragmatic developers we realize the need to “Program Into [Our] Language, Not In It” - Steve McConnell, Code Complete 2nd Ed, Chapter 34.4. In the JavaScript language we use Objects to achieve Namespacing - we’ll cover this closer to the end of this post.

Don’t limit your programming thinking only to the concepts that are supported automatically by your language. The best programmers think of what they want to do, and then they assess how to accomplish their objectives … - Steve McConnell: Code Complete 2nd Ed, Chapter 34.4 

An example of when Namespaces could be used: Let’s say, we’re working on a team of 3 developers, each developer is working on a different widget / component for the same page. So inside our HTML / XHTML document we define and load three different JavaScript files and inside these files we have something like:
In someObscureWidgetJavaScriptFile1.js have:

  helloWorld = function(){ alert('hello world'); };

In someOtherObscureJavaScriptFile2.js we have:

  helloWorld = 'hello world';

In someOtherObscureJavaScriptFile3.js we have:

  helloWorld = { hello: 'hello', world: 'world' };

All these JavaScript files get loaded into the browsers global calling object (window), and each assignment of helloWorld interferes with the previous. When we attempt to reference helloWorld we’ll be depending on the order in which the JavaScript files were loaded - if the first file was loaded we’ll be able to display the alert, if the later file was loaded first we’ll be able to reference a string, and so on.

Back to the topic at hand, How do I create a Namespace in JavaScript.
Note: this approach to Namespacing was recommended and referenced in JavaScript: The Definitive Guide by David Flanagan, other methods of Namespacing can be found on the web (Namespacing your JavaScript by Dustin Diaze outlines an alternate approach). For me, the following seems more intuitive, and is recommended in Flanagan’s book - probably, the best JavaScript book written to date.

Ceating a Namespace in JavaScript:

// Create the namespace object. Error checking omitted here for brevity. 
 var myNameSpace;
 if (!myNameSpace) myNameSpace = {};
 myNameSpace.myPseudoClass = {}; 
 //JavaScript doesn't support classes,
 // so let's avoid confusing people and call this a Pseudo Class  

 // Don't stick anything into the namespace directly. 
 // Instead we define and invoke an anonymous function to create a closure 
 // that serves as our private namespace. This function will export its 
 // public symbols from the closure into the myNameSpace object 
 // Note that we use an unnamed function so we don't create any other 
 // global symbols.
 (function() { // Begin anonymous function definition  

   // Nested functions create symbols within the closure 
   function displayMyMessage() { alert(myMessage); }

   // Local variable are symbols within the closure. 
   // This one will remain private within the closure 
   var myMessage = 'Hello World';

   // This function can refer to the variable with a simple name 
   // instead of having to qualify it with a namespace 
   function getMyMessage() { return myMessage; }

   // Now that we've defined the properties we want in our private 
   // closure, we can export the public ones to the public namespace 
   // and leave the private ones hidden here. 
   var ns = myNameSpace.myPseudoClass;
    ns.displayMyMessage = displayMyMessage;
    ns.getMyMessage = getMyMessage;

 })(); // End anonymous function definition and invoke it

Then outside our namespace we can invoke our methods like this: myNameSpace.myPseudoClass.displayMyMessage();

Read Chapter 10, Modules and Namespaces in JavaScript: The Definitive Guide for a deeper dive into Namespaces and Modules in JavaScript!

If you’re still not convinced you need Namespaces and are interested in reading more about the issues surounding Global Data, then you may be interested in reading Chapter 13.3 (Global Data) in Code Complete.

This post covers Inter / Cross Browser Window Communications using JavaScript.

A common scenario in web applications is: to have Page A open Page B , then have Page A communicate with Page B or vise versa.

One of the techniques floating around the internet suggests that you use Cookies and a JavaScript setTimeout function that listens for the presence of a cookie. So essentially Page A sets a cookie and Page B listens for this cookie and acts on it.

A alternate solution might be to use the JavaScript Browser window.open and window.opener methods. Using these two methods we can achieve inter / cross browser window communication as long as the Same Origin Policy is withheld - a similar approach can be taken for frame and iframe communication.

An example:

// myNewWindow stores the reference to the newly 
//   created window, this provides a handle for defining 
//   and calling methods in the New Window 
var myNewWindow = window.open('about:blank');

// Let us call the alert method in our New Window 
//   from this window (the Original Window) 
myNewWindow.alert('Hello From Original Window');

// Let us call an alert method in our Original Window 
//   from our New Window. So.. Lets use a timer 
myNewWindow.setTimeout(
 'window.opener.alert(\'Hello From The New Window\')', 100);

Click here to run this code live in your browser window using a Bookmarklet, or copy the above code into your Firebug Command Line Console.

Many people appreciate loosely typed languages for the how expressive, elegant, simple, and Zen like they are - and I agree, but I haven’t always thought this way. You see; strictly typed (statically typed) programming languages have always been the mainstay of my programming vocabulary, C++, Java, and C# were the meat and potatoes of my programming language diet. I used these languages (strictly typed) because they were familiar, I understood how their compilers, IDEs, and comfortable class-based inheritance model worked. If someone asked me whether I liked C# (insert strict typed language) or JavaScript (insert weakly typed language) I would immediately have given preference to the strictly typed language. Why? Because that’s where I felt safe, and that’s what I understood - besides who wants to admit they prefer the “weak” language? My preference wasn’t based on knowledge or experience it was based on my familiarity with the strictly typed culture.

I was suffering from Software Ethnocentrism.

Software Ethnocentrism often entails the belief that one’s programming language or development environment is the most important and/or … are superior to those of other software developers. Within this ideology, software developers will judge other groups in relation to their own particular development environment or culture, especially with concern to programming language, methodologies, behaviour, customs, and religion.  - the derived definition (above) is based on Wikipedia’s article on Ethnocentrism. 

I had the tell tale signs of Software Ethnocentrism:

• I thought strictly typed language were “the bomb”  - the only viable solution :)
• I thought Test Driven Development (TDD) and Unit Testing was the panacea
• I was completely obsessed with refactoring tools like ReSharper and Refactoring
• I thought my Compiler and IDE were superior
• and I had complete faith in multipurpose strictly typed languages like C#

Then things changed. I started diving deep into the hearts of weakly typed languages: JavaScript, Ruby, and LISP. Now today, I wonder If the time I spent hung up on strictly typed languages, TDD, and unit testing could have been better spent by expanding my programming vocabulary. If I had only delved deep into the heart of weakly typed languages (like JavaScript, 3 years ago) and grocked the fundamentals of these other languages, then I could have achieved this richer understanding of programming languages that I have today. It’s important to note, that i’m not stating that weakly typed languages are better than strictly typed languages or vise versa, only that both have their place, are equally useful, and should be used when appropriate.

Do you too suffer from Software Ethnocentrism? Try staving off this programming language tunnel vision, learn a new type of programming language. It might be a better investment in your time than becoming obsessed over a microcosm (like say unit testing and TDD).

Steve Yegge makes some humorous jabs at the static type culture:

… I think we can conclude that people who rely too much on static types, people who really love the static modeling process, are n00bs. … Hee hee. - Steve Yegge: Portrait of a N00b

… I think there’s some mystical relationship between the personality traits of “wakes up before dawn”, “likes static typing but not type inference”, “is organized to the point of being anal”, “likes team meetings”, and “likes Bad Agile”. I’m not quite sure what it is, but I see it a lot. - Steve Yegge: Good Agile, Bad Agile

… you have your slob type systems and your neat-freak type systems, and it comes down to personal preference. The neat freaks (Java, C#, C++, Pascal) know damn well that the slobs (Perl, Python, Ruby, JavaScript) are just as productive. Maybe even more so. - Steve Yegge: Egomania Itself

Cartoon Notes: I took this cartoon from Steve Yegge’s blog titled Egomania Itself. It represents the irony of static type languages where everything is a named type - presumably the owner of the property is naming all his objects so he can remember what they are, but in loosely type languages, If it walks like a dog and barks like a dog, I would call it a dog. Read more about Dog Typing er… Duck Typing.

In the larger software community, most agree that:

programming is a social activity, … being the lone wolf … is not what we do anymore - Douglas Crockford

And most of us have come to understand that:

Team dynamics; how well a team works together has a bigger impact on a project than the developer’s individual capabilities. [And that no] individual is a success who hurts the team, and no individual is a failure who helps it. - Software Project Survival Guide

So, it should come as no surprise when large companies that depends almost entirely on team work, lists Team working and interpersonal skills as the VERY most important business skill. - Computer knowledge ‘undervalued’

However; it’s often hard for the those in management to understand that you can’t force people into a team environment - let alone change or mold them. So, if someone doesn’t like working on teams, has never worked on a team, or doesn’t agree with your existing team’s cultural views, then you should ask why. Because:

the people that work for you through whatever period will be more or less the same at the end as they were at the beginning.  If they’re not right for the job from the start, they never will be. - Peopleware: Productive Projects and Teams

In reality, we have very little influence on our team members, poorly matched cultural values will likely result in poorly functioning teams, which in turn negatively results the projects success. Joel Spolsky takes this train of thought a little further and suggests that:

it is much, much better to reject a good candidate than to accept a bad candidate. A bad candidate will cost a lot of money and effort - The Guerrilla Guide to Interviewing (version 3.0) 

However; most organizations don’t have the exposure that Spolsky does, and can hardly find candidates period - let alone the very best candidates. Often in the real world, the only chance you’ll have to guide (influence) any team of developers (or anyone), is to lead by example. Jeff Atwood offers some great advice: 

Cajoling and berating your coworkers into compliance isn’t an effective motivational technique for software developers, at least not in my experience. If you want to pull your team up to a higher level of engineering, you need a leader, not an enforcer. The goal isn’t to brainwash everyone you work with, but to negotiate … So much of leadership is learning to give a damn about other people, something that us programmers are notoriously bad at. We may love our machines and our code, but our teammates prove much more complicated. - Leading by Example

Team work and interpersonal skills are more important than technical skills. The ability to work in a team is absolutely mandatory for today’s software developer.

JavaScript is probably the world’s most popular and misunderstood programming languages and for good reason.
When a developer claims to know JavaScript this generally equates to one or all of the following:

• “I know what JavaScript is, I can learn JavaScript in 30 minutes“
• “JavaScript is for kids, it’s a toy language, it’s easy”
• “I just copy and paste my JavaScript snippets / scripts from the internet”
• “JavaScript is just another programming language like C++, C#, VB.NET, or Java”

If thoughts similar to these have crossed your mind when sizing up your JavaScript knowledge, then you probably don’t know JavaScript.

I would argue that if you’ve never programmed in a functional programming language (like: Lisp, Scheme, F#), never read a GOOD book on JavaScript, or never watched a video on JavaScript, then you probably don’t understand JavaScript at all. JavaScript is starkly different than any other mainstream programming language.

When it comes to JavaScript, if you don’t understand the fundamentals then you’re only punishing yourself.

Here are some things every JavaScript developer should probably understand:

• JavaScript, Mocha, LiveScript, JScript, and ECMAScript are all essentially the same.
• JavaScript is a prototypically inherited (prototype-based programming) language which is very different than the classically inherited (class-based programming) languages like C++, Java, and most of the .NET languages - you know the difference between a prototype-based programming and class-based programming language.
• JavaScript is a loosely typed language - you know the difference between strongly-typed programming languages and weak-typed or loosely typed languages.
• JavaScript is a functional lambda language - you understand lambdas and that functions in JavaScript can be lambdas.
• JavaScript functions can be defined inside functions, inside functions, inside functions, and so on - you can demonstrate this.
• JavaScript uses function scope, has no curly brace ‘{}’ block scope - you understand that this is common attribute of most functional programming languages.
• JavaScript has no private, public, protected assessors, no classes, no enums, no structs - you understand that all these language features can be achieved through objects and function closures.
• JavaScript is classless, but instead it uses objects as general containers.
• JavaScript makes use of garbage collection.
• JavaScript uses truthy and falsy values - you understand which values are truth and falsy.
• JavaScript makes use of the ‘nan’ (not a number) and ‘undefined’ values - you understand the difference between these values.
• JavaScript has pretty good debuggers - you understand how to debug JavaScript from both IE (link) and Firefox (link).
• You appreciate recursion, and understand that recursion is a useful technique in JavaScript.
• You understand that JavaScript Namespaces should be used - you understand the importance of namespaces, and know how to create one (Namespacing Your JavaScript).
• You know how to avoid the JavaScript pseudo-protocol (<a href=”Javascript:alert(’hello’);”), and appreciate avoiding it.
• You know how to avoid embedding DOM Level 0 JavaScript events (<a onclick=”alert(’hello’);”) in your mark-up / document structure, and appreciate this technique.
• You know that JavaScript can make use of two different event models (event capturing and bubbling), but we should only ever make use of bubbling.
• You understand what JSON is and how it’s used.
• You know how to keep you JavaScript, CSS, document structure separate, and appreciate non obtrusive JavaScript.

If any of these points seem foreign, then it may be time to learn JavaScript. With all the hype and buzz around Web 2.0 and AJAX it could be a great way to augment your career while broadening your programming language vocabulary.

Great resources for learning more about JavaScript:

Videos:

• The JavaScript Programming Language: Part 1, Part 2, Part 3, Part 4
• An Inconvenient API: The Theory of the DOM: Part 1, Part 2, Part 3
• Advanced JavaScript: Part 1, Part 2, Part 3
• JavaScript: The Good Stuff: Link
• All these videos are available on the YUI Theater - all the videos are great, watch them all!

Books:

• JavaScript: The Definitive Guide by David Flanagan
• JavaScript: The Good Parts by Douglas Crockford

Links:

• MDC: A re-introduction to JavaScript
• Code Conventions for the JavaScript Programming Language
• JavaScript: The World’s Most Misunderstood Programming Language
• What ASP.NET Developers Should Know About JavaScript
• Best Practices: Implementing JavaScript for rich internet applications
• The seven rules of Unobtrusive JavaScript

Above: PPK's Video from the YUI Theater.

The categorization of roles and topic of role is common in most companies and often discussed during interviews; most interviewers or companies want to know what position you play and how you'll fit into their organization. The interview question is generally mutually exclusive, your choices could be: a Generalist, a Specialist, a Software Architect, a Business Logic Developer, a SOA Developer, a Database Analyst / Programmer, a Graphic Designer, a Web Developer, a Business Analyst, and so on… However; everytime I answer this question I can never respond with an answer that I'm satisfied with, I always feel as though I'm pigeonholing myself into some stereotype or category. From my experience some of the stereotypes associated with roles are: “Web Designers”: artsy, can't really grasp difficult problems, “Generalist”: technically competent, doesn't understand good user interfaces, often doesn't understand the big picture, and so on. It's kind of like someone asking: “what kind of music you listen to?”, but only letting you choose a single genre, then having someone psycho analyze you based on your genre selection - speaking of which, here's a link that already does this (kind of): Which genre of music fits you.

This all brings up the question of identity. What am I, what is my role, what single role do I feel fits my skills and experience? Perhaps I'll start labeling myself as an information technology (IT) addict. :) I love, eat, dream, breath, drink technology. I have an obsession with the Software Development Lifecycle, I always have a couple IT related books on the go, I listen to IT related podcasts while commuting, I like writing code, I write code after work, I write code on the weekends, I contribute to online forums, I edit IT books, I like using Test Driven Development, I like front end work, I like back end work, I like it all.

262728293031

My highlights:

• The session on Agile Project Planning With User Stories, and Refactoring Automated Unit Tests Using Test Smells and Patterns presented by Gerard Meszaros. I’ve been on a couple projects that could be characterized as “Bad Agile”, so Gerard’s presentation hit many chords, one of the comments he made really stuck out. He said something like: “it’s not about the Agile process, it’s about the results, it’s about delivering…don’t be dogmatic”. Sure it’s obvious, but it’s nice to hear it from someone else.  I’m currently in the process of purchasing Gerard’s book: xUnit Test Patterns: Refactoring Test Code.
• Mock objects with Rhino Mocks was another great session (by Shane Courtrille). I’ve been using Rhino Mocks for a couple months now, but there’s always so much to learn from someone with more experience.

I’m trying to make it a point to attend more of these events in an effort to expand my community.

IFS can be described as:

the weariness and stress that results from having to deal with excessive amounts of information - according to the IEEE Spectrum’s (Aug ‘07), Technically Speaking article. 

I think most developers / IT workers have experienced some IFS. An example of IFS might be: the calm, quiet developer who suddenly starts spewing obscenities and smashing their hands through the keyboard, or perhaps the forum poster who asks a simple question, then counteracts every suggestion you provide, and finally attempts to assault you online.

On a daily basis I have to remind myself that:

• Technology can be complex, but it’s not impossible
• Nothings perfect
• There are no silver bullets
• We’re just living the high-tech illusion.

Now let’s move on.

In the mid 80’s DeMarco and Lister found that the “average employee longevity [was] from fifteen to thirty-six months”, that’s about one to three years, and that the “total cost of replacing each person is the equivalent to four-and-a-half to five months”. Joel Spolsky in The Best Software Writing I, mentions that “Recruiting and training a new employee is usually estimated to cost 12 months’ salary, total.” Joel goes on to say that the industry standard for turnover is somewhere around 5%. So accordingly, if you worked at a company with 100 people you’d normally expect to loose 5 employees every year. Anything above 5% and you’re probably working in an environment with high turnover.

DeMarco and Lister point out that, companies with low employee retention rates often enter into a cycle with negative financial implications and “an ugly invisible cost”, because “turnover [produces] turnover”.

This “ugly invisible cost” often manifests itself as:

• Short-term viewpoints, a passing through mentality, degraded moral
• Inexperienced management, early promotion, a top heavy organizational structure
• A feeling of disposability, workers are treated as interchangeable parts, a degraded sense of loyalty
• An undesirable work environment
• A low employee retention rate
• And the cycle continues

Fact 17

Reuse-in-the-large works best in families of related systems and thus is domain-dependent. This narrows the potential applicability of reuse-in-the-large.

It makes perfect sense that companies working within a common domain make use of reuse-in-the-large and often make better project estimations.

On a similar note I found the Level 1 definition of a CMM from Wikipedia quite amusing.

Level 1 software project success depends on having quality people.

Related posts:
Notes on Software Reuse from the book titled “Facts and Fallacies of Software Engineering”

Fact 15

Reuse-in-the-small (libraries of subroutines) began nearly 50 years ago and is a well-solved problem. 

Discussion:
There is a tendency in the computing world to assume that any good idea that comes along must be a new idea. … there is enormous (and often hyped) enthusiasm for this concept, an enthusiasm that would be more realistic if people understood its history and its failure to grow over the years.

Fact 16

Reuse-in-the-large (components) remains a mostly unsolved problem, even though everyone agrees it is important and desirable. 

Discussion:
… we solved the reuse-in-the-small problem as far back as more than 40-something years ago. But the reuse-in-the-large problem has remained unsolved over those same intervening years.

Fact 17

Reuse-in-the-large works best in families of related systems and thus is domain-dependent. This narrows the potential applicability of reuse-in-the-large. 

Fact 18

There are two “rules of three” in reuse: (a) It is three times as difficult to build reusable components as single use components, and (b) a reusable component should be tried out in three different applications before it will be sufficiently general to accept into a reuse library. 

Related links:
Read the entire chapter on Reuse here.
Learn more about this book on Amazon.

Personal computers (PCs) and operating systems (OSs) were developed in the Western world in the English language. In the early 90s the standards for Unicode version 1.0 were set to facilitate the development of multilingual systems. Microsoft’s Windows 3.1J (3.1 in the Japanese language) was released in 1993. Windows 95 and NT supported the basics of the Japanese language, and Windows NT (1993) was the first Microsoft OS to use Unicode internally. By the time a Japanese version of Windows was available the West had already been using Windows 1 - 3.1x and a couple other OSs - Japan was already well behind the Western PC wave.

Image taken from Flickr

The names of people, places and even sushi could not be expressed using the early versions of Unicode. The Japanese language is written with three types of glyphs (Kanji, Hiragana, and Katakana) and uses a Latin based language (Romaji), and western style numerals. Kanji (an ancient Chinese based language) is said to have about 50,000 characters _ for basic literacy you’ll need to know over 2,000 different Kanji characters. Katakana and Hiragana are each composed of about 46 basic characters. Romanji is similar to the English alphabet with 26 characters. With the addition of the western style numerals, symbols, punctuation, uppercase, lowercase, etc… there is an overwhelming number of characters. The Unicode standards were not able to support this sophisticated collection of characters, making PCs inadequate for government, business, and even personal use - subsequently slowing the use of PCs in Japan.

Unicode has come a long way since it was first introducted. Today most Japanese computer users have an English based keyboard and use Romanji - a phonetic equivalence to some Kanji, Hiragana, and Katakana glyphs - to select various glyphs, issues commands, write documents, and control their computer. As a phonetic equivalent Romanji has a number of it’s own translation issues. For example: Salary man is pronounced more like Sarary man, Orange is pronounced like Orangy, Adam is sometimes pronounced Adamu. This is just another contributor to the slow adoption of the PC.

A country in isolation; not only is Japan geographically isolated from the rest of Asia, but in 1641 Japan isolated themselves from the outside world for 213 years (until 1853). Anyone entering or leaving the country faced the death penalty - this time period is known as Sakoku. The effects of isolation have played a significant role in Japanese society and business. Japan still prides itself in being self sufficient and often (understandably) displays anti-globalization / Not Invented Here (NIH) tendencies - these dispositions can also be attributed to the slow adoption of PCs in Japan.

Image taken from Flickr

A sophisticated and complex social structure; Japan has roughly the same land mass as the state of California (US), with four times the population of California, but only 1/4 of Japan is inhabitable - the remainder of land is mountainous or volcanic. To compensate for the minimal space and large population the Japanese have developed a very sophisticated social structure over the past couple thousand years. This social structure is based on community and respect - giving up most respect to deceased ancestors and the elderly. Most people try to maintain harmony within their community. From my observations people shy from criticizing and most decisions must be discussed with all affected parties. Similarly many companies are still somewhat based on the feudal system where positions are heriditary - Presidents, CEOs, etc… are born into their respective positions rather than being selected for their experience or skills. It’s also fair to mention that most Jobs are for life - having multiple jobs is a sign of weakness - and as an employee you are expected to put the requirements of the company over any of your personal needs. A white-collar worker (Salaryman) often works absurd hours (unproductively) due to the cultural tradition of not leaving work before colleauges, and I’ve been told that some companies even have burial grounds for their employees. In these existing structures, almost all Japanese people have a job or a distinct place within society. The introduction of the PCs and the leaps in efficiency and productivity that follow would lead to many layoffs and disruptions within these otherwise harmonious structures.

Links of further interest:

• Japanese Unicode issues: Wikipedia: Unicode Issues
• Wikipedia: The Economy of Japan
• “Japanese workers are renowned for working excessive hours, partly due to the cultural tradition of not leaving work before colleagues, regardless of the actual amount of work.” Read more…
• Japanese Computing: A Short Introduction
• Stratagies for the Japanese OS Market
• A Brief History of Character Codes

The procedure [for Unit Testing] is to write test cases for all functions and methods so that whenever a change causes a regression, it can be quickly identified and fixed. - Wikipedia: Unit_testing

By writing good unit tests and employing a good Unit Testing framework you can significantly improve your software development cycle. By writing unit tests you decrease your dependency on a debugger, decrease source-code tracing (debugger walkthroughs), and so on. And by employing a good Unit Testing framework you can begin to lay the scaffolding for other forms of developer specific testing (integration, system testing, and even GUI testing). Unit Testing also contributes to better documentation - if a developer doesn’t understand the purpose of a component they can now read an additional piece of documentation, the unit tests. Unit Testing and Unit Testing frameworks can bring a team of developers to the same level - the capabilities within a team vary by developer. By using the same underlying framework, by identifying general areas that always need Unit Testing we develop a heuristic approach to testing and with that, test patterns, and a new vocabulary to assist with inter developer communication - design patterns accomplish a similar goal. Marc Clifton has a tutorial on Unit Test Patterns.

Unit Testing has its flaws just like any other technique or methodology - there are no silver bullets. Unit Testing is contingent on GOOD unit tests - it’s just as easy to write bad code that works, as it is to write bad unit tests that pass (work). Unit Testing won’t catch every error, but that’s the reality of writing programs, it’s also why we have a large number of software testing (QA) activities - writing software that is 100% bug free is impossible. These are just a couple issues with Unit Testing.

[Test-Driven Development is] a computer programming technique that involves repeatedly first writing a test case and then implementing only the code necessary to pass the test. The goal of test-driven development is to achieve rapid feedback. - Wikipedia: Test-Driven Development

The Test-Driven Development (TDD) programming technique is fundamental to many of the Agile methodologies - particularly the Extreme Programming (XP) methodology. The TDD approach uses Unit Testing as a process for designing and testing software. The core idea behind TDD is to have the developer “write the test first” then write the code to pass the test. The technique forces the developer to “thinking before acting” which is really a “best practice” advisable for everyone - I would hope that “thinking before acting” is practiced informally by most experienced developers, but that’s often not the reality. Other programming techniques that revolve around the “thinking before acting” idea include: the Pseudocode Programming Process (PPP), and the Program Design Language (PDL) Both the PPP and the PDL have gained exposure through Steve McConnell’s book Code Complete.

The mature unit testing frameworks that have gained popularity through the TDD / XP community are important; unit testing through these frameworks will compliment any quality assurance plan and improve any development process.

For more information on Unit Testing and TDD see the following:

• ScottD’s Musings: My Uber-Test-Driven Development (”TDD”) Links Listing
• Introduction to Test Driven Development (TDD)
• Wikipedia: Test-Driven Development
• Wikipedia: Unit Testing
• Marc Clifton’s Advanced Unit Testing Tutorials (See my previous post: Advanced Unit Testing: NUnit)
• Kent Beck: Test Driven Development: By Example (a great book)
• Construx: Developer Testing Boot Camp (a course)

• Part I: Introduction to unit testing and a case study taking the XP process up to the point of writing some unit tests
• Part II: Implementation of an NUnit look-alike and developing the case study further with real tests and real code
• Part III: Implementation of NUnit extensions, revising and progressing with the case study
• Part IV: Using reflection to create unit tests that are script based instead of code based, and the impact of that on the case study
• Part V: Unit Test Patterns

[The computer] can teach, it can illuminate; yes, and it can even inspire. But it can do so only to the extent that humans are determined to use it to those ends. Otherwise it is merely wires and lights in a box. - Edward R. Murrow

The dwindling interest in computer related professions and the growing demand for these professionals are continually in the news. Governments, teacher associations, and corporations are all taking initiatives, but the problem - as many have pointed out - is much larger lying in a deeper social and cultural context.

In the 50s Edward R. Murrow gave a speech where he criticized television and radio for becoming a form of entertainment akin to show business. Like other intellectuals of the time, Murrow was concerned that the informative, and educational qualities of TV and Radio were being lost. He suggested that the shift from information to entertainment would deeply affect our future, our society, “our culture, and our heritage” (Edward R. Murrow). Now, today TV and Radio is show business (Hollywood), and computers are an entertainment medium rivaling the TV. Today the computer is facing a paradigm shift similar to the shift TV and Radio underwent in the 50s.

Computers are a form of entertainment for most of the younger generation. This younger generation (coined Generation Y, the Google Generation, etc…), have been weaned on robust operating systems, complex (mostly mature) software, the internet, and a popular consciousness (pop culture) that discourages intellectual careers. Not to mention; they’ve grown up in an era of overly complex entertainment and Hollywood. Many of today’s adolescents spend hours listening to music, loading mp3 players, playing games, surfing through web logs, chatting on Instant Messengers, and so on. The underlying technologies facilitating their entertainment are often perceived as magic, like “wires and lights in a box” (Edward R. Murrow). Michael Bishop put it well: “With the same passion that young people enjoy the music players and computer games which the industry develops, they need to realize that their own future lies in creating the software and the applications that enable those experiences.” As Michael points out, we need passion for computers and technology, but in order to inspire passion we need to spark an interest, work against the popular consciousness, and so on.

Sparking an interest; what we’ve been striving for in the software industry is now coming back to haunt us, we’ve successfully insulated the user from many of the complexities surrounding software. We’ve been so successful in abstracted and layered our systems that no one really sees what goes on beneath and as a result most people don’t care. Perhaps the passion for computing and technology could be rekindled if every adolescent were required to use applications like mIRC rather than programs like MSN. mIRC (as many know) is a simple chat application that gently exposes the complexities of the internet, and the world of programming  / scripting.

It’s encouraging to see initiative being taken by corporations, teachers, and governments. I think the most successful initiatives will be at the grassroots level; professionals talking with adolescents, parents (computer professionals) inspiring their children and extended family.

Anyhow; these thoughts are somewhat incomplete and were initially inspired by the movie “Good Night, And Good Luck” - a film depicting Edward R. Murrow.
It’s an excellent movie.

The inconsistent nature of the software industry becomes so repetitious that it eventually becomes consistent. Popular languages, databases, technologies, methodologies, paradigms, and hyped products are always shifting - it's been called innovation, evolution, and many other things.

This statement can be applied to any subject and I recall first hearing it while employed as a private contractor the phrase was something like: “The only thing consistent about the contracting industry is inconsistency”.

The Sapir-Whorf hypothesis says that your ability to think a thought depends on knowing words capable of expressing the thought. If you don’t know the words, you can’t express the thought, and you might not even be able to formulate it (Whorf 1956). - (Steve McConnell, Code Complete 2nd Edition)

Community Server 2.0 had a couple flavors ranging from: a free (restricted) Express edition, through to an Enterprise edition.
After struggling with Community Server documentation and already being weary of “free” editions - as they usually have a catch somewhere - I moved onto the next option.

dasBlog a free, BSD-licensed weblog engine for the .NET Framework. I downloaded compiled and installed dasBlog, it worked, and met my requirements . Now - thanks to the dasBlog contributors - I can move on.

For a summarized (distilled) version of Ross's article view: Distilled: Fixing the Global.asax in ASP.NET 2.0