Migrating blog

I've officially migrated my blog from .Net Developer's Journal (http://www.timstall.dotnetdevelopersjournal.com/) to my own domain - http://www.timstall.com/. .NDJ dropped their blogs, so it was inevidable.

It was an interesting technical adventure - I decided to use blogger based on some friend's recommendations, and was pleased with their API - it just worked:
http://code.google.com/apis/blogger/docs/2.0/developers_guide_dotnet.html#CreatingPublicEntries

I was able to set titles, publish dates, suggested Urls, and even dynamically add categories.
I could then write a simple app that posts 40+ entries a day (Blogger only allows a certain limit, so I couldn't do all 500 posts in an hour), so I made the migration tool run over several days.

[UPDATE] I added a page: http://www.timstall.com/p/timstalldotnetdevelopersjournalcom.html to help redirect traffic.

How does a techie know when they're learning the business?

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

Obviously there's a gradual scale, but here's a brain dump:

• You can talk to a non-tech person without using tech speak (Your business skills are strong enough that you don't need to "hide" behind your tech skills to bail you out).
• You can list at least three industry-specific success metrics (besides standards like "revenue" and "profit").
• You can use business decisions as a "tie-breaker" between technologies.
• You can prioritize features and defend your reasoning.
• You know why your CEO or supervisor is upset.
• You know where your revenue comes from, and how it flows through the company’s various systems and departments. Looking at the production database (that records transactions), you can make an educated guess if this year was financially better than last year.
• You can read the year-end report.
• When a new boundary case comes up in the code, you can make an educated guess before verifying with the business analyst. Then you send the business analyst (BA) an email like "I think it's X because of A and B, would that be right?", and the BA can just reply with a "yes" instead of a detailed email correcting all your concepts.

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

Change: Incrementally Making Things Better (Part 6)

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

Part 1 (Intro)

Part 2

Part 3

Part 4

Part 5

Part 6

STEP: Finish it

Congratulations, after giving up 2 weeks worth of nightly poker games, you've almost shoved through an improvement that makes your department (and therefore your life) better. So close, but so far. You'll still need to make the final push:

• Walk the users through until completion - Say you wrote an "alpha-widget-escalator" plug-in into Visual Studio that makes development of alpha-widgets 5x faster. Don't just send the team an email saying "please download this tool from the shared drive and install it". No. Pick 3 developers. Go to their desks, and walk them through until it works on their machines and they can use the "alpha-widget-escalator" without you. Or, say you're trying to add code-generation to the build. Don't just give the build team some templates - be prepared to sit with Jill from Change Control Management, open up the build script, and integrate those templates into the build, and then run the build to ensure the templates actually work.
• Show positive metrics to management about the initiative's success - Objective metrics simplify a manager's life because it lets them tell their boss what a great ROI those initiatives have brought. Suppose you created an auto-merger service to merge change sets between branches. Make it track how many files it's merged so you can tell management that it "automatically merged 800 files a month, at an average of 1 min per file, that's saving us raw time of at least 13 hrs a month, and because devs don't manually do this anymore, we're not missing any files, which saves us 10 errors a month, at an average of 1 hr each..." Of course, sparing devs from tedious tasks also increases moral and reduces distractions which lets them remain "in the zone". Consider sending a survey to the team a month after the initiative is standard, asking them "are you glad we did this". Survey results about developer moral are fair game to provide to management - "80% of our team loves the new auto merger, 15% like it, and 5% don’t care" - Success metrics also show management that the project indeed did work, which builds your credibility to do bigger projects in the future.
• Have an exit strategy - If you do one small initiative a month, it cumulates and you don't scale. Either make that tool/code/process absolutely maintenance free, or coordinate with management to hand it off to someone else.

Appendix

These are miscellaneous topics related to changing an IT department. If I were a star writer, I'd probably have found a way to integrate them seamlessly into the main article. However, it's easiest to just list them here.

What if you're not empowered to make the change?

Sujit spent 5 years developing .Net applications, and his boss has him pigeon-holed as an application-developer. Sujit can't set up build servers, purchase tools, bring in consultants, change the architecture, or do anything that would really turn his department's mess around.

There's still hope. Sujit can always at least defend his own turf and make "Individual Changes" (described above in "Three categories of changes"). For example, he could write his own private tool or script or code block to make it easier for him personally to comply with the broken infrastructure.

He can also support those who are empowered to make the change. Say the star architect, Mary, would love to push good initiatives, but just lacks the bandwidth. Sujit can assist Mary - he can build prototypes for her, do research, or even just provide moral support that all Mary's efforts aren't for naught.

I'm working 70 hrs a week on a death march, and I just don't have time to change

Sometimes you are in a "just survive" phase. People who have never gone through this misery tend to come off as naive and clueless, and don't get why others haven't already made the department perfect. Do what you can, with what you have, where you are.

Perhaps also use this as the reason you need change. Why don't you have time? Is it because the company is fundamentally screwing something - such as they don't do requirements or functional specs so the devs scramble 2 weeks before go-live to massively "correct" the application? You can tell your manager that you realize you need to solve the current crisis first, but this bad process has to be fixed, or you'll constantly be playing catch-up.

How do you know if your initiative is screwed?

First make sure that this is truly "screwed" and not just "inconvenienced" - initial rejection, compromise, busyness, and delays are not "screwed".

Given that, we've all learned the hard way that life isn't fair. Sometimes your department got painted into a corner - say the business (or industry) is fundamentally not profitable. Sometimes the team is just mentally entrenched and refuses to improve things. Other times the key players have "hidden agendas" and it's too much of a political game. However, I think in general the #1 cause of screwing the ability to make positive change is having bad management.

Good managers can internally start repairing the rotting infrastructure, bad managers leave you drifting in the wind. Think of:

• The manager who is so focused on impressing the VP with business features such that they fundamentally don't value the development infrastructure. If you want to keep giving the VP the golden eggs, you need to take care of the golden goose who lays them.
• The manager who won't acknowledge critical process failures even when they do occur. If you spend days to manually juggle 1000 files to deploy, and the deployment keeps failing, and management thinks that "that's just the way software companies are" and hence won't allow you to fix it, then you are screwed.
• The manager thinks that everything is an emergency, and thus constantly yanks you away from any long-term improvement to always put out short-term fires. They'll tell you to pump water till your lungs explode, but they won't let you plug the hole in the boat.
• The manager who just doesn't get it - they know neither the technology nor the business nor the management skills.
• The micromanager who controls every member such that they aren't free to innovate. If your manager controls which tools you can use to do the job on your private workstation ("do it how I did it 10 year ago"), or has developers controlled down to 30-minute tasks, you're probably screwed.

Ultimately, if you are indeed truly screwed and cannot possibly change the department, that’s a topic for another article.

Change: Incrementally Making Things Better (Part 5)

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

Part 1 (Intro)

Part 2

Part 3

Part 4

Part 5

Part 6

 

STEP: Implement it in small, practical stepsAt a certain point, you just need to jump into the arena and get your hands messy. After all the meetings, word docs, PowerPoint slides, business ROIs, and cheering sessions, eventually someone needs to actually start writing code or changing scripts or procuring a tool so that the change actually happens. PowerPoint decks are not change; working C# code running on other people's machines is.Be practical - you must meet people where they're at. You want to give a drowning man a life preserver, not swimming instructions.

• Be prepared to build the prototype yourself - You may not be able to wait for your manager to give you schedule time or for the PMO to hire contractors to build it - necessity may demand that you start something yourself (this probably means nights or weekends). If the team thinks it has potential, you have a good chance of handing it off to other developers and letting them run with it.
• Your deliverable must be something concrete - Tools, approval emails from management, scripts, or code blocks are all concrete. An email with a link to a "cool" article, or a suggestion of what we "should do if we only had time", is not concrete - it will no more feed your team's need for improvement than an article on restaurants will feed a hungry family.
• Make it work - If you're making a tool, make it easily available (say, publish a working version to a public share - don't require them to compile the source code themselves), make it run on their machine, and ideally give it default config values so that it does something useful right off the bat. From the time Kurt agrees to look at your tool and you arrive at his desk, you have minutes to download it onto his machine, click a single icon or dos command, and have him see the pain that the tool saves him from.
• Start small, and continually add value in incremental steps - Have some deliverable every week. If you're working 20 hours on a project, there's got to be something to show for it. Avoid the "just give me 3 months and I'll give you the perfect solution," because they'll never give you a blank check for 3 months. Even if they do (say you've built up a great reputation with previous successes, so management risks big schedule time on your ideas), some big emergency will interrupt you 2 weeks in. You'll be constantly distracted with the "urgent" so you'll never get to actually do the "important". You're 3-month salvation project will lay in mothballs, taking some of your credibility with it.
• Don't be paralyzed by perfection. I.e., "perfect is the enemy of done". An imperfect solution that actually does something is adding more value (and relieving more pain) than the perfect solution that never got built. Consider building a quick "band-aid" or "throw-away" solution now to stop the bleeding and then building that perfect solution in 6 months when the schedule magically opens up and you have all the time in the world (yes, this is sarcasm).
• Don't be paralyzed by "coolness". Lots of developers like "cool" new technologies. However, such technologies often have risk and learning curves - which may mean that you only have enough time to come up-to-speed with the tech, but not to actually build something useful with it. Many of the infrastructure problems that most shops face have already been solved with older technology - look at classic books written in the 1990's like Code Complete and The Pragmatic Programmers, and ask yourself - how many of those good practices is a suffering department still lacking? Nightly builds, automated deployment, unit tests, modular design, layers - they were all done with over 10-year old technologies. If some cool new technology saves your day - great - but don't limit yourself to it. Sometimes a good old fashioned xml file and console app plumbing is sufficient to save your infrastructure.

Keep in mind that you must do all of this while still getting your Boss's priorities done. You cannot just "go rogue" and abandon your official responsibilities to do a bunch of research and innovation.

NEXT:  Part 6

 

 

Change: Incrementally Making Things Better (Part 4)

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

Part 1 (Intro)

Part 2

Part 3

Part 4

Part 5

Part 6

STEP: Determine which initiatives to push

I am continually surprised by how many smart, energetic, and good-intentioned veterans fail to change their organization because they're pushing the wrong initiatives.You cannot boil the ocean. There are simply too many good initiatives, and you cannot do them all. And even if you somehow could change the entire department (say you win the lottery, and kindly use it to hire a team of star consultants to fix everything), your team couldn't absorb it all. Therefore you must pick your initiatives wisely. Keep in mind that success will increase your credibility with the team, which encourage more success, whereas failure will decrease your credibility. Therefore a small success that actually just works is better than a huge initiative that "almost" works. Unemployed departments are full of cool projects that "almost" work. Here are guidelines to help pick good initiatives for change.

• Knock off the low-hanging fruit. Start adding value (and therefore building credibility) with small wins - perhaps a quick tool or code refactoring or convention you can get done in less than a day.
• Emphasize the high ROI ideas first. For example, updating legacy code that already works has a low ROI because you've gone from "app that works" to "app that worked - gee, I hope I didn't break anything - but now it's easier to maintain." Look for industry-proven changes that give a big return, such as the introduction of code generation, reusable blocks, unit testing, developer tools, change control, etc... New ideas that just "tax" the already-busy developers will go flat.
• Focus on new code. No-one wants to go back and re-write legacy code. Much easier to get people to adapt for new code. If every change has to be applied to 2 million lines of legacy code, it will be like dragging a lead ball around; nothing will get done.
• Pick changes that cooperate with other initiatives. If you're company is desperately trying to improve performance because angry customers complain about slow page loads, now's the time to introduce a caching framework. It will be like running with the wind at your back instead of against your face.
• Break big initiatives into smaller steps. You may not be able to introduce that new attribute-based validation system right away. However, perhaps you can first start building a static utilities library of common validation functions so all the logic gradually gets aggregated in one place. Then you could modify the data layer to pass in entities. Then you could add the validation attributes to the properties on those entities and have a reflection-based component apply the logic. You may not be able to do the big goal all at once, but you could do the small steps piece-by-piece.
• Show how the idea supports the business goals. The easy way to do this is to ask what business goals the managers care about, and pick technologies to support those, as opposed to picking techs that you think are "cool".
• Have either unanimous team support or objective success metrics. We all love hard data, but sometimes a developer just has a "gut feeling" that they know something is right, and they don't have the data to immediately measure it. General rule: if everyone already wants the same goal, then you don't need to convince them with objective metrics ("we really need a tool to automatically merge changes from one branch to another"). However, if people aren't convinced, then you will need some way to objectively measure the benefit.
• What do you care about? Even if something has low ROI, if you'd enjoy it such that you'd spend your own weekend building it - and would have fun doing so - then go for it. You hit two birds with one stone - you get to play with a niche technology or cool tool, and your day job benefits from it.
• What do others care about? - What changes does the rest of the team want? If Lenny wants to automate deployment, and Susan wants better refactoring, and Sunil wants reusable UI controls, then consider adding your weight to those.
• What are the prerequisites? Does your pet project require something else, say purchasing a new tool, refactoring tons of code, or a new team convention where people suddenly change their habits? If so, focus on those prerequisites first.
• What other opportunities does this open up? Related to the previous point, some initiatives open up the door for other big opportunities. Say you purchase a tool (like CodeSmith) to introduce code generation so you can automatically generate data access CRUD plumbing. You can then use that tool to also code generate many other things (base data, install MSI packages, proxy classes, etc...)
• Meet people where they're at - If the team culture is completely opposed to pair-programming, you probably don't want that to be your keynote initiative. If the team is being burnt alive putting out fires, they won't care about anything other than a water hose.
• Can this initiative succeed? Seriously. Remember that a small success is better than a big "almost". Focus on attainable goals.

Given these criteria, prioritize your ideal changes. If there's a hundred things you want to change - great - make an excel list. But then pick your top 3. Then pick your top 1.Some people need to see a list. If that's the team culture, then consider making an excel sheet. Depending on your team, you can make it informal (like the sample below), or very formal - complete with numeric weightings. There's no one-size fits all. If it's too informal, your team may say you "haven't thought it through". On the other hand, if it's too formal, then they may get stuck on inconsequential details like whether making a CI build takes 4 hrs or 8 hrs. In general, you'll want at these pieces of info about each initiative:

• Buzzword - Some label, less than 3 words, that distinguishes the concept so everyone can easily refer to it.
• Description - Any special notes or hints about how to do it.
• Effort - Is this big, medium, or small? A formal scorecard could have an hour estimate here.
• Benefit - Is this project even useful? A formal scorecard could have dollars or time saved here.
• Prerequisites - Must be in place for this to work?
• Who cares - Successful initiatives need people to support them. Will this benefit Cary in IT, the entire QA team, or make your manager's life easier?
• Obstacle - Why isn't this already done? Is it just lack of time?

Here's an informal sample. Of course you can add more columns and vary it up depending on your team culture. Note that some items will be small (get account access), but others could be team-wide initiatives (enforce unit test code coverage).

 

Buzzword	Description	Effort	Benefit	Prerequisites	Who cares?	Obstacles?
Access to QA database	Get devs read-only access to QA database	Minor - ask security team	Medium - lets devs assist with QA bugs	Manager approval	Devs, QA	Martin fears this will hurt QA performance
Purchase ETL tool	Instead of building ETL ourselves	Minor, but costs $$$	Medium	Manager approval	Devs, QA (easier to test)	Procure funds
Developer CI build	Use TFS to have hourly build for dev source code	Medium (less than a day with Monty's help)	Huge - instantly detect compile errors, hook other steps into build like unit test and MSI packaging	Build Server, management to insist the build passes	All devs, managers,  Bart [a senior dev] especially wants this too.	No spare machine for the build server
Split VS solution	Current solution is too big, hard to work with	Small	Faster compile times	Senior Dev support	Half the devs	Time
Make validation library	Put validation logic in reusable utilities	Small to start, could be big	Standard validation, supports future framework	Need a common assembly	Half the devs, Lisa [a product manager]	Just need time to do it
Add unit tests - Phase 1	Just let devs optionally write tests	Medium - tools are free	Huge	Get test harness (like NUnit)	Devs	Culture doesn't support it, so tests not maintained
Add unit tests - Phase 2	Make  required, part of the build	Big	Enforces unit tests	CI Build, code coverage tool, manager support	Everyone	Lots of people don't like UT, "it takes too much time"

 Lastly, as we discuss which initiatives to push, don't use any of these techniques - they will fail miserably:

• Try to change everything at once.
• Push for a change that no-one sees the benefit of (You'll just be branded as that "annoying guy who doesn't get it").
• Don't have your own list, even a mental one. (Merely saying things are "bad" won't fix anything. You'll need concrete examples of what to change.)
• Wait for your manager to give you a list and make it perfect. (Your manager is busy, and they're probably focusing on higher-level problems. They need you to pro-actively tell them the problems you're facing - and your proposed solution.)

NEXT:  Part 5