Archive for September, 2008

The Three-step Sequence: Incorrect Assumptions and Experience

September 30th, 2008

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?

Author: Adam Kahtava Categories: Book, Musings, Personal, Software, Testing Tags:

Microsoft and jQuery Finally: Thank-You!

September 28th, 2008

Microsoft is looking to make jQuery part of their official development platform … jQuery will be distributed with Visual Studio
- jQuery, Microsoft, and Nokia

Other links of interest:

I was completely blindsided by this decision.

Author: Adam Kahtava Categories: .NET, AJAX, ASP.NET, ASP.NET AJAX, JavaScript Tags:

Notes on Software Creativity 2.0 by Robert Glass

September 23rd, 2008

Software Creativity 2.0 by Robert Glass (as the title implies and you might expect) is centered around creativity in the processes, methodologies, organizations, and people responsible for producing software. I concur with Steve McConnell’s glowing review (Landmark Book, On a Par with People Ware and Mythical Man-Month).

Robert Glass has given the software world many gifts during his 50 year career in software development. This book stands above his other contributions as his magnum opus. I cannot recommend it highly enough. – Steve McConnell

There’s no need for my personal review, but I will say that if Robert Glass had a blog this book would no doubt be his best of.

Interesting excerpts from Software Creativity 2.0:

When I began working in industry. I was appalled to find that nothing I had learned in graduate school bore the slightest relationship to what I was asked to do on the job. …

Practice often precedes and helps form theory …

The more a creative person knows about the subject of focus, the less the need for creativity …

In order to think originally, we must familiarize ourselves with the ideas of others

Notes about the Creative person’s traits:

They are especially observant …

They see things as others do, but also as others do not …

They are by constitution more vigorous and have available them an exceptional fund of psychic and physical energy …

They usually lead more complex lives, seeking tension …

The creative person is both more primitive and more cultured, more destructive and more constructive, crazier and saner, than the average person. …

Keep in mind I’ve omitted some of Robert’s earth shattering excerpts since I’ve read a couple of his other books (see this older post for details) – my chosen excerpts don’t do justice to the book. Read it yourself! :)

Author: Adam Kahtava Categories: Book, Creativity, Musings Tags:

Satisficing: Getting Things Done

September 21st, 2008

satisficing (finding a solution that works and is supportable), not optimizing (finding the best possible solution) – Robert Glass, Software Creativity 2.0

The term satisficing has been with us for quite some time and is primarily applied outside the software realm. Inside the software realm as developers working under constraints we make satisficing decisions on a daily basis. A satisficing solution would be one that solves the immediate problem with the least amount of resources and effort. The opposite of satisficing might be to expend resources researching, architecting, and then eventually solving the problem with an optimal solution. Satisficing like most things is not a one-size-fits-all approach, should be practiced in moderation (is not an excuse for being lazy), but is a necessary tool for getting things done. In one of my earlier posts (Necessary Skepticism: Skepticism is not Pessimism) I was skirting around this notion of satisficing without having a proper term for it.

From Wikipedia:

Satisficing (a portmanteau of “satisfy” and “suffice”) is a decision-making strategy which attempts to meet criteria for adequacy, rather than to identify an optimal solution. A satisficing strategy may often be (near) optimal if the costs of the decision-making process itself, such as the cost of obtaining complete information, are considered in the outcome calculus

Example: One’s task is to sew a patch onto a pair of jeans. The best needle to do the threading is a 4 inch long needle with a 3 millimeter eye. This needle is hidden in a haystack along with 1000 other needles varying in size from 1 inch to 6 inches. Satisficing claims that the first needle that can sew on the patch is the one that should be used. Spending time searching for that one specific needle in the haystack is a waste of energy and resources. – Wikipedia, Satisficing

Author: Adam Kahtava Categories: Musings Tags:

Transparency: Considerations For Choosing a JavaScript / AJAX Framework

September 20th, 2008

A growing number of development teams are given the opportunity to choose their JavaScript / AJAX Frameworks. This choice is often thrown to the development team because the Architects are more concerned with the bigger picture, and the technical details are over the manager’s head. Letting the development team decide on the JavaScript / AJAX framework produces some great benefits: it gels the team, fosters project buy-in, and creates project excitement.

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 

Author: Adam Kahtava Categories: AJAX, ASP.NET AJAX, JavaScript, Software Tags:

Everyone Is Special, I Wish I Was Special

September 13th, 2008

I had x-ray vision as a child – that’s right, I could see through walls and birthday gifts. I was convinced I had super eyesight and my friends thought they had similar enhanced sensory powers – we thought we were super heroes.  In high school I was a wizard (one of a handful of computer enthusiasts).  University, College, and my first job were similar experiences – I felt special because most of my colleagues were fresh graduates void of the lifelong passion for computers.

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. :)

Author: Adam Kahtava Categories: Musings, Personal, Software Tags:

Noisy Work Environments are Counterproductive, But Compensating With Music Negatively Effects Creativity

September 6th, 2008

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).

Author: Adam Kahtava Categories: Creativity, Musings, Personal, Software Tags:

Thoughts on Blogging: “Turn Up The Good, Turn Down The Suck”

September 3rd, 2008

The factors described in this post loosely determine which types of blogs I've been subscribing to.

Quality over quantity: Some blogs adhere to rigid posting schedules. I've never paid attention to a blog's schedule and wonder if anyone (beside the author) does. I find scheduled blogs result in diluted content and that their posts become daunting to sift through. Eventually I start skimming all their content and might unsubscribe altogether.

Consolidated feeds are bad mmmm-kay: Occasionally blogs consolidate posts from multiple authors, or group similar topics into a single feed, this results in excessive noise with no granular filtering capabilities. I won't subscribe.

Personality is important, Professionalism is dull: Personality should permeate your posts. Software development is kind of boring, live it up, inject some originality, show your true colors, try to be funny, take the risk. We're all human, your readers aren't robots and zombies. As a subscriber I'm more interested in getting to knowing you (the developer) than how professional you're trying to be. Professional flavoured blogs run the risk of being too sanitary – a lesson learned the hard way *yawn*.

Easy on the code: I look at code every day. I'd rather read something funny, inspiring, thought provoking, philosophical, or related to the human factor of software development. Code in blogs can often come across as filler, if I really needed more code I'd head down to Google Code, CodePlex, and download one of the many projects (take a look at Chrome). With code, there's a million ways to do the same thing, if you're code isn't in my specific problem domain, then I'm falling asleep already.

Subscribing and reading blogs is important for software developers and knowledge workers in general. Blogs offer cross pollination of ideas between problem domains, organizations, and people. What factors determine the blogs you read?

Author: Adam Kahtava Categories: Musings, Personal Tags: