David's Software Development Survival Guide

I mentioned in my last post the need to fail early, fast, and often in software development.
Guy Kawasaki recently posted a great piece on bootstrapping where he explains the point with his sharp style:
" Ship, then test. Perfect is the enemy of good enough. When your product or service is good enough, get it out, because cash flows when you start shipping. Besides, unwanted features, not perfection, come with more time. By shipping, you'll also learn what your customers truly want you to fix. It's definitely a trade-off your reputation versus cash flow so you can't ship pure crap. But you can't wait for perfection either. (Nota bene: life-science companies should ignore this recommendation.) "

Whether expressed as "fail early, fast, and often" or as "ship, then test", the concept is critical to successful software development and innovation at large.
However, as you get closer to impacting customers/consumers, the concept becomes more and more subtle - if not dangerous:
When it comes to impacting the external world, most of the time, you don't get a second chance.

There are at least 3 issues you're facing:
1. Trust:
You cannot test/release/fail early and often with your users, customers, or prospects, and come back to them, and keep on trying stuff on them - only with less issues than the previous time.
You'd be toast.
While the fail early and often concept means that you should hit something; it doesn't mean that there isn't a trust issue.
Kawasaki expresses it as a trade-off between reputation and cash-flow; but unless you have exceptional reputation in the marketplace or with a strong customer fan base, that's actually not an account you can draw funds from - when you're a small player, reputation is more like a Swedish match: you can use it only once.

2. Attention Span:
Trust is one thing at risk; interest and attention is another.
You cannot expect people to wait patiently, with unaltered attention for your next product release.
This is true for enterprise customers expecting a set of feature that is critical to them.
This is even more the case in the consumer space - unless your name is Steve Jobs, Sergei Brin or Larry Page; people will rarely give attention to your product for more than a few seconds; let alone wait for a new better/stronger/faster solution.

3. Freshness of your story:
Closely related to the attention span of your audience is the interest of the media at large (press or blogs): When launching a wide-reaching product or consumer application, and in order to have a successful launch, you will need to have a good product and a great story - and you can use your story only once.
It becomes stale very shortly after it's released.

Back to the concept of failing early, fast, and often -
The fact that you're faced with risks on trust, attention and interest, certainly doesn't mean that you can take a big-bang approach, isolate yourself from the World for a couple of years, and -deus ex machina- put out a solution people will rave about.

There is probably no silver bullet as to when and how to test your solution in the market; but there are a number of common-sense principles:
A key concept is that you need to keep on hitting something - getting feedback about what you're building.
At times, the temptation will be great to say "screw-it, let's just launch".
The question will then be whether you've been obsessive-compulsive or whether you're becoming impatient and sloppy.
There is definitely tradeoff and some balancing act:
. Are you confronting something new that is getting you closer to address the needs of your market?
. Are you reaching diminishing returns in what you do, or how you do it?
. Are you in tunnel vision, absorbed on the current issues and having lost sight of the big picture?

The trick is probably to identify if you're past the point where you will get a second chance - either because the audience you're going to impact is carefully selected (a self-selected fan base or a restricted set of users); and/or because you know you're providing enough of a compelling reason for users to come back.

The Technology Acceptance Model can probably be of help here:
You will get a second chance when there is enough usefulness that your users need to have your solution; and enough usability that they can actually realize benefits out of it.

Note to self and others: this is one of these post that starts with a thought (the central one here being that when it comes to user adoption, you rarely get a second chance), and where I'm circling around, ending-up pulling a whole thread of rumblings - not necessarily in the most coherent and articulate manner. In the spirit of failing early fast, and often; this is the first part of the rumbling.

A central concept to agile programing practices is that no matter how hard you try to plan and design a software solution, you're going to be off the mark.
And the distance by which you'll miss your target largely depends on how far away you're aiming at it; i.e. how much in advance, how far and how deep you're designing your solution.

This is true for your technical architecture: if designed exclusively along a waterfall model; it will most certainly either be under-sized or over-designed - and will rarely perform well, or be cost-effective to maintain.

The problem is even more acute when it comes to specifying functionality and designing end-user experience: if you start coding some functionality according to some written specs frozen 6 months ago, and then throw them over the wall to your users; you can pretty much be guaranteed that your solution will suck - either from a usability standpoint, or from a usefulness standpoint; and most likely from both.

The largely accepted concept that addresses this issue is that we should test early and often, also known as "check-in early and often", "release early and often"; and which I like most expressed as "fail early, fast, and often" - the emphasis being on the idea that it's ok to screw up, and that the earlier you do that in your development cycle, the better off you are.

This is closely related to Risk Management: issues are bound to happen, so the earlier you hit the greatest risk areas, the less likely you are to fail.

This is also very much in line with Gall's Law which states that "a complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: a complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system."

The concept works great and is actually critical to the development of successful solutions - up to a certain point:
There are a number of situations where you can't go out if you don't have enough or don't have the right thing - i.e. situations when you don't get a second chance.
I'll try to expand on this in my next post.

What makes a good technical design?
This is one of these questions I get by way of search engines.

The first answer would be that it depends on who you ask:

In a discussion thread on "What makes a good technical design?", people list a number of great attributes (though often being unclear as to whether these traits are related to good technical design documents or good technical designs):
. "That it does everything it needs to and nothing it doesn't. :)" - KC
. "It's a good design if the thing you design is used in the future in a way that the original developer never anticipated, and it works correctly with no modification." - cbmc64
[Agreed on the first; disagree on the second]

In a similar thread, The Server Side proposes a list of top 10 elements of good software design:
10. Considers the Sophistication of the Team that Will Implement It
9. Uniformly Distributes Responsibility and Intelligence
8. Is Expressed in a Precise Design Language
7. Selects Appropriate Implementation Mechanisms
6. Is Robustly Documented
5. Eliminates Duplication
4. Is Internally Consistent and Unsurprising
3. Exhibits Maximum Cohesion and Minimum Coupling
2. Is as Simple as Current and Foreseeable Constraints will Allow
1. Provides the Necessary Functionality
[1, 2, 3 and 10 are particularly important in my view]

Last but not least, Object Oriented Programming guru Rob C. Martin gives 11 principles:

5 principles of class design:
. The Single Responsibility Principle
. The Open Closed Principle
. The Liskov Substitution Principle
. The Dependency Inversion Principle
. The Interface Segregation Principle

3 principles of package cohesion:
. The Reuse Release Equivalence Principle
. The Common Closure Principle
. The Common Reuse Principle

3 principles of package coupling:
. The Acyclic Dependencies Principle
. The Stable Dependencies Principle
. The Stable Abstractions Principle

These are all useful, deep and insightful - and can probably also make a great impression during dinner in some circles.

The second-level answer as to what makes a good technical design is that there is really no universal answer. It depends.

It should however not vary not based on who you ask, but rather based on what you're trying to accomplish:
What is the business problem that you're trying to address?
What are the resources and timeframe that you have?
What are the constraints that you're facing?

A good technical design is a design that requires the least amount of effort and money while meeting your business requirements; and in particular as they translate into your development speed and turn-around time, maintenance cost, deployment complexity, scalability, or security needs.
There is no right or wrong.

In order to build great designs, you need to be conversant with technical design principles to the point where you feel comfortable not only using them, but also ignoring them.

As far as the current state of software technology, pretty much everything has been written on technical design - but then again, it looks like Search Engines, with their current flaws, want us to write about the topic - and don't seem to lead to anything much relevant.

So here is a list of 3 books that are essential to better designing software and creating solid architectures.
These are classics that are worth much more than what they're being sold for.
With one exception, the list weights heavily towards pure Object Oriented design and concepts. This doesn't mean that highly-structured OO designs are invariably better than the light-structured ones - it just means that in order to make a technical choice, you need to truly understand what your options are.
Onto the list:

. UML Distilled - by Martin Fowler. The focus of this book is as much on UML (which is a critical tool) as on the development and technical design process (where Fowler truly shines). Fowler is able to articulate in a very concise manner the process, challenges, and best practices of creating great OO designs.
Here are two great quotes that convey well Fowler's tone and philosophy:
. "No user is going to help you for pretty pictures; what a user wants is software that executes"
. "A hard deadline works well in concentrating minds"

. Design Patterns - by Gamma, Helm, Johnson, and Vlissides; aka the Gang of Four
This is an absolute classic.
The book contains 23 software design patterns.
There again, the actual patterns are interesting, but what is truly unique and invaluable is the description of the thought process underneath them.
The authors also lay critical principles of good OO designs - including these two:
. "Program to an interface, not an implementation"
. "Favor object composition over class inheritance"

. Building Scalable Web Sites - by Cal Henderson
Cal Henderson played a key role in building the Flickr architecture; so he knows a thing or two about building scalable web applications.
There is a couple of things that make this book extremely compelling:
1. It reflects on a much less formal approach to build solid architectures - the technology stack is LAMP; with PHP intrinsically putting less focus on the high-structure OO principles that Fowler or the Gang of Four are outlining
2. It touches on all the elements required to build high-traffic web applications - this includes general architecture options; authentication and security requirements; localization and internationalization; hosting; partitioning, distribution and clustering; performance and scalability.

As a bonus - here are 3 websites that are worth looking at:
. OO Tips, by Yonat Sharon, contains a great collection of notes on Object Oriented design. The content is sometimes too deeply rooted into Object Oriented dogma - but there again, knowledge is power.
. Mapping objects to relational databases, by Scott Ambler, is a great paper on the key design issue of Object-relational mapping. The article balances depth and clarity, and perfectly articulate how design choices are a question of trade-offs.
.The Anti-pattern catalog, on Ward Cunningham's web site, has an extensive list of design traps, that you can get familiar with - in order to be better able to identify and avoid them.

A number of years ago, the Capability Maturity Model was introduced as a way to measure the maturity of development organizations.
In a nutshell, the concept is that the least mature organizations are relying on undocumented processes, practices and knowledge; and that their success -if any- is the sole result of individuals' heroic prowess.
Grossly oversimplified, the CMM states that organizations mature by gradually developing repeatable processes; then measuring their efficiency, and finally optimizing the way they operate.
Somewhat of a Maslow pyramid of needs applied to organizations - from survival to ongoing self-improvement.
You can read here and there for a more detailed -and clearer- explanation.

The CMM is definitely a good way to "read" a development organization - and address its weaknesses.

Looking back at the development shops I've worked at, and the ones I've worked with; it seems that the maturity of these organizations could also be categorized along an alternative framework, based on 3 very distinct types:

. The Flip-Flop organization:
Flip-Flop organizations are on the lower end of the scale, and are a too common type.
Their essence and commonality lies in the fact that they are lacking focus and a sense of purpose.
Some employ very formal and repeatable processes, others are very Agile; yet they all achieve the same thing: not much, if anything.
A majority of the projects they engage in never come to fruition: they're either shut down in flight, experience a slow death, or do come to completion but with an outcome that has no significant impact.
The management style of these organizations could pretty much be anything - except focused, deliberate, and resolved.
The pattern is self-reinforcing as people quickly understand that there is no point in pushing their limits, that they won't be held accountable for slipping a date, and that they might as well focus on Resume Driven Development.

The common cure for fixing a Flip-Flop organization is to come down with a hammer, set objectives that you can't mess with, and transform it into...

. The Red Army development team
[Apologies to veterans who fought in Stalingrad and freed-up death camps; it's the Management I have in mind...]
The central concept in this type of organization is that it's a crime not to meet a goal or to slip a date - and you might get shot (or fired) for doing so.
Projects need to have aggressive completion dates before starting, and once initiated, there is no turning back unless an Act of God strikes.
There again, processes may or may not be formal/agile/repeatable - although processes do tend to develop very quickly when people need to set boundaries around their responsibility and accountability.
The overall throughput is much greater than in the Flip-Flop organization; the organization does get from point A to point B; but there are 2 major issues:
1. Efficiency is on the same order as driving a military-grade truck to go to the post office (a practice that was popular until recently). Mileage is poor and you need deep pockets in order to operate this way.
2. In software development, the point B defined when you were at point A, rarely has any relevance when you're about reach the said point B. Development is a process of discovery that requires constant adjustments, and markets are typically volatile and demand an ongoing validation of the strategy and objectives.

In order to fix a Red Army organization you need the organization and its leaders to develop a deep concern for both economy and impact - i.e. a focus on getting maximum results without expanding energy unnecessarily.

You then get...

. The Kung Fu organization:
If you're not a fan of Stephen Chow's movies or haven't read Sun Tsu the concept might sound obscure.
What lies within it is a constant focus on quickly assessing your current position, leveraging your strengths and the opportunities presented by the environment, and creating maximum impact with minimal effort.
This requires the organization to be deliberate and disciplined, yet flexible and creative.
In this type of organizations, you'll typically find:
- very lightweight processes
- very seniors engineers that have the respect of the entire organization, but yet are not unquestioned
- a leadership team with a constant focus on performance and results

In a way, Peter Drucker, might have been much closer to Kung Fu than one would have thought.

I'm talking about perseverance here -i.e. "to persist in a state, enterprise, or undertaking in spite of counter-influences, opposition, or discouragement" [m-w definition] - not about data storage...

I recently came across 2 great pieces that are uplifting for any individual or team facing obstacles, and in particular the lack of understanding or empathy from the external world.

The first one is coming from Guy Kawasaki: in a guest post on Sun's blog titled "Five most important lessons I've learned as an entrepreneur" - item 4 reads:
"
Ignore schmexperts. Schmexperts are the totally bad combination of schmucks who are experts--or experts who are schmucks. When you first launch a product or service, they'll tell you it isn't necessary, can't really work, or faces too much competition. If you succeed, then they'll say they knew you would succeed. In other words, they don't know jack shiitake. If you believe, try it. If you don't believe, listen to the schmexperts and stay on the porch."

The other piece is proof to Kawasaki's point - it's a letter from the NY MOMA that was sent to Andy Warhol in 1956.
It reads:
"
Dear Mr. Warhol:

Last week our Committee on the Museum Collections held its first meeting of the fall season and had a chance to study your drawing entitled Shoe which you so generously offered as a gift to the Museum.

I regret that I must report to you that the Committee decided, after careful consideration, that they ought not to accept it for our Collection.

Let me explain that because of our severely limited gallery and storage space we must turn down many gifts offered, since we feel it is not fair to accept as a gift a work which may be shown only infrequently.

Nevertheless, the Committee has asked me to pass on to you their thanks for your generous expression of interest in our Collection.

Sincerely,
Alfred H. Barr, Jr.
Director of the Museum Collections"

The letter ends with a P.S.:
"The drawing may be picked up from the Museum at your convenience."

I recently went through another 3 day management training class - and it was just excruciating; a real punishment for being a manager.
One of my lead, who was also attending the class, had me promise not to use this stuff at the office.

The management field is plagued by a slew of witch doctors that are selling management books and trainings, in the hopes of making millions, while attempting to impersonate true management theorists - such as Drucker, Humphrey, or De Marco.

There are 2 questions that keep on hitting me when I go through these types of trainings -I've stopped going through the books a while ago, but I don't always get, or choose, the option to skip the trainings-:
. What are the components of BS management methodologies?
. Why people eat the stuff?

I only have a partial answer to the second question and it probably has to do with why there are so many variations of Fast Food chains in the World.

I may have a more complete answer as to what is the fabric -if you will- of these management sub-methodologies.

So here are 5 steps to creating a Bullshit Management Methodology:

1. Pick a good, wide-reaching, and difficult problem - e.g.
. quality sucks in most products;
. communicating with people is difficult;
. change is hard;
. we rarely get to retire before age 30;
you name it...

2. Identify common-sense concepts and ideas that, if applied, do address the problem - BUT introduce a thick layer of theories, concepts, and acronyms on top of it:
Don't just say that Quality must be an overall process that needs to be constantly measured and improved; or that when discussing difficult topics with people, you should assess objectives, values, background, and emotions.
Instead, introduce concepts with unique names and acronyms: "method 3", "level 4", SSX, "black belts", whatever...

This step is absolutely critical and has 2 major benefits:
1. No one wants to buy a book that just says common-sense stuff. It's boring.
2. You put your audience on the edge - they need to memorize stuff, make an effort to follow you.
The idea here is that there should be just enough complexity for the audience to follow you, and yet prevent them from analyzing and questioning the virtues of what you're saying.
In other words, they should have just enough to chew on and digest.
And if it makes people hopeful and upbeat at the prospect of solving a pain or addressing a need - they'll ask for more.

3. Ignore other theories and authored work
You should avoid referring to other authors; especially if they're original, critical, thought-provoking, and articulate - they are your competition.
One caveat - it's OK, and actually recommended, to quote people who've given their names to a theory but haven't published much other than specialized research papers. So Maslow is always a great addition.
In any case, you should never list your sources and references in your books / training materials - unless your publisher forces you to mention other published authors.

4. Be assertive as if you had seen the Light and found the Truth
Do not invite self-criticism or doubt.
Push it as far as you can without ever showing an ounce of doubt.
It's OK to call your work a 'philosophy', but you should instead define a dogma.
The bulk of your audience isn't expecting to read Kant or Hobbes when picking your book. They're looking for a ready-made solution that can give them a comforting faith; not for some uncertain philosophical journey raising more questions than they have answers.

5. Be universal
The Management Methodology you're advocating should have the ambition to apply to all aspects of the audience's life.
The 7 Epsilons Quality Management theory is relevant to your kitchen, and Situated Power Communication should work on your spouse, kids, and dog.
And if it doesn't work; it means the reader didn't get it - and she should know it.

This raises the stakes -the Methodology is much more powerful and critical than the audience initially imagined- and simplifies the reader's problem: just buy this book, follow these steps, and all of your problems will be fixed. And you should sign-up for my seminars if they're not.

And when you're done creating your very own Power Management Methodology for the Enterprise - if you've ended up corrupting yourself, feel lost, burned out, or need to get back to the basics - you can always reflect on what Peter Drucker's was writing in the early '70s:
"An employer has no business with a man's personality. Employment is a specific contract calling for a specific performance... Any attempt to go beyond that is usurpation. It is immoral as well as an illegal intrusion of privacy. It is abuse of power. An employee owes no "loyalty," he owes no "love" and no "attitudes"--he owes performance and nothing else."

I talked a while ago about perceived market trends in the programming language world: Java's stronghold seems to remain untouched, PHP is all the craze despite its intrinsic lack of structure, and the Ruby fad seems to be losing momentum - I actually thought it was pretty much dead until I started discussing with friends and was told Ruby is in fact alive and kicking.

How can this easily be validated?
Beyond formal polling -which is quite involved, expensive, and not necessarily accurate-, there are a number of ways to measure language adoption trends: analysis of book sales volumes, result counts in general-purpose search engines as well as blog-centered ones, or number of related job postings.

One of the key to understand strengths and limitations of each of these approaches is to put them in the context of the Diffusion of Innovation theory. In a nutshell, this theory states that 1. technologies spread by gradually addressing the needs of 4 types of users (innovators, early adopters, early majority, and late majority); and that 2. they do so in a non-linear manner, by typically expanding slowly until reaching the early majority, at which point they start expanding at a much faster rate (if and when the technology is successful).

Here is a rundown of these trend analysis methods, followed by actual results:

. Book sales volumes is an interesting source - as introduced by Tim O'Reilly.
One limitation is that the numbers could reflect interest more than actual usage - buying a book on Ruby programming doesn't necessarily mean that I'm actually using it.
From a Diffusion of Innovation standpoint, books would also tend to be purchased not so much by innovators or early adopters (books are typically not published when these categories start adopting a technology) and more by the early and late majorities - so sales numbers would probably better represent technologies that are already in the mainstream as opposed to the emerging ones.
From a practical standpoint, a major issue with this approach is that the numbers are not published on a regular basis.

. Volume returned by search engines is probably the simplest and most accessible method - I've tried to use it in my low-key analysis of web services adoption trends, and TIOBE publishes indexes established based on this.
One objection with TIOBE's index is that -as with any index- numbers can be taken at face value, with the audience ignoring their actual source and its intrinsic limitations:
1. You need to pick your search keywords wisely; and you'll always get a level of noise in the results. TIOBE uses " programming" as their keywords (as in "java programming" or "PHP programming") which might not be the best choice for say Actionscript (the more relevant keyword here being "Flex"). I use the language name as the search keyword - and I'm not sure how many of my results are related to jewelry when searching on "Ruby".
2. Web count probably tends to favor languages on which there is a large established volume of data -i.e. those who've reached the majority-, or those who are creating an unusual amount of buzz (and thus generating a large number of references).

. Technorati, or other similar blog-centered tools, is a useful variation on search engines - these probably tend to favor languages generating a lot of debate and discussions.
The volume is likely to be generated by innovators and early adopters, and is therefore expected to tend to over-amplify early technologies rather than those in the mainstream.

. Job postings are another place to look at.
In fact, the job market could be one of the best indicators of the penetration of a technology: this is where the data is not affected by the volume of interest, publicity, or discussions; but in fact represents where organizations actually stand in terms of executing on a technology.
One major caveat, is that organizations could more heavily recruit skills they don't have rather than the one they already have on staff – i.e. technologies entering the mainstream rather than established ones.
The location of the job offering could also say a lot in terms of the diffusion of the technology: in tech-focused areas (e.g. the SF bay area), the numbers probably tend to favor technologies that are at the stage where they access the early adopters and early majority; in more traditional areas, they would reflect more or less on the early vs. late majorities, depending on how conservative the area is from a tech standpoint (e.g. NYC vs. Washington DC).

To validate my hunch, here are the results of the above 3 approaches (excluding book sales because of lack of current data) for Java, PHP, Ruby, and Flex:
I'm using craigslist for job postings, and also normalizing results to 100% to help the comparison across sources.

. Google:
Java 487 millions; php 12,230m; ruby 130m; flex 95m
[4%, 94%, 1%, 0.7%]

. Yahoo
Java 908 millions; php 2590m; ruby 267m; flex 195m
[23%, 65%, 7%, 5%]

. Technorati:
Java 228k; php 141k; ruby 51k; flex 60k
[47%, 29%, 11%, 13%]

. Craigslist – SF Bay Area (all jobs)
Java 1125; php 773; ruby 257; flex 250
[47%, 32%, 11%, 10%]

. Craigslist - NYC (all jobs)
Java 406; php 606; ruby 143; flex 218
[30%, 44%, 10%, 16%]

. Craigslist - DC (all jobs)
Java 228; php 267; ruby 47; flex 98
[36%, 42%, 7%, 15%]

What does this say? Probably that I need to do some more digging...

- The google results seem to be out of control.
I initially thought this was because of all the pages ending in .php, but the results are not different by much if searching on text only. So I went onto Yahoo, which is different, but still weighted towards php beyond what I was expecting.
Plausible explanations:
1. Php is indeed predominantly used
2. Because of its nature and audience, php is much more "documented" on the web than java is

- The Technorati weighting is indeed quite different from the regular search engines and instead closely aligned with the SF bay area job posting distribution - but I'm not quite sure what to make of it except that I'm not really seeing the amplification of emerging technologies that I was initially expecting.

- In terms of job postings, the balance is leaning towards java in the Bay Area and PHP elsewhere.
Is it really about being conservative, or does it have to do with the nature of the projects in different locations?
Note also that there are less job postings in NYC and DC combined than in the Bay Area - so the question of what constitutes the "majority" might not be that straightforward.

-As far as Ruby is concerned; there is not much that the numbers reveal - is it still in it's infancy, or slowly winding down?
The only way to tell would be to look at the trending over time - which is a little bit more involved.

I might take another checkpoint in 6 months to see where we are.

I recently realized that Yahoo! search gives me a great ranking on these keywords - but then doesn't link to anything relevant.
That's a great question nonetheless... So here are some guidelines.

What makes a good technical design doc varies greatly based on the environment, the level of uncertainty and changes expected, the level of formalism expected or required, the audience and stakeholders, and how the document fits into your SDLC.

There are some guidelines that are good to keep in mind in any case:

Happy writing.

Performance reviews can be a great tool - both for managers and contributors - but most often, their intent is missed and their essence diluted in corporate formalism.

Here is a rundown on some of the issues, and some thoughts on how to fix them.

In most organizations performance reviews are comprised of:
- a written self-review, where employees can reflect on their own performance
- a written manager's review, where managers should structure and formalize their evaluation
- a review meeting, where managers can formally deliver their feedback, and discuss with employees

I believe these 3 components are essential, as they allow proper reflection and communication - on both ends.

To spice things up, performance reviews are often driving, and followed by, salary adjustments.
This sounds quite reasonable as you do want to compensate people based on their performance; but this is also putting a lot of weight on the exercise - most employees get less open to feedback when they think that the perception on how they performed on such or such project is solely guiding their paychecks
[People should instead be compensated based on the overall value they provide to an organization in relation to market rates, as opposed to strictly on short-term performance]

The crux of the problem often starts with the manager's written part of the performance review. These written reviews are either too un-structured -consisting in a loosely defined "Manager's Review" section which will eventually be followed by "Employee's Comments"; or conversely, too formalized - I've had to deal with "systems" where managers needed to rate their staff based on over 100+ questions after which a score would be given.
These type of written performance evaluations result in review meetings with similar attributes - either a set of random recollections and thoughts, or a discussion around a metric system that employees try to game in order to get the highest possible score; hoping that their pay raise will follow.

To be truly effective, to both the reviewer and the receiver, performance reviews need to focus of performance, results and growth - and just that.

In order to accomplish this, I structure both self-reviews as well as reviews around 4 questions:
- What were your major accomplishments over the review period?
- What are the strengths you need to build on?
- What are the areas you need to develop?
- In which ways can we help you become more productive?

While the relevance of the first question is obvious; the remaining questions are meant to help both the manager and the employee understand what they're good at (performance and results are obtained by building on strength, not weaknesses); where they need to improve in order to get greater leverage on their skills; and how can they make a greater contribution.

The last key principle to better performance reviews is that the feedback provided during the review should be no surprise to the reviewee.
People can only get better at their game if they receive constant feedback on their performance throughout the year.

When discussing roadmap options -estimates, plans and development capacity- with Executives, I'm often challenged by their assumption that x staff-weeks of effort here (in the San Francisco bay area) is equivalent to x-staff weeks of effort for our offshore team (located in India).
The challenge for me has been as much to understand what variables affect offshore development productivity, as to communicate it to upper management - in a short and clear manner.

Before going into further details, I should say that
- Our overall development team is medium-sized (20-30 developers)
- Our offshore team represents less than half of that size
- Members of the offshore team are generally very solid and competent engineers; but
. They're on average 5 years more junior that the SF folks
. They have 6 to 18 months tenure with us, when the majority of the SF folks have been working with the product for over 5 years

When talking about differences in productivity, I'm therefore NOT referring to a potential difference due to one of the team being intrinsically less competent or talented than the other; but differences related to experience, background, and distance.

When I have to explain it in less than 10 seconds I usually say that because of the overhead created by the distance as well as the difference in seniority and tenure, we're typically able to get 90+% productivity (compared to the SF team) on 1/3rd of our projects.
For the remaining projects, the overhead is typically so important that it doesn't make any sense to engage on the project at all if it has to be done offshore.

So far, I've identified 3 major factors that affect offshore productivity:

1. Technical competence - meaning abilities, skills, and experience. In my situation, we're mostly affected by the difference in experience. In other cases, you might be affected as well by engineering abilities, meaning having the offshore team not being "as good" as your local engineering team.
The difference in technical competence can be modeled as a percentage of productivity of your local team.

2. Distance - no matter what you do, you will get some overhead related to distance: communication is more challenging when engineers cannot just walk to the next cube to discuss an issue or validate a solution.
The best way I've found to mitigate this is
a. To have the offshore team work on their own set of projects – i.e. minimize the amount of cross-continent communication by allowing the offshore team to work on the same issues and resolve them internally
b. To have an engineer on the local team being dedicated to be the point of contact for the offshore team. This helps understanding where they stand, what their progress and challenges are, and channel and follow-up on communications between the 2 teams
c. To have proper communication solutions in place such as conference calling and/or video conferencing, instant messaging, servers for file transfers, and the like
d. To have regular checkpoint meetings (at least twice a week) with the remote team

While you can very significantly reduce the distance overhead, some will remain.
This can also be modeled as a percentage of productivity of your local team.

3. Nature of work. This is where it gets tricky. There are a number of components that make the nature of the job more or less appropriate to do offshore.
This includes factors such as
. Amount of background info required to do the job. - e.g. Rewriting some SQL code for performance would require close to no new context for a qualified developer to do the job. Conversely, writing a new piece of functionality at the core of your business domain, and using some proprietary framework, would require some significant ramp-up effort as well as ongoing knowledge transfer.
. Amount of iterations required or expected - how much design reviews and other cross-team validations are going to be required
. Size of the job (i.e. small vs. large projects) - this might greatly affect the above factors; e.g. a significant training/ramp-up effort might be more appropriate on a large project

Ultimately, the nature of the work might require both a fixed-cost increment of effort to start the job, as well as an ongoing increment of effort, that could also be modeled as a percentage of your baseline productivity.

To sum it up; if we had to model the above, it would give something like

Offshore Effort = (Baseline Effort x Skill Percentage Adjustment x Communication Percent Adjustment x Nature of Work Percent Adjustment) + Nature of Work Fixed Cost Adjustment

That's probably a little over-the-top for managing day-to-day R&D with an offshore team; but it helps understanding the challenges.
This is one of these cases where modeling is more interesting than the model.

The most interesting part of this is that the productivity of offshore development efforts can vary widely based on these –and potentially other- factors.

What this also says is that offshore development initiatives are bound to be unsuccessful if the distribution and execution of work is not properly thought out.

I was mentioning in my last post 2 widespread -and related- management theories: MBO on one hand, and Theory X / Theory Y on the other.

Both theories are quite general and high level.
They're both deeply rooted in assumptions about what motivate people.
Theory X, which is authoritarian and directive, assumes people on the job are primarily motivated by money, fear, and/or the need for protection.
On the other hand, MBO as well as Theory Y, are centered on fostering a collaborative environment based on trust, commitment and reciprocity where the focus is on end-goals and results.
MBO/Theory Y assume that people on the job are primarily motivated by self-development and the search for personal achievement.

A number of additional management theories exist.
Some of them are bringing fresh perspectives both in terms of styles and methodology, while at the same time providing different spins on underlying motivational assumptions.
These ultimately give us more keys, tools, and options to do better jobs and bring the best out of our teams.
There are 2 of these I was familiar with -Joel Spolky's as well as Ken Blanchard's-.
I also took a look at Wikipedia's entry on Management Styles.
Here is a rundown.

Wikipedia's entry lists 4 styles:
- autocratic; where the leader makes all the decisions and drives them down the organization - the closest thing to Theory X
- paternalistic; where the leader also makes all the decision, but is more concerned about the well-being of employees - a softer variation on Theory X
- democratic; where decisions are made collectively - probably the closest thing to Theory Y; for as long as you understand that corporations' primary goal is not the well being of their employees, and as such are not meant to be democratic organizations
- and laissez-faire; where decisions are not made in a concerted effort - and which is probably Theory Y applied with no drive; or simply the absence of Management.
This nomenclature is interesting because it relates management styles to a form of political government.
Beyond the fact that, in my view, governments and corporations should have radically different goals [the protection and well being of their citizen on one hand vs. making a profit on the other], I can see a couple of limitations here:
The first one is that most of us put a judgment value on each of these forms of government -from unacceptable to desirable- with democracy being the only mature or reasonable system for the vast majority of us.
The second limitation is that these form of management -and the way they're described- seem to be primarily a by-product of the personality traits of the person in charge. The type of work at hand as well as the attributes of the team being managed -size, skill level, or seniority- seem irrelevant to the choice or application of these styles; when in fact they should be key drivers.

Joel Spolsky has his own -very original- way of describing 3 distinct Management styles.
. Econ 101 Management - this style is assuming that behaviors and performance can be driven by the prospect of financial rewards; and therefore assumes that the main motivation for people to work is money.
It uses compensation mechanisms as the main leverage to get things done; and ignores other motivating factors.
As pointed out by Spolsky, this style is both expensive and inefficient.

. Command and Control - this style consists in applying general infantry military methods in the workplace.
It is relying on imposed authority; and is based on the assumption that the subjects are ultimately motivated by fear, or a deep sense of duty.
If you want to play Drill Sergeant on a team of developers, you'll notice that it's quite inefficient and you'll probably soon end up on your own.
[While on the topic; I should mention that in a number of elite defense organizations, where members are highly trained and skilled, the management style can actually get quite sophisticated - see the book from David H. Friedman, Corps Business]

Spolsky' preferred management strategy is what he calls the Identity Management Method - it consists in encouraging people to identify with the organization, and implicitly assumes they will be primarily motivated by the need for Group Belonging.
Team building exercises as well as treating people with genuine care are critical as this strategy heavily relies on reciprocity to foster performance and loyalty.

The identity management method is a great approach that is virtuous and efficient when applied to development teams and other knowledge workers.
The only limitation that could be objected is that it is somewhat uni-dimensional - it doesn't tell me if and how I should vary my management style between junior and senior developers, or how to deal with an upbeat team after an IPO vs. a depressed and disgruntled team going through multiple rounds of layoffs.

To be most efficient, management styles should not only be applied at the overall level of a team, but should also vary based on general circumstances and individual situations.

I've found the most interesting bit on this from management seminars' Ken Blanchard
The method, called one-on-one leadership, consists in identifying where each individual stands in terms of
1. Competence - i.e. knowledge, skills, experience and capabilities; and
2. Motivation - i.e. determination, confidence, and commitment
Blanchard posits that management style needs to be adjusted considerably based on these 2 variables.
More specifically, they need to be adjusted in terms of the amount of direction as well as support being given:
Adjusting direction consists in providing different levels of granularity when stating objectives and giving instructions. A "low competence" individual typically needs a high degree of direction, with a clear and detailed description of what and how things need to be done. Conversely, a superstar developer would only need measurable goals with a description of the desired outcome and underlying intent -providing specific instructions, such as mingling into her code and telling her how to use such or such language feature, would instead be counter-productive.

Management Support consists in the degree of encouragement and validation that is given to an individual.
There again, this should vary significantly based on the level of motivation of the individual: an ecstatic new-comer might need to be paced, a developer going through the challenges of learning and growing needs a lot of encouragement and feedback; and our superstar developer might not need anything but a soft reinforcement of how much she is valued and appreciated.

To take it further, good management style should not only factor levels of competence and motivation, but also what specifically motivates each individual what they like, do best, and aspire to do better or grow into.

[Ed Note:
1. Apologies to my regular readers for not having posted in so long - I got sidetracked... should be back to a 2 to 4 weeks schedule
2. The email subscription has been fixed - you can now use the feedburner email widget on the right to get notified whenever a new post is published]

Shortly after being promoted a manager, someone asked me which management style I was using.
I did find the question a little odd for, at that time, there didn't seem to be many choices in "style" given the field and the environment - technical, volatile, and with most people hating the idea of being "managed".
There are in fact quite a few approaches to managing technical teams; and understanding them is a good step in becoming a better manager.
Here is a tentative rundown:

One of the most known style of management is Management By Objective (MBO).
Popularized by Peter Drucker in the late '50s, its key concept consists in getting buy-in from employees on defined objectives and specific tasks, and asking them when they'll be able to complete their assigned tasks.
Commitment is here essential, as the method relies on:
1. the assumption that the contributor knows better about the task at hand than their managers
2. Once a commitment is made, the contributor will make every effort to deliver on her promise -see the concept of cognitive dissonance for a deeper explanation-

MBO was somewhat of a revolutionary concept at the time, for it was in stark contrast with the generally accepted idea that managers should get results by either knowing more about the job than the people they managed or by having the ability to coerce subordinates into doing things -Management By Intimidation if you will-.
These two approaches are completely irrelevant in the tech field where, if your team members are indeed solid contributors, they'll know more about their jobs than you do; and if you try to "intimidate" them they'll eventually raise their finger -not the one you want- and find a job elsewhere.

Another spin on MBO is Theory X vs. Theory Y, established in the '60s by Douglas Mc Gregor.
Applying theory X consists in managing people by putting emphasis on controlling -meaning not trusting and instead directing and measuring.
Theory Y on the other hand relies on empowering employees and giving them proper level of ownership to get their job done - which is very close with Drucker's MBO.

The key to both theories, and when they would be relevant and effective, lies in what motivates employees in their lives and on the job.
More specifically, theories X and Y are deeply rooted in the Maslow Pyramid of needs:
Theory X can only be appropriate for jobs that only satisfy the lower levels of the pyramid -i.e. "hygiene" needs / jobs that pay the rent.
Theory Y is conversely only relevant in environments where the higher levels of the pyramid (need for group belonging and "self-actualization") can be satisfied:
The need for group belonging makes it compelling for a contributor to deliver on her commitment to her peers, and not let her team down.
The need for self-actualization drives people to learn new technologies, apply new skills, and try to improve their performance.

In my next post, I'll go over a couple more theories on Management styles.