Archive for the ‘Team Work’ Category

On Teams: Religious Debates Erode Respect

July 15th, 2010

“religious debates … consist largely of people expressing strongly held personal beliefs about things that can’t be proven. … they rarely result in anyone involved changing his or her personal view. … besides wasting time, these arguments create tension and erode respect among team members, and can often prevent the team from making critical decisions.” – Steve Krug, Don’t Make Me Think

There we have it, religious debates erode respect.

Author: Adam Kahtava Categories: Software, Team Work 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:

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:

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:

Gross Generalizations: Software Evangelists, Rock Star Developers, Senior Developers, and Software Architects

July 13th, 2008

Generalization like rumors usually have some truth to them _ at some point, someone formed a thought around a frequently observed piece of truth and… Viola! A generalization was born (or maybe a rumor). Generalizations are incorrect for every single possible case (the exceptions), but there is truth to them.

That’s my disclaimer; now let’s have fun with generalizations.

The Software Evangelist

The epitome of an Evangelist can be observed on Sunday morning TV:


A congregation frying like bacon on the floor, 800 numbers requesting money seared into your TV set, and an Evangelist at the helm orchestrating the show.

Evangelists are a great source of inspiration, excellent communicators, and great leaders. However, they often present a one sided biased opinion, a narrow focus, and can be driven by ulterior motives (money, power, viewership, readership, etc).  Listen to any Evangelists with a grain of salt.

Rock Star Developers

Rock Stars are on MTV, and featured in tabloids – they live hard and die young. 

The lyrics of Great Big White describe the life of a rock star:

Well I’m a wasted rock ranger
I live the life of danger
On the road to find a higher high
The music of wild rock will get me by

Some companies seek out “Rock Star Developers”, here’s an excerpt from an email I received:

are you a Rock Star? I have an opportunity for a rock star … I am reaching out to you in the hopes that you might the star I and the client are looking for!

So, what is a Rock Star Developer? My perception is a: narcissistic, self-centered, prima donna _ someone who doesn’t work well in a team, doesn’t listen, does whatever they want, and lacks dependability. Hiring a Rock Star Developer probably isn’t recommended – unless your organization has a liberal guitar smashing policy, doesn’t mind drunken belligerency, and is run by a one man show.

Senior Developers

Everyone wants a Senior Developer, but occasionally these developers are more senior than developers, and certainly not senior developers _ often the developer’s age (not experience) determines their title. Studies have shown that a developer with 2 years experience can perform at the same level as a developer with decades of experience. Still some Senior Developers have an unexplainable need to let the world know of their seniority through email signatures, resumes, business cards, LinkedIn profiles, and so on.

If you work for 10 years, do you get 10 years of experience or do you get 1 year of experience 10 times? You have to reflect on your activities to get true experience. If you make learning a continuous commitment, you’ll get experience. If you don’t, you won’t, no matter how many years you have under your belt. – Steve McConnell, Code Complete 2nd Edition

Software Architects

Software Architects can be glorified Senior Developers – an architect might be a developer who is senior (like a curmudgeon with a walker) that needed a new title.

Thoughts on generalizations:

There are two sides to these generalizations, the people who claim to be, and the people who are. The people who claim that they’re a Senior Developer are usually impostors, whereas the person who is a Senior Developer is collectively regarded as one by their peers.

Generalizations (like metaphors) are communication mechanisms, sure, there are edge cases and exceptions. Occasionally I encounter aversions to generalizations. Responses like: “Hey that’s not completely true, X,Y,Z disproves that”, or “Naw… that’s just incorrect” seem to be made when we forget that we’re just using generalizations.

What generalizations stick out in your mind?

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

Living The High-tech Illusion: Software Development is Not Rocket Surgery

June 15th, 2008

#CalgaryBarCamp was swell. It was refreshing to meet such a diverse group of like minded people that all essentially do the same thing (create software), but do it in different ways using different tools, platforms, and languages. The ad-hoc discussions both in the bar and between sessions were my highlight. A reoccurring theme in our conversations was that technology, tools, and platforms don’t matter that much. What really matters is: people, communication, ideas, taking risks, and motivation.

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?

On Teams: Thoughts, and Quotes related to Team Work

January 31st, 2008

Team work and interpersonal skills are absolutely essential for the present day knowledge worker (software developers, and the like). If you don’t like working in teams, don’t know how to work in a team, then you may not be able to find work.

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.

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

Community keeps us Grounded, Expand your Community.

March 4th, 2007

Whether it be a group people living in the same area, the scientific community, the business community, the software community, or the global village, community is what keeps us all grounded.

Community’s facilitate cross pollination (the sharing of ideas, thoughts, and alternatives), and keep egos in check. Communities reduce ignorance, can prevent the Not Invented Here (NIH) mentality, can prevent Social Isolation, and can prevent other personal or business stifling consequences.  By expanding our communities we become more grounded. To expand our community in the scientific / software realm we can attending local events, network with colleagues, participate in online forums, participate in peer reviews, contribute as technical editors, subscribe to industry related magazines and publishing’s, maintain professional memberships, donate time, or contribute to other community related events.

Community is important, expand your community!

In an effort to expand my community I’m:

  • Editing technical books
  • Contributing to online forums
  • Blogging

In the future I’d like to:

  • Present at user groups
  • Contribute to an open source project
  • Attend more conferences

How are you expanding your community?

Related thoughts:

No man is an island, entire of itself
every man is a piece of the continent, …
- John Donne, Meditation XVII, English clergyman & poet (1572 – 1631) 

Not Invented Here, in the context of corporate culture, sometimes occurs as a result of simple ignorance, as many companies simply never do the research to know whether a solution already exists. – Wikipedia: Not Invented Here

If it’s a core business function — do it yourself, no matter what. – Joel Spolsky, In Defense of Not-Invented-Here Syndrome

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