Archive

Archive for October, 2008

Vernacular Culture and Heretics: Humanity the Zen of Zen?

October 30th, 2008

I found Art Kleiner’s concept of vernacular culture interesting in his book The Age of Heretics: A History of the Radical Thinkers Who Reinvented Corporate Management.

Vernacular as described by Kleiner:

Despite the power of corporate practice, something desperately desirable has been lost in everyday corporate life, and without it, corporations could not truly perform. This lost quality, unnoticed and yet desperately needed, was the vernacular spirit of everyday life …

there is no better word than vernacular for the quality of relationships and culture that dominated community life before the advent of the industrial age … 

Vernacular life was the way of life that still exists in these villages of our dreams … In a vernacular culture the best things in life are free, economic and personal life are mixed together … and every exchange of goods is not just an economic transaction but an expression of the community’s spirit …

the builders of industrial culture didn’t have to reject vernacular culture; they merely ignored it or destroyed it in passing, while the power of finance and operations, the power of the numbers culture, undermined the relationships that vernacular culture depended on.

There’s strong parallels to the vernacular culture, the Agile / Lean movement, open source, buying locally, the Toyota Way and an innate human need for community and contribution. Today, many of the institutes that have been built on industrial culture (GM, Ford) seem to be faltering, whereas those that have been built on vernacular culture (Toyota, Google) seem to be succeeding.

Through the book the author suggests that heretics are often responsible for transforming industrial cultured institutes to ones that embrace vernacular culture.

Kleiner describes a heretic as:

someone who sees a truth that contradicts the conventional wisdom of the institution to which he or she belongs and remains loyal to both entities – the institution and the new truth.

One of the concepts that is continual presented within this text is that conventional wisdom and institutions are often incorrect, as individuals we can change our situation, our work environment, and our world, but in order to make change we need to identify, verbalize, and seek out new ideas and approaches.

I don’t know how I was recommended this book, but I’m really enjoying it!

Author: Adam Kahtava Categories: Book, Musings, Open Source Tags:

Everything I Ever Needed to Know About Software I Learned Somewhere Else, Like Tree Planting

October 26th, 2008

Tree planting is a common job for university / college students in Canada. For those unfamiliar with tree planting, the connotation often conjures images of hippies and tree huggers, but in reality it’s grueling work most often embraced by entrepreneurial minded individuals – most tree planters are trying to pay their way through school or save up some fast cash for traveling. Over the years I have found some strong parallels between my experience tree planting and the software realm.

An Quick Introduction to Tree Planting

The tree planting season begins when the Canadian ground is soft enough to stick a shovel into it (in BC this could be as early as May) and ends in late July or August. As a planter you spend your summer living in bush camps (out of tents) close to remote cut blocks (your workplace) – my furthest camp was 5 hours from the nearest town via logging roads. Bush camps rarely have amenities, you dig your own bathrooms, and shower from the closest puddle. err… water source. As a tree planter your daily job involves getting up hours before sunrise, making lunch, going to a cut block, then spending most of the daylight hours running around desert like wastelands (clear cuts) as you try to plant 3,000 or more trees. 

As a tree planter you’re replacing the trees that lumber mill have cut down, the trees you’re planting are a crop that will be harvested in the next 60 years. You’re paid either by piecework, or on a per tree basis. One tree was worth about $0.12, but the tree / fixed piece price depended on the complexity of the land – for example when teetering on the side of a mountain you could expect $0.30+ per tree (along with the great view). As a student the pay was great, if you planted 3,000+ a day you were making $360 plus a remote allowance based. On top of this you were living in the bush making it difficult (never impossible) to spend your money.

How Tree Planting Relates to Software

Quality, Quantity, and Economics: Tree planters have to meet quality standards – periodically through the day a tree checker validates your work and provides quality feedback. As a planter you need to meet prescribed density requirements (you might need to have at least 8 trees in a 6 meter diameter), you need to meet specie requirements (you might need to have one fir tree for every 20 spruce trees), and you also need to meet planting requirements (the tree needs to be green side up, standing straight, the roots in soil, and the roots can’t be ‘J’ rooted). Usually there is a 10% leeway for poor quality (for every 10 trees you plant a single bad tree), this leeway is granted since it impossible to find a suitable planting site for every tree. As a planter you’re consistently working to keep quality in balance with quantity (since your income depends on your production) – an overly dogmatic approach to quality could mean you didn’t make much money while losing your mind as you searched for a suitable planting site on a rock face. On the other side if you placed too much emphasis on quantity (production) you risked forfeiting a day of work as you painfully pulled and replant (reworked) all of your trees. Occasionally there were severe imbalances between a contract’s quantity and quantity expectations, in these situations we could often negotiate a higher rate, and it wasn’t unheard of to have an entire crew go on strike. Similarly, in software we’re constantly balancing quality, quantity, and the economics of the project.

A Process Unsuitable for Automation: On the surface tree planting (like software development) appears to be automatable. A tree planters job boils down to some core tasks (make hole with shovel, bend over, plant tree, close hole, rinse and repeat 3,000 times a day!). Attempts have been made to automate the process, but the wide variation of terrain coupled with the constantly changing tree specifications are no match for an automated machine – the wide variation in terrain could require riding in a helicopter to a mountain top, riding in a rolligon the next week, or hiking for kilometers through the bush loaded down with trees for days. In the software realm automation is perceived as highly desirable (and some think it’s inevitable), but software, like tree planting is too complex for wide scale automation. Human agility, resourcefulness, and adaptability continues to succeed widespread automation.

The Quest for Continual Improvement: In order to improve as a tree planter you need to be self aware and reflective as you hone your skills daily. Ideally you’re searching for techniques that conserve energy and increase productivity while allowing you to stay in your flow. On my first day I made $-15 dollars in a 10 hour day. In the software development realm there is a constant quest for self improvement and enhancing your productivity.

Motivation: Your income depends directly on your motivation. Similarly in the software realm, if you’re not motivated to maintain and augment your skills, then you soon discover your rate and opportunities directly reflect your motivation level.

Team Work: You spend four months in bush camps with the same group of about 35 people, the camps are further subdivided into crews – with each crew containing 10-15 people. You work with the same people in your crew day-after-day and get to know them in EVERY way – you probably interrupted them taking a sh*t in the middle of a clear-cut, or took shelter in a crummy as a hail storm moved through. When working in a small finite team you quickly learn that it’s not possible to choose your members and that making (and maintaining) healthy relationships with your team members makes everyone’s life easier – and might even keep your sanity. Often times (like when bears are in the area) you work in groups or teams, side by side on a single piece of land. While pair planting you get to know the style of your partner, you can predict where they probably forgot to plant a tree and how they keep track of their line of planted trees. During the day you informally compete with your partner, and cajole each other for fun. Pair planting (cluster planting) relates nicely to paired programming and the importance of team work in the software realm.

Organizational Composition: As a tree planter you are a self employed contractor, you’re responsible for your own equipment, and lining up jobs with multiple companies to bring you through the summer. The composition of each tree planting company varies. Some companies will hire anyone and heavily recruit (these companies typically underbid on land, offer lower prices, and have a high turnover rate), whereas other great companies hire planters based on referrals and experience (these companies are known to have dependable annual contracts and a better environment). The best companies give their crews autonomy, respect, and adequate resources to get the job done. Again this transfers into the software realm.

Communication and Responsibility: Living in remote camps on dangerous logging roads requires additional safety. Communicating with your team is often necessary for survival. Not only are you responsible for yourself, but those around you. Tree planters have been known to be forgotten over night on remote cut blocks hours away from camp because no one knew where they were, or if they even came to work that day. Similarly, software teams should be taking collective ownership of a project, you are responsible for your code as well as the code base as a whole. Communication is essential.

What odd jobs have you taken to get you through college / university? How do you find they relate to the software realm? Have you ever planted trees?

Author: Adam Kahtava Categories: Musings, Personal, Team Work Tags:

Project Failure is not Personal Failure: Emotional Buy-in to Projects, Languages, and Frameworks is Bad

October 23rd, 2008

I was at the point where I could visualize the project’s code, the team had gelled, and we only had a couple remaining issues. This was after almost a year of over time and personal sacrifices. From our perspective (the developers) everything was great. Then for reasons beyond our control, the project was canceled. I was DEVASTATED! Somewhere over the course of this project I had lost my personal life and began equating my personal success to the project’s success. When the project came to a screeching halt, so did I.

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…
Author: Adam Kahtava Categories: Musings, Personal, Software Tags:

Going Ergonomic

October 21st, 2008

I went ergo this year. I upgraded to dual monitors, got a monitor stand, an ergonomic keyboard, and then the ergo mouse – then threw out my original right handed ergo mouse so I could mouse goofy (use my left hand for mousing).

The ergo keyboard was the hardest to master. I unfortunately learned how to type while enthralled with mIRC and ICQ – this was well before the touch typing classes of high school. Since I never really learned how to type, I had evolved a pseudo typing approach. Sure, I always kept my hands on the home row, but they were always off by one vertical row of keys – my left hand would reach for the Y,H,N keys which should normally be controlled by the right hand. My pseudo typing speed was average, but using the new ergo keyboard was a huge challenge – my left hand kept trying to straddle the gap to reach the Y,H,N keys. Relearning touch typing on the ergo keyboard was frustrating, but it now feels natural and I'm surpassing my old average typing speed.

The ergo mouse was pretty straight forward, within a week I was feeling confident with my precision.

Switching hands and using a left hand ergo mouse was more difficult. I often catch myself reaching for my left mouse, like reaching for the stick shift in an automatic car after driving standard. My precision is still off a little, but the position on the left is closer to my keyboard and more natural for my arm and shoulder. Since I try to use my mouse as little as possible, switching hands was also an incentive to learn more keystrokes.

Kudos to Steven Rockarts for suggesting I mouse goofy, if it wasn't for his suggestion I would have cut the left side of my keyboard off! :)

Ergonomics are important for a sustainable and physically tolerable career in computers. 

A couple great post on the subject:

Do you use any ergonomic products?

Author: Adam Kahtava Categories: Ergonomics Tags:

Mouse Gestures Vs The Five Button Mouse

October 20th, 2008

Opera's native mouse gesture capabilities originally introduced me to gestures (mouse gestures basically let you control functionality through mouse button click combinations and mouse strokes). I used Firefox's mouse gesture plug-in for a while, but after acquiring a five button mouse and using browsers with five button support I find mouse gestures useless.

In a browser (and some versions of Windows Explorer) with a five button mouse you get:

  • Back and Forward capabilities (the left and right most buttons)
  • Open in new tab capabilities (clicking the scroll wheel)
  • The standard functionality via the remaining buttons

Do you use mouse gestures or a five button mouse?

Author: Adam Kahtava Categories: Ergonomics Tags:

On Teams: Dysfunction

October 19th, 2008

One of the risks to a project’s success is a dysfunctional team. It’s common for team morale to fluctuate as a project moves through its life cycle – project politics, bureaucracy, challenging overtime demands, etc, can all take their toll on a team. A team under stress can take a couple of diverging roads – from what I’ve experienced a team can rise to the challenge (like a family) and grow stronger, or digress into a winner-takes-all environment (like Survivor).

Teams work best in a trusting environment, and things begin to fall apart when backstabbing occurs – which from my experience results in 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 appetite for control, 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.

Author: Adam Kahtava Categories: Musings, Software, Team Work Tags:

The Machine

October 15th, 2008

Living inside a machine ultimately leads to deep inbred malaise and resentment, the atrophy of creativity and productivity, and the propensity to sabotage. – The Age of Heretics, Art Kliener

At some point, I think we all experience life in the machine.

Author: Adam Kahtava Categories: Creativity, Musings Tags:

On Teams: Leadership and Group Organization Matters

October 14th, 2008

This experiment draws some strong parallels to the software realm.

the experiments … organized some public school, middle-class eleven year olds into [clubs] with five boys in each and a carefully trained college student leader. 

Some of these collegiate club leaders were told to become autocratic. They gave detailed directions to the boys, telling them exactly how to paint their clubhouse signs or build model airplanes. Other, the laissez-faire leaders, stayed out of the way, and in the third group, “democratic” leaders helped the boys execute their own ideas, with as much non coercive guidance as possible.

Laissez-faire leadership, letting the boys do whatever they wanted, bred frustrated cynicism. Under authoritarianism, some boys became extremely obedient … while others fought, bullied each other, and destroyed their own toys. In the democratic groups, boys became more conscientious, more tolerant of each other, less selfish, and more adult.The Age of Heretics, Art Kliener

The reactions these groups exhibited, is similar to what I’ve experienced while working in software teams. The best experiences I’ve had have consistently been in democratically structured teams – with a very fine balance of aristocracy from a team lead or architect. it also follows that the most challenging teams have been rigidly autocratic or Laissez-faire (hands off, with no guidance).

If a system is to have conceptual integrity, someone must control the concepts. That is an aristocracy that needs no apology. … In an unconstrained implementation group, most thought and debate goes into architectural decisions, and implementation proper gets short shrift. – The Mythical Man-Month, Fred Brooks 

The balance between democracy and aristocracy is delicate. A team leaning too much on aristocracy runs the risk of undermining the team, while a overly democratic team can fall into paralysis which places the project’s completion in jeopardy.

Author: Adam Kahtava Categories: Personal, Team Work Tags:

Winforms / Webforms Can Make You Obsolete: Framework or Metaphor Lock-in is a Liability For Your Career

October 13th, 2008

I’ve always been uncomfortable with the ASP.NET Webform / Winform metaphor – I moved to ASP.NET from ASP 3.0 / PHP with no proper Windows development experience. The Webform / Winform metaphor was alien, but the code behind model and the ability to re-use controls drew me in, while the Webform metaphor became a tolerated evil. Today ASP.NET MVC and the announcement that Microsoft has embraced jQuery keeps me interested.

As developers, limiting ourselves to a single metaphor, framework, or programming language is a liability to our career. In order to remain employable and engaged with our work, we need to understand the higher level concepts surrounding our chosen development arena – if you’re working in the webspace this means knowing CSS, JavaScript, HTML, and more than one server-side language. Then beyond technologies and languages we should be looking at transcending principals like design patterns, and good design practices.

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 favorite framework is going to be replaced. … I would love to see everybody learn a bunch of languages because it does make you a better programmer. … Most people will never switch languages. – Steve Yegge, stackoverflow podcast #25 

How To Display Your Amazon Reviews and Wish List (on your site) Using Amazon’s Web Services

October 6th, 2008

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:

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

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.

Author: Adam Kahtava Categories: .NET, ASP.NET, Amazon, Open Source, Software, XML Tags: