My Love/Hate Relationship with JavaScript

So it's been about a year since I blogged about anything. During that time I was forced to work with uggh...JavaScript. It's interesting how you can hate something when you don't really know much about it. In learning and using it in the past year, I have to say my attitude towards the language has completely changed. While I like other languages more, I no longer dislike JavaScript and I find it can be really useful, which is what all engines aspire towards (bonus points if you get the veiled reference).

From my better appreciation for the language, I really have one major criticism: the global scope it uses. While many developers have tried to work around this issue, it's still there...waiting...ready to pounce on the unsuspecting victim. Regardless, I now had a gaping whole in my emotional fabric: I no longer hated something. As vacuums are often filled quickly, I found a new, yet familiar target for my ire: bad programmers. I have always hated bad programmers, which includes my own bad programming efforts, but I realize my former dislike for JavaScript was really a result of bad JavaScript programmers.

So...JavaScript is OK to mostly good and bad JavaScript programmers should "stop it!" (more bonus points for getting cultural references).

Irony

To anyone who actually reads this blog: Sorry for not blogging more frequently. I really haven't had anything worth writing about. Which brings me to my new point.

Why are the spirits of business policies routinely betrayed by people in the business? For example: sick leave and education reimbursement policies were developed to recognize people needing time off for sickness and to attract and retain good talent.

Unfortunately, a LOT of places look down on you, or worse, if you use your sick leave. This helps lead to people coming in to work sick and gets more people sick.

Now onto education, and the germ of this little post. What's the point of education reimbursement if management won't support you time needs, or won't even hire you because of your school needs? It is incredibly vexing.

Need for a new Metaphor

Software Engineering suffers from many things, such as bad management; however, I want to focus on an aspect that I feel stands at the heart of things.

A Bad Metaphor

Somewhere in antiquity, before 1990, people got together to categorize software engineering. Some described it as an art while others wanted it to be a science, or an engineering discipline similar to civil and mechanical engineering. The science advocates won...mostly. I say this because the nomenclature, journals, writing, etc. points towards SE being a science, where practice shows it is sorely lacking in this regard. SE is an art.

Back to our bad metaphor

In describing SE as a science, SE Management became identified with Construction Management. You can see this in names: Architect, Project Manager, Subcontractor, etc. You can see it in the way construction projects are built: requirements gathering, design, blueprints, foundation, framing, roofing, drywall, inspection, sign-off, etc. It is eerily close to the Waterfall method, which most will contend is the worst way to build software of any significance. Obviously, the software as construction metaphor is just plain wrong. Unfortunately, there are similarities and that is where people get sucked into thinking it is correct, or at least "good enough."

Another bad metaphor

Currently, there is a trend to identify SE, or at least hacking, with painting. This is seductive but ultimately laughable. I firmly believe that SE is an artistic effort. This is why great developers are 10x to 30x better than average developers; however, the similarity between SE and painting is superficial. I say this because, while both are arts, painting has not offered any useful insight into creating better software.

We could try to correlate painting layers to an n-tier design or how you really have to think about your art before you create it, but these examples seem contrived and more importantly offer little real value. What we need is...

A new metaphor

So far I have come across two metaphors that I think are much better than the current crop; however, I am currently at a loss as to which is the more accurate.

SE as poetry

The first metaphor comes from Alistair Cockburn. At least that is who I learned it from. He stated, "What if software development were not software development? Then what would it be, and what would the experience be like? I suggest that it is like a community writing epic poetry together (Cockburn, Agile Software Development, v2, p29)." He goes on to describe how the the communal effort would take place, where there would be key poem designers, lead poets, not-so-good poets and great ones, non-poets who are involved in quality and sales, etc. You get the picture. Mr. Cockburn's solution to this scenario is proper communication.

SE as gardening

I first started thinking about this metaphor in mid 2007. Think of a garden. You have all types of plants: flowers, annuals, perrenials, grass, trees, bushes, etc. You even have non-plant items: sidewalks, benches, bird-feeders, etc. All of it has to work together for an overall effect that the owner, or designer, wanted. In addition, it has been built over time by different people with different specific goals.

This metaphor has lots of correlations:
The owner may have switched designers. The suppliers ran out of one type of tree, so they used another similar type. New designers and workers came in months after the old team left. A tree can represent a giant monolithic program, where grass is a distrubuted program. You can even discuss viruses, fungi, and literal bugs that negatively affect your garden paradise.

It is because of this that I feel that the best current metaphor for SE is Gardening.

I absolutey HATE this word and its ilk

Architecting

This is quite possibly the most disgusting abomination in the English language! It's variants, Architected and Re-Architect, are just as bad. There aren't any such words. Before you start saying "well... it's a neologism," understand that it is just bad grammar foisted upon us by consultants who think the word design just isn't sexy enough.

Would a client rather have something redesigned, or re-architected?

Redesigned sounds rather mundane and doable. Re-Architected sounds expensive, requiring great magical ability. Before you get on my case about how I spell re-architected, remember it's a fake word. I can spell it any way I want.

The sad part is the number of seemingly intelligent, technical people using this word in normal conversation.

First Post

I have been toying with the idea of starting a blog for a while now. I began reading them sometime last year (2007) , starting with Joel Spolsky's joelonsoftware. After that, I started reading a plethora of blogs on software, design, usability, languages, business, and industry trends. I have to say that it has been a lot of fun; however, I feel there is hole in the discussions.

I can't quite say what I find lacking for I like and dislike blogs on an entry-by-entry basis. Granted, some blogs seem to have a greater overall cohesion; however, most often it really is like talking to a friend, where you have some great conversations, some not-so-great, and some WTF are you talking about you conceited dumb-ass?

This will be my attempt to join the melee. Perhaps I will provide a coherent voice. I doubt it. I actually had a high-school teacher call me the "king of the non sequiturs." Maybe that would have been a better name for this blog. Oh well, time will tell.