Secrets to Winning at Office Politics - Part 2

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/secrets_to_winning_at_office_politics__part_2.htm]

Following up on my previous post, here are several good quotes from the other chapters of the very good book, Secrets to Winning at Office Politics.

Chapter 4: Political Psych 101: Allies and Adversaries

• "Positive relationships build political capital." (pg. 53)
• "Allies can be grouped into three categories: Friends, Partners, and Connections." (pg. 55)
• "colleagues usually judge your personality and your competence separately." (pg. 55)
• "Those who loudly complain that 'it's who you know' are usually the same ones who never take the initiatives to get to know anyone." (pg. 59) --> as an introverted hermit, this hits home with me.
• "adversaries fall into three groups: focused, emotional, and vengeful" (pg. 63) --> you want to be aware that someone who seems adversarial because they're just focused on their goal is not necessarily out to get you personally.
• " is not an adversary - [they're] simply a difficult person." (pg. 67)
• "Usually, the most effective containment strategy [with adversaries] is to increase your leverage." (pg. 68)

Chapter 5: Political Games: Moves and Countermoves

• "Political games re played for emotional rewards" (pg. 83)
• "Political game players always have a socially acceptable explanation for everything they do." (pg. 83)

Chapter 6: How to commit political suicide

• "If you want to commit political suicide, simply start engaging in any behavior that consumes a disproportionate share of management's time and attention." (pg. 107)
• "Once people arrive at a conclusion, they unconsciously continue to gather evidence that supports their opinion." (pg. 109)
• "There are four common causes of career destruction: (1) poorly controlled emotions, (2) a victim mentality, (3) self-centered foals; and (4) foolish reactions to change." (pg. 110)
• "Many political suicides are so caught up in their own concerns or delusions that when the ax falls, they are totally shocked." (pg. 121)
• "It's a heckuva lot easier to blame somebody else." (pg. 123)
• "if your colleagues are happily  and productively engaged while you're fuming with rage, then you need to take a closer look at yourself." (pg. 124)
• "When someone indicates that your behavior is a problem, don't automatically reject that possibility." (pg. 126)
• "When you are trying to recast your image, remember that others will not immediately notice the change in your behavior. If you're waiting for the applause, it may seem awfully quiet for a while." (pg. 127)
• "if you're not the problem, but people think you are, the political effect is unfortunately the same." (pg. 127)

Chapter 7: Power, Power, Who has the Power?

• Don't confuse "power" with "authority".
• "... any strength, carried too far, becomes a weakness." (pg. 137)
• "Here are some questions to consider in determining a person's power level: ... Do they talk more about the past or the future? ... Who can they go see without an appointment? ..." (pg. 137)
• "Some timid souls, fearing that they will be perceived as pushy, overbearing, or insensitive, simply give their power away." (pg. 138)
• "If you want to look ridiculous, just try using power that you don't have." (pg. 140)
• On pg. 147, the author presents a 2x2 "Power Grid":
  • High level of position and high degree of influence --> Power Players
  • High level of position and low degree of influence --> Empty suits
  • Low level of position and high degree of influence --> Persuaders
  • Low level of position and low degree of influence --> Weaklings
• "An organization's culture is largely determined by the beliefs, values, and preferences of the Power Elite... you must adjust to the culture established by the reigning Power Elite. There is not one chance in a million that you are going to change it." (pg. 149)

BOOK: Secrets to Winning at Office Politics - Part 1

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/book_secrets_to_winning_at_office_politics__part_1.htm]

I am more of a clumsy walrus than a suave politician, so I was fascinated with the book Secrets to Winning at Office Politics. The author conveys her points with hard-hitting stories, 2x2 windows (to show the whole context), and explicit principles. Probably one of the five best books I've read.

At least twice each chapter, I smacked myself in the head, saying "D'oh - that's what I did wrong in that situation". A general theme of the book is that politics aren't necessarily dirty and corrupt - having good political skills can actually be a service to your coworkers because you can be easier to work with and help them achieve their goals.

There were so many good quotes, that I'm splitting it into multiple blog posts.

Chapter 1: Politics is not a dirty word

• "Our hope was that we could keep him from destroying his career."
• "...keep them from becoming their own worst enemy" (pg. xvii)
• "'politics' is what naturally happens whenever people with different goals, interests, and personalities try to work together." (pg 3)
• "...not everyone is interested in promotions. Autonomy, security, responsibility, skill development, challenge, and interesting work are a few of the other rewards that people often hope to find through their jobs." (pg 5)
• "...it's pretty tough to find tutoring in office politics." (pg 6)
• You must be able to answer the question: "How would you like things to be different?" (pg 7)
• "Wishing is a passive activity that can easily degenerate into whining and complaining. Goals, on the other hand, help to define the actions we need to take." (pg 9)
• There are four political types, behavior that (pg 11):
  • Helps your business and helps your personal goals --> winner
  • Helps your business and hurts your personal goals --> martyr
  • Hurts your business and helps your personal goals --> sociopath
  • Hurts your business and hurts your personal goals --> dimwit
• "Never advanced your own interests by harming the business or hurting other people." (pg. 17)

Chapter 2: Political Intelligence and the facts of life

• " wondered why every place he worked was filled with stupid, incompetent people." (pg. 24) --> Sure there are bad companies, but after 10 years and 3 places, if everything is still bad, you probably need to do some self reflection.
• "Clinging to the belief that the workplace should function demographically will only doom you to frustration and disappointment." (27)
• The organization facts of life: (pg. 27)
  • #1: Organizations are not democracies.
  • #2: Some people have more power than others.
  • #3: Virtually all decisions are subjective.
  • #4: Your boss has control over much of your life.
  • #5: Fairness is an impossible goal
• "The person with the most power wins" (pg. 29)
• "Getting worked up about fairness is a waste of time and politically stupid. People who are obsessed with fairness tend to whine, and nobody likes a whiner... politically intelligent people concern themselves with leverage, not fairness." (pg. 31)

Chapter 3: Forget Fairness, Look for leverage

• "she was pulling a power play at the wrong time" (pg. 36) - with respect someone moving houses, who got angry at the movers and threatened not to pay while they still had all her furniture in their truck.
• "Winners are able to accurately calculate the Leverage Equation in any given situation." (pg. 38)
• "being the boss doesn't necessarily mean that you have the most leverage." (pg. 39)
• "Never intentionally offend anyone at work." (pg. 43)
• "'Fairness' seldom determines what happens to you at work - leverage usually does." (pg. 45)
• "...too much passion can be dysfunctional. Dedication to your work may make you credible and persuasive, but those who are too emotionally invested in their jobs can become defensive and inflexible." (pg. 49) --> I always thought passion was good, but it's possible that good passion can be misdirected for a bad result.

More in the next post...

BOOK: Emotional Intelligence

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/book_emotional_intelligence.htm]

I have always admired those who have a firm grasp over their emotions, and I don’t mean the Spock-like characters that appear dead to their feelings. This eventually led me to read Daniel Goleman’s #1 bestseller Emotional Intelligence. While the book was filled with good concepts, two really stood out to me:

• Verbal Bias - Many “techy” people have a verbal bias in their communication. They think it is more “logical” and “objective” to just go with the words that were written or said, and not taint that with someone’s non-verbal inflections. But such a bias is not more logical, quite the opposite. The majority of someone’s communication is non-verbal, and it is illogical to ignore additional (and relevant) information, therefore it’s actually very illogical to have a verbal-bias that ignores - or doesn’t attempt to understand - someone non-verbal communication.
• Emotional Hijacking – I’ve seen coworkers freak out. Rands points out that this means that they care. Great, but I don’t want to be the one freaking out where the frustration of a bad project gets the better of me. It helps to know that most of us have some sort of trigger that will instantly hijack our emotional state and make us go into a state of uncontrollable rage. For example, don’t tell me that “I don’t have time to write unit tests”.

Good emotional exercises that came to mind as I read:

1. Think of every emotion you can. You fail if you can only list “happy” and “sad”. You also fail if you keep listing physical states (“tired”, “hungry”) or mental states (“frustrated”, “focused”). I failed on both accounts. Then I went to google for “list of emotions”.
2. Think of 20 coworkers. What emotions do you think each are feeling? “Rejected” because no on adopted their initiative? “Excited” because they’re on a hot project?

The book has a lot of good zingers:

1. “the brain has two memory systems, one for ordinary facts and one for emotionally charged one.” (pg. 21)
2. “people who cannot marshal some control over their emotional life fight inner battles that sabotage their ability for focused work and clear thought.” (pg. 36)
3. “many people with IQs of 160 work for people with IQs of 100.” (pg. 41)
4. 5 fields of emotional intelligence: Knowing one’s emotions, Managing emotions, Motivating oneself, Recognizing emotions in others, and Handling relationships (pg. 43)
5. “New solutions and fresh ways of seeing a problem do not typically come from worrying.” (pg. 67)
6. “People who are optimistic see a failure as due to something that can be changed so that they can succeed next time around” (pg. 88)
7. “People’s emotions are rarely put into words; far more often they are expressed through other cues.” (pg. 96)
8. There are at least three ways of displaying emotions: minimizing, exaggerating, and substituting (pg. 113)
9. “The two cardinal sins that almost always lead to rejection are trying to take the lead too soon and being out of synch with the frame of reference.” (pg. 123)
10. “Stress makes people stupid.” (pg. 149)
11. “Many things people do at work depend on their ability to call on a loose network of fellow workers” (pg. 161)
12. “[stars] do the work of building reliable networks before they actually need them. When they call someone for advice, stars almost always get a faster answer.” (pg. 162)
13. “There are no grades given in Self Science; life itself is the final exam.” (pg. 268)
14. “The emotional mind is far quicker than the rational mind” (pg. 291)

BOOK: Managing Humans

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/book_managing_humans.htm]

About two Christmases ago, I was shopping for a gift for a tech buddy. Browsing through the local Barnes & Noble, I saw this yellow book "Managing Humans". I thought to myself "what technical geek doesn't need to know better people and management skills?" Relieved to have found the perfect gift, I never thought much about that book since. Then a coworker suggested Michael Lopp's Rands in Repose blog. I was impressed with Michael's take on how "software engineers" meet "people skills", saw that it was the same guy who wrote "Managing Humans", and figured that two (indirect) endorsements for the same book, combined with my quest to improve my people skills, meant I should buy it. $16.49 and 8 days later, I had the book in my hands, and could barely put it down. With each chapter, I thought to myself "this guy really gets it".

The book is divided into 34 small chapters, each based on insightful stories based on in-the-trenches experiences. Lots of people-books offer fluff: "be nice to all your coworkers", "work hard", "always brush your teeth so your bad breath doesn't alienate your coworkers", etc... Michael bypasses the obvious and gets to the good stuff. Some of the big points I took away:

Blunt Truths

1. "Your manager is not a manager until they've participated in a layoff." (pg. 15)
2. "If you're sitting in a meeting where you're unable to identify any players, get the hell out." (pg. 23)
3. "Remember that for every person on the team who has a strong opinion regarding the decision, there are probably four other coworkers who just want someone to make a decision so that they can get back to work." (pg. 28)
4. "you aren't a company until 1.0 is done." (pg. 77)
5. About reacting vs. thinking, and being too busy: "when you're busy, you're not thinking, you're reacting." (pg. 83)
6. About "Malcolm Events" - "Seemingly insignificant events that are intent on screwing you in an unlikely way." (pg. 93) "The only way you're going to learn to identify potential Malcolm events is by going through some horrible, horrible experiences." (pg. 96) Part of avoiding these events is clear and tough communication that most people want to shy away from, such as team status reports that say "We're not doing Phil's favorite feature."
7. "nothing gets everyone's attention like a deadline." (pg. 107)
8. About finding the anchor in a meeting - "Just wait for someone to say something controversial and see who everyone looks at." (pg. 148)
9. "Like it or not, your boss has as much effect on your career as you do" (pg. 163)
10. "A reorg isn't over until someone important has printed out a new organizational chart and presented it in front of the entire company." (pg. 174)
11. About outsourcing your job - "You could be outsourced because your job is so richly defined that it can be documented and explained to any reasonable professional on the planet..." (pg. 179) "Jobs that can be 'well specified' are being shipped offshore." (pg. 183)
12. "A micromanager does not trust." (pg. 189)
13. "Guy who knows the people are the business." (pg. 190)

Other misc quotes

1. "you are not talking to a person when you talk with your manager; you are talking to the organization." (pg. 11)
2. "understanding your manager's place in the political food chain is the trickiest because you're often not in the meetings where he is interacting with his superiors." (pg. 14)
3. "In any freakout, there is normally a very noisy preamble which is designed to get your attention." (pg. 18)
4. "your job is not just management of people, it's management of information." (pg. 105)

BOOK: Winning with People

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/book_winning_with_people.htm]

I am not a people person. However, I do love software engineering, and I recognize that no software engineering project will succeed without people. 95% of every project failure I've ever seen (or heard of) has ultimately been due to people reasons, not technical reasons - two coworkers can't get along, the manager leads the team in the wrong direction, the tech folks can't get the requirements from the business folks, the QA and dev teams bicker about what's "really an issue", etc... Hence, the cruel irony that just like I work on technical skills, I must also actively work on people skills. Sometimes that means not talking about work during the occasional co-worker lunch. Other times it means reading people-oriented books. This latter activity makes me consciously focus on people interactions.

One such book I read was John Maxwells' Winning with People. It was a Christmas present. John has written dozens of books about people, leadership, relationships, and all that. He's got a lot of wisdom. The book is a series of short chapters on various principles like "Never let the situation mean more than the relationship", and "the journey with others is slower than the journey alone." I found it practical, avoiding the common sense clichés like "be nice, work hard, etc..."

I saw a few big take-aways:

• "The journey with others is slower than the journey alone" (pg. 198)
• Quoting Andrew Carnegie, "No man becomes rich unless he enriches others." (pg. 230)
• "If individuals don't possess people skills, they very quickly hit a ceiling in their effectiveness." (pg. 242)
• "Most of us admire and respect people who sustain solid, long-term relationships." (pg. 259)

The book is also filled with good quotes, like:

• Quoted T.S. Eliot as saying "Half the harm that is done in this world is due to people who want to feel important." (pg. 11)
• Quoted someone "the difference between who you are today and who you will be in fie years will be the people you spend time with and the books that you read." (pg. 13)
• "Actions are remembered long after words are forgotten" (pg. 42)
• "People who add value to others almost always do so intentionally."
• "We often expect maturity to come with age, but the truth is, sometimes age comes alone." (pg. 63) - There are young devs who are great, and "experienced" devs who are not.
• "Ultimately the things that bring fulfillment involve others." -  I would find it more fulfilling to use an old technology with friends, where we actually ship the product, then a new "cool" technology by myself.
• "The best way to keep from stepping on other people's toes is to put yourself in their shows." (pg. 73) [I see this continually in the classic software rivalries: managers who want to deliver vs. techies who want to do "cool" stuff; application developers vs. QA, application developers vs. IT infrastructure, etc...]
• "I made a mistake of trying to impress everybody" (pg. 95) - Software engineering is too big, so you can't possibly know it all, so inevitably you'll meet people who know more than you. One of the dumbest thoughts that ever crossed my mind as a younger consultant was "everybody asks me for help, but I don't need to ask anyone else - I must be doing great". Ah, the cluelessness of being young.
• "If you don't like people or don't believe in them, you won't be able to fake it" (pg. 104). Tim's translation: "People can tell when you think they're a moron."
• "Caring for people should precede confronting people" (pg. 107)
• "Quitting is a permanent solution to a temporary problem." (pg 111)
• "Most of the time when you confront people, they will have an emotional reaction." (pg. 114)
• "Most people hate confrontation, but they love resolution." (pg. 115)
• "If you are not honest with yourself, you will not be capable of honest with others." (pg. 126) - Example: If you deceive yourself into thinking the big task will be done in only 4 days, you're going to struggle giving accurate status reports to management.
• "It is more rewarding to resolve a situation than to dissolve a relationship." (pg. 132)
• Quoting someone else: "If you make every game a life-and-death proposition... you'll be dead a lot." (pg. 138)
• Quoting someone else: "A successful man in one who can lay a firm foundation with the bricks others have thrown at him" (pg. 222)
• "People are an appreciating asset only if we are willing to invest in them." (pg. 233)

See also:

BOOK: Making Things Happen, BOOK: Bringing Out the Best in People

BOOK: Complete MBA for Dummies

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/book_complete_mba_for_dummies.htm]

I'm always been intrigued by the non-coding aspects of a project that are necessary for that project to succeed. Much of this includes people and business skills. I keep hearing of co-workers who take business classes, and it sounds fun, but it takes more time than I have right now (building snow-dinosaurs, sandboxes, and Christmas lights for the kids takes a lot of time). So I settled for the next best thing: reading the Complete MBA for Dummies. I was impressed.

The book is a casual 400-page read, and certainly lives up the the "for dummies" genre. It offers an overview of starting a small business, from the basics of management to HR to accounting to marketing and economics. I liked the practical tone.

While a book like this doesn't fundamentally change one's view of business, it is useful to get one to casually think about business-concepts during the normal work day. For each project, it prompts me to ask questions like:

• "where does the revenue come from?"
• "who is paying for this project?"
• "how will this project help the business?"
• "can this thing I built actually be marketed?"
• "who are the customers for this product?"

Continually keeping these types of questions in mind also helps a developer relate to business-sponsors, who are the people that ultimately write the developer's paycheck.

 

BOOK: 97 things every software architect should know

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/book_97_things_every_software_architect_should_know.htm]

A few months back I finished the book 97 Things Every Software Architect Should Know. I've been slow on blogging, so I hadn't gotten around to my standard follow-up post for books I read.

The books consists of 97 short essays, by various accomplished architects, each with a quick insight. It was a casual and fun read, the kind of book that's easy to sneak in a few pages between changing the kids diapers and fixing the house. It's got a lot of good points. I especially recall an essay about how "the database is your fortress" - GUI and Middle Tier apps change, but you will always have your database.

For hard-core architecture, I thought that Microsoft .NET: Architecting Applications for the Enterprise and Patterns of Enterprise Application Architecture were much more systematic and thorough. But overall, it was still a fun read.

BOOK: Microsoft .NET: Architecting Applications for the Enterprise

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/book_microsoft_net_architecting_applications_for_the_ente.htm]

As the .Net platform matures (almost version 4.0!), I'm seeing more and more good .Net architecture books coming out. One such book is Microsoft .NET: Architecting Applications for the Enterprise, by Dino Esposito and Andrea Saltarello.

 

The first section focused heavily on architectural principles. The book was worth getting just for Chapter 3 alone (Design Principles and Patterns), which provided a survey of the various concepts required for high-level architecture, such as OOP, Design Patterns, Structured Design, Separation of Concerns, Dependency Injection, Testability, Security, and AOP.

 

I also liked their chapter on DataAccess. They made a well-reasoned plug for NHiberante and the maintenance benefits of auto-generated dynamic SQL for the data access layer. I admit that I personally have "grown up" with a bias for code-generated stored procedures, but I can see the changing winds.

 

Their book is very focused on the standard N-tier layers: DataAccess, BusinessFacade, Service, and Presentation. Here's the table of contents:

• Chapter 1: Architects and Architecture Today

• Chapter 2: UML Essentials

• Chapter 3: Design Principles and Patterns

• Chapter 4: The Business Layer

• Chapter 5: The Service Layer

• Chapter 6: The Data Access Layer

• Chapter 7: The Presentation Layer

• Final Thoughts

• Appendix: The Northwind Starter Kit

The book didn't discuss much on messaging, caching, validation, logging, system integrations, configuration, or other architectural components. However, most applications make or break on the data access strategy, so I can see the focus there. And, you could have an encyclopedia if you wanted to cover every aspect of enterprise architecture.

 

I found it interesting comparing the book to Fowler's landmark Patterns of Enterprise Application Architecture. Indeed, Dino and Andrea continually refer back to patterns in Fowler. The Dino/Andrea book almost seems intended as a sequel to Fowler's - it adds value by specializing in .Net, having the benefit of almost 6 years of hindsight, and providing constant web references and practical tools (many which didn't exist when Fowler wrote his book). Overall, it's a good read for any .Net Architect or aspiring developer. It's an especially good read for those who grew up as architects in a single company, and therefore may only have exposure to one way of doing architecture.

BOOK: Pragmatic Thinking and Learning: Refactor Your Wetware

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/book_pragmatic_thinking_and_learning_refactor_your_wetware.htm]

I'm fascinated with learning how to learn, so I was excited to finally read Andy Hunt's Pragmatic Thinking and Learning: Refactor Your Wetware. Recall that Andy is one of the co-stars of the hit The Pragmatic Programmers.

This is a good example of a higher-level, "non-syntax" book, something that transcends the "How to program XYZ" genre. (Shameless plug: I had written my own book: A Crash Course in Reasoning, but I can see why Andy's is in the top 3000 Amazon sales rank, and mine is barely in the top 3 million).

My favorite chapter was "Journey from Novice to Expert", as there is such a huge productivity gap here. He also continually emphasized the differences between the two parts of the brain, comparing it to a dual CPU, single master bus design.

It was an enjoyable read, similar to picking desserts out of a buffet. He had a lot of good quotes throughout the book:

• "... software development must be the most difficult endeavor ever envisioned and practiced by humans." (pg. 1)
• "... it's not the teacher teaches; it's that the student learns." (pg. 3)
• "Don't succumb to the false authority of a tool or a model." (pg. 41)
• "If you don't keep track of great ideas, you will stop noticing that you have them." (pg. 53). This is huge. The "slow times" during the day (driving, waiting in line, burping a sleeping baby) are great for mulling over random ideas. It's almost like collecting raindrops. I used to do this, but got lazy the last few years. Andy's chapter inspired me to go out, get some pocket-sized notebooks, and start jotting down random thoughts again (read: future blog entries).
• "Try creating your next software design away from your keyboard and monitor..." (pg. 72). It's ironic, but often sitting in front of the computer, with all the internet distractions, can kill one's creativity.
• "So if you aren't pair programming, you definitely need to stop every so often and step away from the keyboard." (pg. 85). I've seen many shops that effectively forbid pair programming, so this at least is a way to partially salvage a bad situation.
• "... until recently, one could provide for one's family with minimal formal education or training." (pg. 146)
• "... relegating learning activities to your 'free time' is a recipe for failure." (pg. 154)
• "... documenting is more important than documentation." (pg. 179). The act of documenting forces you to think through things, where design costs upfront are much cheaper than implementation costs later.
• "... we learn better by discovery, not instruction." (pg. 194).
• "It's not that we're out of time; we're out of attention." (pg. 211)

Perhaps the best effect from reading this kind of book is that it makes you more aware, such that your subconscious mind is constantly thinking about learning.

BOOK: Software Estimation: Demystifying the Black Art

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/book_software_estimation_demystifying_the_black_ar.htm]

I personally have never met a developer who liked giving estimates. Indeed, it's an uphill battle. It's not just that developers don't like working on things which don't compile. It's also that amidst endless ambiguity, changing scope, and technical challenges, some boss pressures you into a specific date when a non-specific feature will be fully complete (with no bugs, of course). However, every aspiring tech lead must eventually fight this battle. Because software estimation is perceived as a "soft science", it's easy for devs to view it as some necessary tax to tolerate in order to get to the "real" work of coding. Therefore, many devs never try to improve their estimating skills, and hence there are a lot of bad techniques out there.

That's why I'm glad that superstar Steve McConnell dumped his wisdom into Software Estimation: Demystifying the Black Art. The book is filled with gems. Here are some of the key tips that I found practical:

• "Distinguish between estimates, targets, and commitments".
• Once you've given an estimate and schedule, control the project so that you meet the estimate (reduce scope, juggle staff, prioritize features, etc...). The schedule is not like a basketball that you toss in the air and hope that it makes the shot - rather it's like a football that you personally carry to the end zone.
• "We are conditioned to believe that estimates expressed as narrow ranges are more accurate than estimates expressed as wider ranges." (pg. 18)
• Steve emphasizes the "Cone of Uncertainty" - namely that initially, the project has many unknowns, and hence the estimate has a much larger range. However, as the project progresses and more issues become known, the range shrinks. Ironically, it is at the beginner of the project (where everything is most unknown), that many bosses want a stable, singular, estimate. Consider using phase-specific estimation techniques for different stages of the project - some techniques work better at the begininng with higher uncertainty, others work better near the end. Also, within the same project phase, consider using multiple estimation techniques to detect for converging (and hence more reliable) estimates.
• Always have the people who do the implementation work also provide the estimates.
• Sometimes, you can use group estimates. However, each developer should come up with their estimates separately, else the dominant person in the group will likely overly-influence everyone else (especially because most devs tend to be introverts). If their estimates differ greatly, then discuss why they're different, and iteratively keep re-estimating until they converge.
• Collect historical data for past projects, which you can then use to assist with future estimates.
• Count, Compute, Judge. If you can simply count the size somehow (lines of code, modules, etc...) - then that's best. If you cannot directly count, consider computing from things you can count. The point is you always want to avoid subjective judgments when there's a more objective alternative.
• Try to estimate based off of objective quantities like historical data and lines of code, as opposed to subjective measurements like developer quality. The boss will heckle the subjective measurements: "Your estimate assumes only average developers, but we're paying for senior devs, so re-calculate with senior devs. Great, that saved us 1 month."
• When the boss doesn't like the estimate, change inputs, NOT outputs. For example, don't just shave a month off your 5-month estimate because your boss will now be more receptive, rather change the inputs (such as reduce features) so that recalculating the estimate now results in 4 months.
• Establish a standard estimation procedure for your department. By following an objective set of steps, you (the estimator) have a level of "protection" from all the business sponsors who want a lower estimate. For example, you might say "Our standard procedure, which historically returns estimates within a 20% accuracy, always adds 15% risk buffer for this type of application." Then you aren't the "bad guy" for adding the "extra" 15% (funny how anything that increases an estimate is seen as "extra", not "striving for accuracy").
• When presenting your estimates (and schedules), don't even bother presenting nearly impossible scenarios. The boss will just assume that you'll be lucky and of course hit the most optimistic number that is mentioned.
• Always give an honest estimate. Don't lowball the estimate just so that you're boss accepts it - doing so will screw you with an impossible schedule, which will also destroy your credibility ("you can't even hit your own estimate!") If an honest estimate is too high, it is the business sponsor's decision to reject the project, not the developers.

Lastly, consider checking out Construx Estimate.

BOOK: Patterns of Enterprise Application Architecture

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/book_patterns_of_enterprise_application_architecture.htm]

I remember when Martin Fowler's Patterns of Enterprise Application Architecture came out back in 2002. I constantly heard good things, but never got around to reading it. Finally, I buckled down and went through it, and I'm glad I did.

Perhaps the biggest thing I liked about the book was the common vocabulary. Whenever I look at popular community projects (such as Enterprise Library, CLSA, or .NetTiers), or just read star bloggers, ones keeps hearing about all these pattern names (ActiveRecord, Gateway. Lazy Load, Repository, Registry, Service Layer, etc...). While gradually you pick them up, it's convenient just injecting them into your brain all at once.

I also thought his chapters on concurrency were excellent, especially how he explains the difference between an optimistic lock and pessimistic lock. (My simplified interpretation is that an optimistic lock is "optimistic" in that it assumes conflicts are either rare, or easy to resolve, and hence checks for conflicts at the end of a transaction. On the other hand, a pessimistic lock is "pessimistic" in that it assumes conflicts are either common, or very expensive to resolve, and hence prevents the conflict from ever occurring by locking at the beginning of a transaction).

He's also very "no-holds-barred" for doing things the best way. For example in the Metedata Mapping pattern he emphasizes using code generation or reflection - two concepts that for some reason many developers seem reluctant to use.

Lastly, reading a solid book like this just helps you think more about enterprise patterns as you go through your daily coding, and that's a valuable thing.

 

BOOK: Making Things Happen

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/book_making_things_happen.htm]

I got to finish reading another good book: Making Things Happen: Mastering Project Management, by Scott Berkun. Scott worked for 10 years at Microsoft, which included projects on IE, MSN, and Windows. The book is practical and engaging - definitely not one of these ivory-tower things that bore you to death. All the book drawings also look like sketches on the back of a napkin - no MS Visio here.

Perhaps what I find interesting about it is that so many developers think that the only thing they really need is super technical knowledge - "If I'm just brilliant, then everyone will recognize my brilliance, and life will be good." This is simply not true - there are non-technical factors that can kill projects and careers: people skills, politics, bad management, etc... My entire software career, I've seen people significantly smarter than myself who crash and burn because, although they got the tech skills, they are clueless about how to convert those tech skills to "make things happen".

Scott divides his book into three main parts:

1. Plans
2. Skills
3. Management

Amongst those three main categories, he covers a broad spectrum of vital, yet non-technical skills, such as figuring out what to do, making good decisions, how not to annoy people, what to do when things go wrong, and actually getting things to happen.

Some quotes I liked:

• "failures force us to pay attention." (pg. 5)
• [about schedules] "attempting to predict the future - something our species rarely does well." (pg. 31)
• "The more change that is expected, the shorter the milestones should be." (pg. 39)
• "Volume should never be confused with quality. Unfortunately, because volume is easier to produce than quality..." (pg. 79)
• "innovative work often occurs when one person has both requirements and design authority" (pg. 94)
• "programmers tend not to be interested in writing things that don't compile." (pg. 140)
• "If I can't come up with more than one choice, I clearly don't understand the problem well enough: there are always alternatives." (pg. 161)
• "For most tough decisions, the problem isn't a lack of data. Tough decisions exist no matter how much information you have." (pg. 167)
• "You have to  be willing to get burned if you want to develop the skill of putting out fires." (pg. 222)
• "if you can't say no, you can't manage." (pg. 265)
• "As a rule, the further a team gets from reality, the harder it is to make good things happen." (pg. 267)

BOOK: Framework Design Guidelines

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/book_framework_design_guidelines.htm]

A while back I finished reading Framework Design Guidelines by Krzysztof Cwalina and Brad Abrams. It's been ranked well on Amazon, and I can see why. Besides the general guidance one expects from a book like this, it had two other things that I really liked: (1) all the commentary from top .Net Architects, and (2) it provided a behind-the-scenes history of how the .Net Framework and Base Class Library came to be. Especially for practitioners who have made .Net their life (like myself), these are good things to see. I remember back when I started with .Net 1.0 in 2002, and how it's progressed from there to 1.1 and 2.0 and 3.0 and 3.5 and now "3.6" (i.e. .Net 3.5 SP1), so the book has been a good stroll down memory lane.

I'm impressed by the sheer volume of practical examples - this book is not some ivory tower theory pamphlet, but rather written from the first-hand experiences in the trenches.

I think the book got off to a strong start with "What makes a framework easy to experiment with?" As the brunt of it is a giant list of "do's" and "don'ts", it can get a little tedious at time, but it's still a very good read. I think reading an authoritative book like this also gives you a little more confidence that there's not something obvious that you're missing, as well as subtly increasing your code-smell.

Book: Working Effectively with Legacy Code

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/book_working_effectively_with_legacy_code.htm]

A while back I was working on some huge legacy security component. I found it quite challenging, especially the legacy code part of it. Afterwards I thought about writing a blog post on "tips for working with legacy code". While I never got around to that, I did recently finish reading Michael Feather's excellent book Working Effectively with Legacy Code. His book is infinitely better than any measly blog post I could have come up with.

 

This book is awesome. I encounter people who effectively (and naively) say "just write it perfectly the first time." However, that misses the point. For example, many devs weren't even around when the system was first written - they're inheriting someone else's code. The author tackles the problems head-on with concise examples and clear guidance. The book has three parts: the first part starts as a general overview and then explains why this is really a problem, the second part offers tons of practical ways to test difficult code, and the third part explains how to break dependencies so that the code is no longer so tightly-coupled.

 

Two main themes of the book are (A) you want to be able to somehow write unit tests for this code, and (B) tightly-coupled code makes that very difficult. For example, if you've got a some "Employee" object, and its constructor requires a live database connection, singleton references, external configs, and web HttpContext access (like session state), you're somewhat screwed. He then proceeds to show how to salvage that situation by making low-risk changes that allow you to pull the code into test harnesses.

 

You've got to love empathetic chapters like "it takes forever to make a change" and "I can't get this class into a test harness". I think this is a perfect book for anyone dealing with legacy code.

Book: Silverlight in Action

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/book_silverlight_in_action.htm]

I've been excited about Silverlight since I first heard about it over a year ago. Because I started looking at it as an alpha technology, there weren't even the books out yet. So, I used the quickstarts, Bill Reiss's game tutorials, Jesse Liberty's tutorials, and other people's blogs. Well, the books finally started coming out, and I got a copy of Chad Campbell and John Stockton's Silverlight in Action.

 

I liked it. While I got a lot of the background from the online Silverlight resources, the book was just thorough, filled in gaps, and had really good chapters on transforms, animation, and resources (they finally just "clicked" for me).

 

It reminded me of the "good old days" when learning a brand new technology, and you just huddled down with a book and a computer, and hour-by-hour you kept learning something new. I think this book does a really good job of introducing developers to Silverlight.

Book: C# 3.0 in a Nutshell

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/book_c_30_in_a_nutshell.htm]

I recently finished a casual read of Joseph & Ben Albahari's good book C# 3.0 In a NutShell (by "nutshell" they mean 800+ pages).

 

They do a good job of including two audiences - those new to programming (who need C# syntax and the basics of an array explained), and those familiar with C# who just want to see the new stuff. I found the chapters on Linq and Ling-to-Xml very instructive.

 

They also then give a healthy chapter to each of the main parts of the framework. To be able to jump from language design to Linq to System.Net to Reflection to Xml to Serialization and beyond is an impressive feat. I think having that kind of broad knowledge gives the developer a powerful tool belt. Besides the basics (like xml), there are simply cool tools and process that you can never create unless you understand reflection, diagnostics, networking, streams, and even threading.

Book: Code Leader

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/book_code_leader.htm]

I'm always fascinated by the difference between average developers, and good developers. Therefore any book that helps explain how to go "to the next level" is going to capture my interest. Patrick Cauldwell's Code Leader: Using People, Tools, and Processes to Build Successful Software does. With a forward by Scott Hanselman, the book lives up to the hype. Patrick sees the big picture, and leverages his experience to explain a dozen concepts used by good developers - the ones who other developers look to as leaders (hence the title). I'm paraphrasing his chapter titles:

1. Buying vs. Building
2. Test-Driven Development
   1. "writing fewer lines of code should never be considered a design goal."  (13)
3. Continuous Integration
   1. "and developer time is always more expensive than hardware" (25)
   2. He emphasizes that while many projects are tempted to offload their build scripts to a junior dev (to free up the senior devs to do something "important"), it's really in the projects best interest to have your best talent create the build process as that immeasurably benefits every aspect of the project.
   3. "Nobody can check in changes at 5:00 p.m. on Friday before going on vacation." (39)
4. When is it done?
   1. "Nothing paralyzes a team faster than trying to reach consensus on every design point." (45)
5. Testing
   1. "Testing is perceived as less 'fun' than writing 'real' code." (57)
   2. "A clean build server is a happy build server." (89)
   3. "One of the most important parts of your strategy should be to demonstrate progress as early as possible." (97)
6. Source Control
   1. I love this: about source control, he mentioned that some are free - "(free as in puppy, not free as in beer)" (112)
7. Static Analysis
   1. He mentions several tools: NDepend, FxCop, Simian
8. Contracts and Interfaces
9. How to limit dependencies - an emphasis on Dependency Injection and Inversion of Control
10. Model-View-Presenter (MVP)
11. and more...

Overall, a very good book. It's filled with tools and practical examples. I think that every dev lead should be familiar with the topics that he discusses.

Book: Bringing Out the Best in People

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/book_bringing_out_the_best_in_people.htm]

Arguably the most critical component of a software application are the people who build it. If the team doesn't get along, or lacks the drive to learn new things, then the team will eventually fall apart, and the project will come tumbling down shortly thereafter. Therefore while technical books are important, "people" books are important too. With that in mind, I just finished reading "Bringing Out the Best in People" by Alan Loy McGinnis. It was a good, easy read. He wrote it in the mid 80's, but as human nature hasn't changed much since then, it's still very relevant.

 

He offers 12 main points, including:

• "Expect the best from people you lead" -  I interpreted this as giving people the benefit of the doubt, and encouraging them to tackle difficult problems that bring out their best talents.

• "Create an environment where failure is not fatal" - I've seen many ex-consultants who are terrified of failure. "One wrong mistake on this project, and I get replaced with a new contractor, so I better not screw anything up". Such fear paralyzes any normal person because you can't take any risk. But software is an innovative field, and innovation requires risk. Therefore having the schedule allow for some flexibility and giving people second chances are good things.

• "Place a premium on collaboration" - Some management structures over-emphasize "the star". Who single-handedly wrote the most code? Who fixed the most bugs? Who built the toughest features? The problem with over-emphasizing the individual (at the expense of the team) is that it often pits the individual members against each other. Then you get team members quietly asking themselves dangerous questions like "Why should I fix your bug." Think of basketball - yes there are stars, but the coach just wants to win the game - the coach doesn't care who the star is.

There's a lot to discuss about it. In short, it's nice to balance all the technical reading with a "people" book.

Book: Beyond Bullet Points

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/book_beyond_bullet_points.htm]

The corporate world is filled with endless PowerPoint presentations. Many of these are just templated slide after slide of bullet points, which can be boring. A recent book I read, Beyond Bullet Points, by Cliff Atkinson, explained an alternative technique to make PowerPoint more interesting. His idea (as best I understand it) is to mimic what other successful media do (like Hollywood) by telling a story with pictures instead of using bullet points. The end result is that it emphasizes the speaker's own words rather than endless PowerPoint text. I had the opportunity to attend the USNAF back in 2006, and several presentations used this technique, and it was indeed more lively.

Http Pocket Reference

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/http_pocket_reference.htm]

I finished reading the O'Reilly HTTP Pocket Reference. I just wanted a good refresher on HTTP. It was a very good book. I liked that it was only 80+ pages, maybe a 1-2 hour read, and just covered the important stuff. When time is short, there's a definite benefit to just reading a summary as opposed to an exhaustive reference. I notice that many devs don't take enough time to read a full book, so they settle for just skimming blogs. However, that usually gives just a gap-filled understanding because they never get that end-to-end thoroughness. The pocket books offer a good compromise - more thorough than just a blog entry, but still short enough to read when time is tight.