A final comment on compensation, this one related to options. (Then, like the bonus cycle, we'll be done with this subject... until next year. That's the way the financial industry works -- for now.)
Google gets a lot of press about how great it is to work there and how people are lined up for interviews, like the lines for American Idol auditions. Stories about their 20% free time policy, creative culture, self-organization methods, and of course free food sound very appealing. I admire them for their innovative products and efforts to balance business with "not doing evil". And yes, some of my best friends are Googlers.
Recently, Google decided to reprice options that it had given out to employees. Due to the stock market cliff-dive, the options became worthless.
This reminded me of another tech company that was once considered the greatest in the world, hiring only the smartest of the smartest people. They minted many millionaires through stock options. People dreamed about working there.
The company? Microsoft, which many would say epitomizes everything that Google is against. It wasn't that long ago that Microsoft was the beautiful company.
Which led me to wonder: is the warm glow coming from Google really just a function of their (previously) red-hot stock price? Will Google be perceived as just another company now that the options payoff has disappeared, and their pay matches most other companies (i.e., now that even their masseuse can't become a millionaire).
Obviously, this is a simplistic view. Google represents the cloud revolution against the desktop, just as Microsoft represented the desktop revolution against big hardware. That's also important.
But what I'm interested in is whether Google is actually a fundamentally different type of company, or they just have a good business at the present time. I think if you asked Google management which they would rather have, they'd choose the former. (Of course, everyone would want both.)
The typical justification for options is to align both the long-term benefits of the employee and the employer, via the stock price of the company. At the point that the company reprices options, the options are no longer acting as an alignment tool, though. The employee benefited despite how the company fared. The company's options program is exposed as just a form of deferred compensation.
There's nothing inherently wrong with that. Any manager would be foolish not to exploit a cheap way to fund super salaries for great people, as long as the shareholders don't mind.
Going forward, it will be interesting to see whether Google's creative organization continues to be heralded as their secret weapon, or whether their exalted image will follow their stock price.
Thursday, February 26, 2009
Wednesday, February 25, 2009
Seth's blog
Seth Godin doesn't talk at all about software development in his blog, so I was surprised it at #3 on Jurgen Appelo's list of top 100 blogs for dev managers. Presumably most of those hits are coming from marketers, not software managers.
Yet, his is one of the first blogs I read everyday, and much of what he says directly relates to having a software career based on excellence and demonstrating importance through daily effort. As he marks his 3,000th blog post, he comments:
Here's a fairly recent post -- a typical example of why I read him. It's aimed at marketers, but highly relevant to anyone building their IT career.
In IT, it's easy to get obsessed about content. Our resumes overflow with acronyms and languages, versions 3.7 through 8.13. As we work longer, we might pick up some knowledge about the industry we're in, such as financial services, so that goes in the resume too. It's all stuff we "know".
Meanwhile, what's really valuable is the process. Capturing that in your resume or identifying which job applicants understand the process is the challenge and the goal. How do you identify what is important to your user? How do you effectively test your code?
Practices such as Agile help draw focus to the process, but sometimes that just turns into another list of domain knowledge. What's a product backlog? How many weeks do your sprints last? This is all content.
The more important questions lie underneath these details. What's the purpose of a product backlog? Name some other ways to do the same thing, and why are they better or worse? That's process.
I highly recommend Seth's blog for anyone interested in thinking about how to do their job excellently.
Yet, his is one of the first blogs I read everyday, and much of what he says directly relates to having a software career based on excellence and demonstrating importance through daily effort. As he marks his 3,000th blog post, he comments:
The hard part, as you can guess, is the first 2,500 posts. After that, momentum really starts to build.He started back in 2002, so that works out to aboue 415 posts a year. Yup, he's definitely a guy who believes in daily effort.
Here's a fairly recent post -- a typical example of why I read him. It's aimed at marketers, but highly relevant to anyone building their IT career.
As you consider marketing yourself for your next gig, consider the difference between process and content.... As the world changes ever faster, as industries shrink and others grow, process ability is priceless. Figure out which sort of process you're world-class at and get even better at it. Then, learn the domain...
In IT, it's easy to get obsessed about content. Our resumes overflow with acronyms and languages, versions 3.7 through 8.13. As we work longer, we might pick up some knowledge about the industry we're in, such as financial services, so that goes in the resume too. It's all stuff we "know".
Meanwhile, what's really valuable is the process. Capturing that in your resume or identifying which job applicants understand the process is the challenge and the goal. How do you identify what is important to your user? How do you effectively test your code?
Practices such as Agile help draw focus to the process, but sometimes that just turns into another list of domain knowledge. What's a product backlog? How many weeks do your sprints last? This is all content.
The more important questions lie underneath these details. What's the purpose of a product backlog? Name some other ways to do the same thing, and why are they better or worse? That's process.
I highly recommend Seth's blog for anyone interested in thinking about how to do their job excellently.
Tuesday, February 24, 2009
There's no f in bonus
Bonus season winds down here in the financial industry, and we're left to consider what it all means. The bonus pool is particularly sensitive on Wall Street because financial firms rely on it excessively, outweighing regular pay for some employees. Many workers in the industry and in my company took a zero bonus.
What is the purpose of a bonus? Reward for individual productivity? Incentive to stay? Alignment of interests between employee and employer? Profit-sharing?
If your answer is all of the above, then I think there's no chance the bonus system at your company is working. It's just another form of compensation, so there's almost no reason to have it; just give a regular salary.
The general public is fuming about Wall Street firms' bonuses this year, in light of having their received taxpayer assistance. The public views these bonuses as a type of profit-sharing; thus, no profit, no sharing.
Individual employees view these as productivity rewards. Thus, the ones who worked very hard and had measurable positive results this year are upset about low or no bonuses.
Middle management typically views it as a key employee retention tool. Thus, even though Mary Developer didn't have the opportunity to produce like in previous years (maybe a couple of her projects were canceled), and Joe Programmer out-produced Mary this year, rarely would a manager consider switching their bonuses if Mary is viewed as the foundation of the group.
I would guess that senior management most commonly views these as a way to align employee and employer interests. Unfortunately, the payouts encourage the employee's short-term interests, which may be at odds with the company's long-term interests.
Underlying all these interpretations: a bonus that doesn't grow or, worse, shrinks feels like a punishment, even if the bonus is advertised as variable or tied to profits.
I think the biggest problem is that most companies haven't really thought specifically about what the bonus should accomplish. Thus, it tries to do all of the above by default, only because everyone interprets it however they want.
One of the most important decisions a company's executives makes is how people will get paid. If they want use bonus payments effectively, they need to be crystal clear about their purpose, and drive that down through the company.
On Wall Street, they would likely have revamped the entire bonus structure, probably eliminated it. Unfortunately, the issue has now spun out of control, and the revamping will be imposed.
What is the purpose of a bonus? Reward for individual productivity? Incentive to stay? Alignment of interests between employee and employer? Profit-sharing?
If your answer is all of the above, then I think there's no chance the bonus system at your company is working. It's just another form of compensation, so there's almost no reason to have it; just give a regular salary.
The general public is fuming about Wall Street firms' bonuses this year, in light of having their received taxpayer assistance. The public views these bonuses as a type of profit-sharing; thus, no profit, no sharing.
Individual employees view these as productivity rewards. Thus, the ones who worked very hard and had measurable positive results this year are upset about low or no bonuses.
Middle management typically views it as a key employee retention tool. Thus, even though Mary Developer didn't have the opportunity to produce like in previous years (maybe a couple of her projects were canceled), and Joe Programmer out-produced Mary this year, rarely would a manager consider switching their bonuses if Mary is viewed as the foundation of the group.
I would guess that senior management most commonly views these as a way to align employee and employer interests. Unfortunately, the payouts encourage the employee's short-term interests, which may be at odds with the company's long-term interests.
Underlying all these interpretations: a bonus that doesn't grow or, worse, shrinks feels like a punishment, even if the bonus is advertised as variable or tied to profits.
I think the biggest problem is that most companies haven't really thought specifically about what the bonus should accomplish. Thus, it tries to do all of the above by default, only because everyone interprets it however they want.
One of the most important decisions a company's executives makes is how people will get paid. If they want use bonus payments effectively, they need to be crystal clear about their purpose, and drive that down through the company.
On Wall Street, they would likely have revamped the entire bonus structure, probably eliminated it. Unfortunately, the issue has now spun out of control, and the revamping will be imposed.
Monday, February 23, 2009
The end of H-1B?
Thomas Friedman notes:
the U.S. Senate unfortunately voted on Feb. 6 to restrict banks and other financial institutions that receive taxpayer bailout money from hiring high-skilled immigrants on temporary work permits known as H-1B visas.
Not only will "buy American" sentiment continue to grow, but the original purpose of the H-1B program -- to fill the shortfall in technology workers -- begins to look silly as the numbers of laid-off tech workers increase. I personally know several good technologists searching for work. If this downturn continues for any amount of time -- and it appears that it will -- then that shortfall will surely disappear.
At the same time, like everyone else in the industry, I have worked with plenty of H-1Bs, and have become good friends with many of them, so I wouldn't be in favor of shipping people out.
Ironically, it's probably in the best interest of countries who send their H-1B workers to the U.S. to keep them at home. But, what's good for the team (country) in the long-term may not be what's good for the individual in the short-term.
Currently, the U.S. acts like the New York Yankees of the world. The Yankees hire the most expensive and best players, tilting the odds of a championship in their favor. Smaller teams constantly have to re-tool with young, unproven players. Similarly, the best and brightest come here for better pay and working conditions, tilting the odds in favor of exciting new innovations being created in the U.S. They help start new enterprises that make their solutions available first to U.S. companes. Their countries of origin have to constantly train new talent to stock their own companies.
In general, I am in favor of more immigration. Economies with greater immigration prove to be stronger than those with less. Japan has suffered economically since the 90s in large part because of a lack of immigration, combined with a very low reproduction rate.
I'm not sure that targeting immigration to a specific category of worker is the best way to go about it, but it may be the only way to achieve the desire ends politically.
Thus, let me say: long live the H-1B!
Remind me I said this if I get laid off. But, you have to believe in your own value, that quality wins out in the end. As a result, I have confidence my friends, currently out of work, will find something soon, being smart and highly capable guys.
Difficult times put your beliefs to the test. That's when you find out what you truly believe.
Thursday, February 19, 2009
Path to excellence
How can you excel in your job? Go deep and go wide (but not at the same time).
Going deep means becoming an expert. This can simply be a manifestation of doing something very well: learning about what you're doing, instead of just trying to get it off your plate as fast as possible.
One person who worked for me coded up some trade feeds for regulatory purposes. As she went along, she spent the time to learn a lot of fine-grained details about the regulations and what that meant for our system. Eventually, every meeting involving coding changes (because the regulations regularly change or have exceptions) required her presence.
Another guy wrote a feed to send some data to a central database for management reporting. The feed required some calculation pre-processing, but otherwise, it was pretty straightforward. In doing his work, he came to fully understand the nuances of the calculation on our side and how any changes would affect the aggregation. Eventually, he learned so much about this overall business process that he stopped working for me and started working for the business side.
By going deep, you become the go-to person on a subject. You can go deep on a technical language or a complex application module. You become the state of the art for that art. You demonstrate high competence in a public, understood way.
Going wide means picking up new skills or knowledge. The key to going wide is that the value is unlocked only when you combine the new with the old.
My friends who worked on the trade and data feeds combined their programming skills with a business process they previously knew nothing about. They did an excellent job of combining the two.
What you can't do is learn something totally unrelated to what you are doing now. Eventually, this could pay off for you, but it could be a long wait, and it won't help you excel today. You are a newbie in the new field; your only advantage is your accumulated unique experience that you bring with you.
Here's a fascinating example of a guy who repeatedly goes deep, then jumps to something new but related, then goes deep in that. He started with industrial engineering, becomes an expert in gun manufacturing ("I probably know as much, or more, as any one single person about manufacturing guns," he claims, credibly), moves into robotics. Then,
Going deep means becoming an expert. This can simply be a manifestation of doing something very well: learning about what you're doing, instead of just trying to get it off your plate as fast as possible.
One person who worked for me coded up some trade feeds for regulatory purposes. As she went along, she spent the time to learn a lot of fine-grained details about the regulations and what that meant for our system. Eventually, every meeting involving coding changes (because the regulations regularly change or have exceptions) required her presence.
Another guy wrote a feed to send some data to a central database for management reporting. The feed required some calculation pre-processing, but otherwise, it was pretty straightforward. In doing his work, he came to fully understand the nuances of the calculation on our side and how any changes would affect the aggregation. Eventually, he learned so much about this overall business process that he stopped working for me and started working for the business side.
By going deep, you become the go-to person on a subject. You can go deep on a technical language or a complex application module. You become the state of the art for that art. You demonstrate high competence in a public, understood way.
Going wide means picking up new skills or knowledge. The key to going wide is that the value is unlocked only when you combine the new with the old.
My friends who worked on the trade and data feeds combined their programming skills with a business process they previously knew nothing about. They did an excellent job of combining the two.
What you can't do is learn something totally unrelated to what you are doing now. Eventually, this could pay off for you, but it could be a long wait, and it won't help you excel today. You are a newbie in the new field; your only advantage is your accumulated unique experience that you bring with you.
Here's a fascinating example of a guy who repeatedly goes deep, then jumps to something new but related, then goes deep in that. He started with industrial engineering, becomes an expert in gun manufacturing ("I probably know as much, or more, as any one single person about manufacturing guns," he claims, credibly), moves into robotics. Then,
A few months ago, Baber decided to design his own mini-helicopter, one light enough to disassemble and carry in a backpack. After a successful test flight in January, he is currently busy building [modifications].
Yes, these are all related fields for him. This example shows that, if you truly master this process, you actually create your own "industry". Here's the summary (and the full article, requires free registration).
Wednesday, February 18, 2009
What's in your box score?
I'm not a big fan of the NBA, but an article about NBA player Shane Battier is loaded with insights about teams.
An old adage claims that you can't manage what you don't measure. Seems true enough. Is the quality of your software improving? Much easier to say if you have some statistics on number of bugs, severity, etc.
But are you measuring the right things?
It's only recently that the NBA started to figure out how to measure the value of team play. At "regular" companies, the use of 360 reviews attempts to get at something similar. Feedback loops from multiple sources on multiple aspects of a person's job can also be used.
Does your team / manager / company -- do you -- encourage behavior that makes the team stronger? Or are you breeding players just padding their own stats?
The article goes into a lot of other equally relevant and interesting subjects. Read the whole thing.
It was, and is, far easier to spot what Battier doesn’t do than what he does. His conventional statistics are unremarkable: he doesn’t score many points, snag many rebounds, block many shots, steal many balls or dish out many assists... "He can’t dribble, he’s slow and hasn’t got much body control."Weak stats on both offense and defense, yet teams he plays for become winners.
Battier’s game is a weird combination of obvious weaknesses and nearly invisible strengths.... When he is on the court, his teammates get better, often a lot better, and his opponents get worse — often a lot worse. He may not grab huge numbers of rebounds, but he has an uncanny ability to improve his teammates’ rebounding.... At the same time he somehow improves the defensive efficiency of his teammates — probably, Morey surmises, by helping them out in all sorts of subtle ways. "I call him Lego," Morey says. "When he’s on the court, all the pieces start to fit together."
An old adage claims that you can't manage what you don't measure. Seems true enough. Is the quality of your software improving? Much easier to say if you have some statistics on number of bugs, severity, etc.
But are you measuring the right things?
For most of its history basketball has measured not so much what is important as what is easy to measure — points, rebounds, assists, steals, blocked shots — and these measurements have warped perceptions of the game. ("Someone created the box score," Morey says, "and he should be shot.")The ongoing financial meltdown contains numerous, unfortunate examples of what happens when the wrong behaviors are rewarded based on measuring the wrong things. For one, bankers bonuses were tied to the size of their deals, regardless of quality and risk.
It's only recently that the NBA started to figure out how to measure the value of team play. At "regular" companies, the use of 360 reviews attempts to get at something similar. Feedback loops from multiple sources on multiple aspects of a person's job can also be used.
Does your team / manager / company -- do you -- encourage behavior that makes the team stronger? Or are you breeding players just padding their own stats?
The article goes into a lot of other equally relevant and interesting subjects. Read the whole thing.
Tuesday, February 17, 2009
Promotions
Annual promotions were announced recently at my company.
Occasionally, someone works for me who actively disdains getting promoted. "Not my objective," is what they say. I applaud the attitude, but I do sometimes wonder about the underlying assumptions.
While it is accurate to say that it is not a primary objective, it should be an objective because getting feedback should be an objective. A promotion is one of the biggest feedback mechanisms. I'm a big fan of receiving feedback.
I think these employees feel the promotion process is corrupt and inaccurate, and therefore not an accurate reflection of what they do. Another version of this complaint: "only those who are trying to get promoted actually do," the implication being that more kissing up to the boss is required. Surely that happens in some cases, but the vast majority of promotions that I participated in or had detailed information on were openly debated and resulted in the right people being chosen.
But, even if you accept the premise -- that the promotion process is useless as a feedback mechanism -- asking, "What are the specific things I would have to accomplish to be promoted?" is a very good way of finding out how to succeed. This creates a conversation about what is considered excellent work and what isn't.
At the end of the year, if you didn't get promoted, but you hit all the achievements, you'll know you did a great job, which is the primary objective. Then again, maybe you will get promoted, and you might find you like it.
Occasionally, someone works for me who actively disdains getting promoted. "Not my objective," is what they say. I applaud the attitude, but I do sometimes wonder about the underlying assumptions.
While it is accurate to say that it is not a primary objective, it should be an objective because getting feedback should be an objective. A promotion is one of the biggest feedback mechanisms. I'm a big fan of receiving feedback.
I think these employees feel the promotion process is corrupt and inaccurate, and therefore not an accurate reflection of what they do. Another version of this complaint: "only those who are trying to get promoted actually do," the implication being that more kissing up to the boss is required. Surely that happens in some cases, but the vast majority of promotions that I participated in or had detailed information on were openly debated and resulted in the right people being chosen.
But, even if you accept the premise -- that the promotion process is useless as a feedback mechanism -- asking, "What are the specific things I would have to accomplish to be promoted?" is a very good way of finding out how to succeed. This creates a conversation about what is considered excellent work and what isn't.
At the end of the year, if you didn't get promoted, but you hit all the achievements, you'll know you did a great job, which is the primary objective. Then again, maybe you will get promoted, and you might find you like it.
Saturday, February 14, 2009
Valentine's Day
Valentine's Day is a corporate holiday manufactured to boost sales during a slow time. It's a totally transparent marketing manipulation scheme catered to women.
That doesn't prevent millions of women from loving it all the same. After all, everyone likes to be appreciated.
When do you take time to tell your team how much you appreciate them? This is a serious matter, and something that doesn't happen enough. Studies show positive reinforcement is more effective and longer-lasting than negative.
The annual review doesn't count, though it should happen there as well. (Positive comments should outnumber the negative ones.)
Maybe you're thinking, "We have an event just for this already: our annual holiday party." But, that's a gift of the company, not from you, and if your company parties are anything like mine, what typically happens is people use the party to interact and bond with people outside their group. That's actually a great use of the party, and it also means you should have something separate.
How about an annual appreciation lunch with each team member? Or a party that is planned ahead and advertised specifically as a "team appreciation party"?
Sound contrived? Surely it is, but that won't stop your team from liking it and feeling appreciated all the same.
(Just don't do it on Valentine's Day.)
That doesn't prevent millions of women from loving it all the same. After all, everyone likes to be appreciated.
When do you take time to tell your team how much you appreciate them? This is a serious matter, and something that doesn't happen enough. Studies show positive reinforcement is more effective and longer-lasting than negative.
The annual review doesn't count, though it should happen there as well. (Positive comments should outnumber the negative ones.)
Maybe you're thinking, "We have an event just for this already: our annual holiday party." But, that's a gift of the company, not from you, and if your company parties are anything like mine, what typically happens is people use the party to interact and bond with people outside their group. That's actually a great use of the party, and it also means you should have something separate.
How about an annual appreciation lunch with each team member? Or a party that is planned ahead and advertised specifically as a "team appreciation party"?
Sound contrived? Surely it is, but that won't stop your team from liking it and feeling appreciated all the same.
(Just don't do it on Valentine's Day.)
Friday, February 13, 2009
New rules: no more rules
This escalator sign doesn't really make sense. But at least they have the excuse of English not being their native language. Presumably, the Chinese makes perfect sense.On the subway I take, they have no such excuse.
The tunnel where I get out is very deep. A very long escalator takes you from the subway to the top, where the ticket booth and street exits are. The escalator only goes up; to go down, you have to take the stairs or the elevator. Once you arrive at the top of the escalator, an LED sign greets you with this message:
"Escalator is for subway patrons only."*
What? Only people coming from the subway are on the escalator. The only way to be in violation would be to buy a subway ticket at this station, walk down the stairs, and then take the escalator back up. Just for fun. Even then, you paid for a ticket, so shouldn't you be allowed a free escalator ride?
Why is this sign there? The only reason I can think of is that, in the design stage, someone put in this "feature" thinking abstractly that it could be of benefit. Later, when it came time to actually use the sign, the only thing anyone could think of was mindless manager-ese -- something they read somewhere else.
"Restrooms are for customers only" on a restroom at the back of the store is another example. Whoever posted that sign probably saw a similar sign somewhere else, but failed to note that they probably saw it at the front door.
In software development, we should be following principles and practices, not rules. Principles are almost philosophical; it's what you believe.
Practices are not rules. Practices derive from principles. This is where confusion creeps in. Is "Make your classes final, do not allow extensions" a rule or a practice? How about "All classes should have a unit test"?
The key is whether you're being motivated by principle. If you understand the principle, and that's why you're following the rule, you're really following a practice. If you don't understand the principle, or you're following the practice regardless of it, you're actually following a rule.
I see now that Robert Martin also has a related post yesterday, specifically about SOLID principles. Scott Bain also has an good write-up on this in Emergent Design.
* I would take a picture, but that is verboten in this high security era.
Thursday, February 12, 2009
Testing smackdown, part 4
Not to keep cross-posting Jeff Atwood (a sign of respect, anyway), but he responds to Robert Martin's criticisms directly.
Note that Jeff's argument here is not the same one I was making before about why TDD or another development principles might be pushed aside sometimes (basically: real-world constraints get in the way).
In fact, even though Jeff and I seem to reach the same conclusion, I disagree with Jeff here. This might not be his only reason for discounting the importance of TDD, but at least this particular argument seems weak.
I'm not sure you could follow Robert's principles "mindlessly", so I don't see any problem with putting them out as design goals.
Several years ago, when I started coded heavily in Java, I read that you should only code to interfaces. It also said that behavior used by multiple implementations should be kept in abstract classes; in anticipation of that, it recommended extending abstract classes as a rule, so that specific behavior could be easily moved up if you wanted to generalize. And, actually, those rules make a lot of sense to me.
So, on my next assignment, I did exactly that. Every single class extended an abstract class. Every instantiation was to an interface. To some degree, mindlessly.
But, to some degree, thinking was always required. Do I need this method in the interface? Which part of the behavior goes in the abstract class and which in the implementation?
The real downside was the massive number of files. More files had to be maintained. Creating a class took more time, because I had to create 3 files every time I wanted one. Once that was done, however, the burden wasn't too great, and I did see some benefits later when I went back for modifications and extensions.
On subsequent projects, I created interfaces and abstract classes more selectively. This is closer to the agile idea of limiting complexity to what you know you will need.
With this practice, or pick a principle, say the Single Responsibility Principle, it's much easier to ignore it and just plow forward with the code.
I haven't yet run into a case where someone was absurdly over-applying solid development principles or practices; the incentives run the other way.
At what point do you stop having a set of basic, reasonable programmingThis has expanded beyond testing and into development principles, but TDD is still a good straw man for the conflict.
guidelines -- and start being a Ferengi programmer, an imperfect manifestation
of the ruleset?
Note that Jeff's argument here is not the same one I was making before about why TDD or another development principles might be pushed aside sometimes (basically: real-world constraints get in the way).
In fact, even though Jeff and I seem to reach the same conclusion, I disagree with Jeff here. This might not be his only reason for discounting the importance of TDD, but at least this particular argument seems weak.
I'm not sure you could follow Robert's principles "mindlessly", so I don't see any problem with putting them out as design goals.
Several years ago, when I started coded heavily in Java, I read that you should only code to interfaces. It also said that behavior used by multiple implementations should be kept in abstract classes; in anticipation of that, it recommended extending abstract classes as a rule, so that specific behavior could be easily moved up if you wanted to generalize. And, actually, those rules make a lot of sense to me.
So, on my next assignment, I did exactly that. Every single class extended an abstract class. Every instantiation was to an interface. To some degree, mindlessly.
But, to some degree, thinking was always required. Do I need this method in the interface? Which part of the behavior goes in the abstract class and which in the implementation?
The real downside was the massive number of files. More files had to be maintained. Creating a class took more time, because I had to create 3 files every time I wanted one. Once that was done, however, the burden wasn't too great, and I did see some benefits later when I went back for modifications and extensions.
On subsequent projects, I created interfaces and abstract classes more selectively. This is closer to the agile idea of limiting complexity to what you know you will need.
With this practice, or pick a principle, say the Single Responsibility Principle, it's much easier to ignore it and just plow forward with the code.
I haven't yet run into a case where someone was absurdly over-applying solid development principles or practices; the incentives run the other way.
Wednesday, February 11, 2009
Coding epistemology
Jeff Atwood has a nice post about knowledge -- specifically, one way to learn something well.
I consider there to be the three levels of knowledge. They reflect my belief that knowledge needs to be shared to get the most value out of it.
1. knowledge you know. You read something, someone tells you, or you do it yourself, to the point where now you know it. But how do you know you know it?
2. knowledge you can explain to someone else. This requires you to organize the information. Many times, in the actual moment of explaining, you will suddenly realize a gap in your knowledge or a fallacy in your logic. I think this is akin to getting a call from your mom that she's coming over, and realizing only at that moment that your apartment is a mess; you're viewing yourself through someone else's eyes. And yes, the act has to involve explaining and a someone else, not just a mental exercise where you convince yourself that it could be done.
3. knowledge you can answer questions with. People react to your explanations in unpredictable ways; weird questions pop out. They try to apply it to things you'd never think of on your own, just as end users do things with your application that you'd never considered. These questions test the robustness and flexibility of your knowledge -- or, said another way, they test whether your understanding is at the implementation or the abstraction level.
You are more likely to succeed at numbers 2 and 3 if, as in Jeff's example, you wrote something yourself from scratch, as opposed to someone just explaining it to you once. Someone explains something to us, we can walk away with a false sense of security in our knowledge, which easily crumbles in the face of simple questions.
Implicit in number 3 is the possibility that someone's question may blow up your knowledge, perhaps due to false or missing assumptions.
For these reasons, I like to have a "training" on any major new functionality, either as a group, or one-to-one. To verify that the trainee (which could be me) is truly walking away with knowledge, that person will later have to explain it to the next person. And take questions.
I consider there to be the three levels of knowledge. They reflect my belief that knowledge needs to be shared to get the most value out of it.
1. knowledge you know. You read something, someone tells you, or you do it yourself, to the point where now you know it. But how do you know you know it?
2. knowledge you can explain to someone else. This requires you to organize the information. Many times, in the actual moment of explaining, you will suddenly realize a gap in your knowledge or a fallacy in your logic. I think this is akin to getting a call from your mom that she's coming over, and realizing only at that moment that your apartment is a mess; you're viewing yourself through someone else's eyes. And yes, the act has to involve explaining and a someone else, not just a mental exercise where you convince yourself that it could be done.
3. knowledge you can answer questions with. People react to your explanations in unpredictable ways; weird questions pop out. They try to apply it to things you'd never think of on your own, just as end users do things with your application that you'd never considered. These questions test the robustness and flexibility of your knowledge -- or, said another way, they test whether your understanding is at the implementation or the abstraction level.
You are more likely to succeed at numbers 2 and 3 if, as in Jeff's example, you wrote something yourself from scratch, as opposed to someone just explaining it to you once. Someone explains something to us, we can walk away with a false sense of security in our knowledge, which easily crumbles in the face of simple questions.
Implicit in number 3 is the possibility that someone's question may blow up your knowledge, perhaps due to false or missing assumptions.
For these reasons, I like to have a "training" on any major new functionality, either as a group, or one-to-one. To verify that the trainee (which could be me) is truly walking away with knowledge, that person will later have to explain it to the next person. And take questions.
Tuesday, February 10, 2009
Good person, wrong role?
A friend of mine recently lamented to me about the difficulties of hiring. "These guys come with beautiful resumes and rock solid recommendations, and then they come and are so disappointing." I'm sure anyone involved in hiring knows exactly what my friend is talking about.
To some degree, just chalk it up to the intrinstic difficulties of hiring. Even legendarily thorough and expensive processes employed at places like Google and Goldman, Sachs let in a fair share of low performers.
However, a book I read lately brought another cause to mind. David Sedaris's Holidays on Ice is, like all of his books, a collection of funny short stories. The stories are always personal vignettes involving his family or some trip he took. His new books always get to the top levels of the sales charts. I have read several, and they never fail to make me laugh.
Holidays on Ice is unique in that it also contains a few purely fictional stories.
His fictional stories stunk. I can't think of any real clunkers from among the dozens of his personal stories spanning multiple books, but I found every one of the fiction stories to be unamusing and uninteresting.
If you were evaluating his writing, and happened to read only his fiction, you'd walk away thinking, "Everyone talks so highly of this guy, but he can't write!"
I think this points to a simple truth: people can be hugely talented and accomplished, but it still requires getting them into the right role. The right role is not a title. The Vice-President role under John McCain would have been vastly different than it will be under Barack Obama. Same title, different role.
Getting someone into the right role can be very difficult. Sometimes there's a mismatch with the company culture. Some people are highly accomplished but not good team players. Or, vice versa, they are solid team players, but that makes them ineffective on a team of stars. A personal narrative writer assigned to fiction.
A good manager should be evaluating and searching for the right roles and responsibilities for each team member. This is the first step in empowering and motivating your employees. It is also never-ending. If that sounds like a lot of work, it is, which is why a rigorous hiring process can pay for itself.
But hiring will only get you so far, and then it's time to manage.
To some degree, just chalk it up to the intrinstic difficulties of hiring. Even legendarily thorough and expensive processes employed at places like Google and Goldman, Sachs let in a fair share of low performers.
However, a book I read lately brought another cause to mind. David Sedaris's Holidays on Ice is, like all of his books, a collection of funny short stories. The stories are always personal vignettes involving his family or some trip he took. His new books always get to the top levels of the sales charts. I have read several, and they never fail to make me laugh.
Holidays on Ice is unique in that it also contains a few purely fictional stories.
His fictional stories stunk. I can't think of any real clunkers from among the dozens of his personal stories spanning multiple books, but I found every one of the fiction stories to be unamusing and uninteresting.
If you were evaluating his writing, and happened to read only his fiction, you'd walk away thinking, "Everyone talks so highly of this guy, but he can't write!"
I think this points to a simple truth: people can be hugely talented and accomplished, but it still requires getting them into the right role. The right role is not a title. The Vice-President role under John McCain would have been vastly different than it will be under Barack Obama. Same title, different role.
Getting someone into the right role can be very difficult. Sometimes there's a mismatch with the company culture. Some people are highly accomplished but not good team players. Or, vice versa, they are solid team players, but that makes them ineffective on a team of stars. A personal narrative writer assigned to fiction.
A good manager should be evaluating and searching for the right roles and responsibilities for each team member. This is the first step in empowering and motivating your employees. It is also never-ending. If that sounds like a lot of work, it is, which is why a rigorous hiring process can pay for itself.
But hiring will only get you so far, and then it's time to manage.
Monday, February 9, 2009
Software trade-offs: strategy under fire
You built a great product. Your software is the dominant player in the market. Yay!
New competitors appear with new features. Those features target your specific strategy, exploiting it to expose a weakness. Or, "misuse" of your service also exposes a weakness of your strategy. How do you respond?
Keep in mind that the strategy is or at least has been critical to your success. Any changes could compromise the value of your software.
Lew Moorman sees Twitter theatening Google. (Via Robert Scoble.)
Meanwhile, the lack of human contact on Facebook has made it difficult to recover from scams.
New competitors appear with new features. Those features target your specific strategy, exploiting it to expose a weakness. Or, "misuse" of your service also exposes a weakness of your strategy. How do you respond?
Keep in mind that the strategy is or at least has been critical to your success. Any changes could compromise the value of your software.
Lew Moorman sees Twitter theatening Google. (Via Robert Scoble.)
Twitter is building a human powered search indexing engine. It is an engine that will build better results than any rules based index and has gotten millions of people super motivated to contribute for free every day (even though they don’t know it).Robert also points out that Twitter and other real-time interactive sites will provide better late-breaking searches.
Meanwhile, the lack of human contact on Facebook has made it difficult to recover from scams.
Facebook confirmed Rutberg's identity theft story and says it's beefing up security in reaction to the new scam. But Rutberg isn't sure how effective the social networking company has been. His main complaint: There is no way to call the firm and sound the alarm that a crime is in progress. The company confirms it doesn’t accept phone calls.
I think Facebook's problem is the easiest to resolve: put a "I am the owner of this account, and it has been taken over" link on the site, which immediately gives you access to a live person. This phone number would also be used for people who have been locked out of their accounts illegitimately. Yes, it would cost some money, but that would be managed by limiting the calls to only identity issues: those who accounts have been blocked by hackers or Facebook.
Google can hope that greater "stickiness" among their various tools -- gmail, reader, etc. -- leads to a greater percentage of people logging in, which in turn makes it easier to track specific user's behavior and who's reading whom. This will allow them to generate searches based on personal networks. Longer term, I think some amount of loss to niche searching is inevitable. This actually creates a healthier online infrastructure for us, as users.
The key for Google is whether an exploitation could turn fatal (as Google's was for Yahoo and Excite, etc.). So far, I would say this one is not.
Saturday, February 7, 2009
Testing smackdown, part 3
Robert Martin further responds to Joel Spolsky and Jeff Atwood:
If people are misquoting or misinterpreting you, by all means, take them out back behind the shed. Perhaps they have been irresponsible. Perhaps these are wide-spread inaccuracies, and this is a chance to set the record straight. That's what Robert's trying to do.
On the other hand, perhaps real problems emerge with the methodology in some circumstances.
It's all out in public, so everyone can understand the nuances of each argument and make their own conclusions.
Think if George Washington were blogging to correct Supreme Court justices trying to interpret the "founding fathers' original intent". Or John Maynard Keynes were here to set the economists straight about what to do with our current financial mess. (The economic blogging battles going on make this software discussion seem very polite by comparison.)
Hopefully we'll get more details from all sides about both interpretation and implementation problems around test-driven development, SOLID, Agile, and other principles.
If you had read through any of the articles and/or books I’ve written on these principles over the last 15 years, you’d have found that I don’t recommend the religious or dogmatic approach you blamed me for.I'm following this confrontation because I think it represents one of the primary benefits of our current age. The two parties aren't just blowing hot air: one is one of the greatest software architects living, and the other two are extremely successful professionals with large numbers of followers.
If people are misquoting or misinterpreting you, by all means, take them out back behind the shed. Perhaps they have been irresponsible. Perhaps these are wide-spread inaccuracies, and this is a chance to set the record straight. That's what Robert's trying to do.
On the other hand, perhaps real problems emerge with the methodology in some circumstances.
It's all out in public, so everyone can understand the nuances of each argument and make their own conclusions.
Think if George Washington were blogging to correct Supreme Court justices trying to interpret the "founding fathers' original intent". Or John Maynard Keynes were here to set the economists straight about what to do with our current financial mess. (The economic blogging battles going on make this software discussion seem very polite by comparison.)
Hopefully we'll get more details from all sides about both interpretation and implementation problems around test-driven development, SOLID, Agile, and other principles.
Friday, February 6, 2009
Dilbert + agile
These are a bit old, but the Agile implementation at Dilbert's office is amusing.
Dilbert pairs up.
We need more programmers.
Thanks to Jose for the pointer.
Dilbert pairs up.
We need more programmers.
Thanks to Jose for the pointer.
Thursday, February 5, 2009
Even cost-cutting measures are now too expensive
BusinessWeek reports:
I disfavor any work arrangement where half the team is located somewhere else, unless a clear division of responsibility can be identified (in which case, you really have two teams). Great camaraderie helps you form a great team. "Negotiations" -- meaning, any agreement that has to be reached between 2 or more parties -- done in person have twice as much success than those done over the phone, and four times greater than email. (They haven't studied twittering yet...)
Outsourcing adds the additional problem of agency, where the development team's incentive is to benefit the outsourcing company, not the client. Yes, the two often overlap, but not always. Similar problems can occur when a big company makes its IT team a silo that reports to no specific business unit. Developers should have frequent interaction with the client, whether internal or external.
Off-shoring adds additional layers of problems involving culture, language, and time difference.
The poster child for off-shore outsourcing is manufacturing, where you can hire assembly line workers at crazy low wages. Yet, recent studies show even that may be false savings.
Can't control quality in manufacturing -- think how much more difficult software is.
The economic slump has become so pronounced that even outsourcing is getting scaled back. Executives who once relied on outside firms to handle certain IT tasks to cut costs are now reining in some outsourcing plans on concern they're too expensive.The article is specifically talking about off-shoring.
I disfavor any work arrangement where half the team is located somewhere else, unless a clear division of responsibility can be identified (in which case, you really have two teams). Great camaraderie helps you form a great team. "Negotiations" -- meaning, any agreement that has to be reached between 2 or more parties -- done in person have twice as much success than those done over the phone, and four times greater than email. (They haven't studied twittering yet...)
Outsourcing adds the additional problem of agency, where the development team's incentive is to benefit the outsourcing company, not the client. Yes, the two often overlap, but not always. Similar problems can occur when a big company makes its IT team a silo that reports to no specific business unit. Developers should have frequent interaction with the client, whether internal or external.
Off-shoring adds additional layers of problems involving culture, language, and time difference.
The poster child for off-shore outsourcing is manufacturing, where you can hire assembly line workers at crazy low wages. Yet, recent studies show even that may be false savings.
Can't control quality in manufacturing -- think how much more difficult software is.
Wednesday, February 4, 2009
Reverse H1B?
There may be some good aspects of this program, but comes across very badly:
One good aspect is that it creatively solves a problem for both sides. These are people who have been laid off, after all.
Unfortunately, it smells very much like shipping jobs overseas, which, in a time of financial crisis, is not a good odor. The other problem: if it works well, it creates the incentive to use it to actually ship jobs overseas, even if that wasn't the original idea.
Thanks to Tyler Cowen for the pointer.
India, China, Brazil... sounds like IT development-type jobs. If they were business consulting jobs, I would think you'd have to speak the local language.The climate is warm, there's no shortage of exotic food, and the cost of living is rock bottom. That's IBM's pitch to the laid-off American workers it's offering to place in India. The catch: Wages in the country are pennies-on-the-dollar compared to U.S. salaries.
Under a program called Project Match, IBM will help workers laid off from domestic sites obtain travel and visa assistance for countries in which Big Blue has openings. Mostly that's developing markets like India, China, and Brazil.
One good aspect is that it creatively solves a problem for both sides. These are people who have been laid off, after all.
Unfortunately, it smells very much like shipping jobs overseas, which, in a time of financial crisis, is not a good odor. The other problem: if it works well, it creates the incentive to use it to actually ship jobs overseas, even if that wasn't the original idea.
Thanks to Tyler Cowen for the pointer.
Tuesday, February 3, 2009
Testing smackdown, part 2
Following up yesterday's post about the disagreement between Joel, Jeff, and Robert about testing and code quality, I was reminded about some code changes we had to make last year.
As I mention in my bio, I work at an investment bank. After the market closed one day, at 5 or 6 pm, we got a call from one of the business managers.
"We need to stop trading with Bear Stearns. Starting immediately, if Bear tries to buy something from us, reject the trade." This was back when everyone became seriously concerned that Bear Stearns would go out of business. (Eventually, JP Morgan bought them.)
None of us was even aware that the trading feed had a feature that allowed us to reject a trade based on the buyer, because no one on the development team had been around when the trade feed was written 8 years before. And Wall Street had never stopped trading with another major bank in our lifetimes.
With the clock ticking, we investigated how the feature worked. After a couple hours of talking to business people and developers at the exchange (where we send our trades), we figured out what fields to check, how to reject the trade, etc.
And then we hard-coded Bear Stearns into our trade feed. Hard-coded. Ran a couple unit tests ourselves, dropped it in for unit testing.
It was coming up on 9 pm, so the business manager ran a couple of very quick tests, gave us the thumbs up. Developers at the exchange confirmed our messages looked good. We pushed it out to prod.
That was fine, until a few weeks later, when Lehman started wobbling. "We need to stop trading with Lehman."
Again, we hard-coded it.
Does this make you cringe? In this case, I think what we did was exactly right.
Now, you might say that we got lucky. This was major business functionality, and it went in with maybe a half hour of testing all together. And you might also say that the fact that we had to go back and break the code open again later for Lehman shows the problem with our rushed implementation.
But, frankly, part of doing your job is knowing your code and understanding the risks you're taking. That's what Joel is talking about when he says he wants to step back from hard rules because he fears that people will stop thinking.
What risks did we take? The main thing we considered is, "What is the cost of hard-coding this vs the cost of doing something well-designed?" Knowing our code, we decided hard-coding would save a lot of time with not much downside. The main reason: you only have a small number of trading partners that you could remove from the feed before you'd end up not needing the feed anymore! Yes, we had to bust it open again for Lehman, but that was maybe another half hour, since this time we knew exactly where to put that code.
And, of course, as it turned out, we've never had to remove this code.
So, from a time perspective, we spent less than 2 hours coding this and never touched it again. It'd be impossible to get a better return on a richer, more robust implementation.
How about the testing? The two best testers are the business manager and the developers at the exchange -- they know the features and exactly how they want it to behave. Due to the time of day, every minute we delayed meant less likelihood we would have the these experts around, if not physically then mentally. So, I wanted to get the results into their hands as quickly as possible, even though that meant shorting our own testing.
What would have been completely unacceptable would be to say that we couldn't implement it in time, before start of trading the next day. And that's what Jeff's getting at when he says
As I mention in my bio, I work at an investment bank. After the market closed one day, at 5 or 6 pm, we got a call from one of the business managers.
"We need to stop trading with Bear Stearns. Starting immediately, if Bear tries to buy something from us, reject the trade." This was back when everyone became seriously concerned that Bear Stearns would go out of business. (Eventually, JP Morgan bought them.)
None of us was even aware that the trading feed had a feature that allowed us to reject a trade based on the buyer, because no one on the development team had been around when the trade feed was written 8 years before. And Wall Street had never stopped trading with another major bank in our lifetimes.
With the clock ticking, we investigated how the feature worked. After a couple hours of talking to business people and developers at the exchange (where we send our trades), we figured out what fields to check, how to reject the trade, etc.
And then we hard-coded Bear Stearns into our trade feed. Hard-coded. Ran a couple unit tests ourselves, dropped it in for unit testing.
It was coming up on 9 pm, so the business manager ran a couple of very quick tests, gave us the thumbs up. Developers at the exchange confirmed our messages looked good. We pushed it out to prod.
That was fine, until a few weeks later, when Lehman started wobbling. "We need to stop trading with Lehman."
Again, we hard-coded it.
Does this make you cringe? In this case, I think what we did was exactly right.
Now, you might say that we got lucky. This was major business functionality, and it went in with maybe a half hour of testing all together. And you might also say that the fact that we had to go back and break the code open again later for Lehman shows the problem with our rushed implementation.
But, frankly, part of doing your job is knowing your code and understanding the risks you're taking. That's what Joel is talking about when he says he wants to step back from hard rules because he fears that people will stop thinking.
What risks did we take? The main thing we considered is, "What is the cost of hard-coding this vs the cost of doing something well-designed?" Knowing our code, we decided hard-coding would save a lot of time with not much downside. The main reason: you only have a small number of trading partners that you could remove from the feed before you'd end up not needing the feed anymore! Yes, we had to bust it open again for Lehman, but that was maybe another half hour, since this time we knew exactly where to put that code.
And, of course, as it turned out, we've never had to remove this code.
So, from a time perspective, we spent less than 2 hours coding this and never touched it again. It'd be impossible to get a better return on a richer, more robust implementation.
How about the testing? The two best testers are the business manager and the developers at the exchange -- they know the features and exactly how they want it to behave. Due to the time of day, every minute we delayed meant less likelihood we would have the these experts around, if not physically then mentally. So, I wanted to get the results into their hands as quickly as possible, even though that meant shorting our own testing.
What would have been completely unacceptable would be to say that we couldn't implement it in time, before start of trading the next day. And that's what Jeff's getting at when he says
Because the unit of measure that really matters to me is, how quickly you can respond to real business needs with your code. And by that I mean, how well are you serving the people that are using your code. To me that's what it's all about.This is in the paragraph that leads up to the infamous quote. It's important to think about that when you consider his later remarks.
Monday, February 2, 2009
Testing smackdown, part 1
It's not often you see the heavyweights go straight at each other, so when they do, it's worth taking note -- not for the spectacle, but to try to understand how they could be so far apart on something fundamental.
Robert C. Martin is deeply troubled by something Joel Spolsky and Jeff Atwood said. Yes, the Robert that wrote one of the greatest dev books ever. Yes, the same Joel and Jeff that inhabit spots 1 and 3 in Jurgen Appelo's top 100 software dev blogs.
Here's the offending quote, as spoken by Jeff:
Joel may be aware of the controversy, because he promptly posted on his own blog part of the transcript from the podcast, which I don't recall him ever doing before. Read it and form your own opinion about the context of Jeff's comments.
I will have my own opinion about it tomorrow after you've had a chance to consider your own.
Robert C. Martin is deeply troubled by something Joel Spolsky and Jeff Atwood said. Yes, the Robert that wrote one of the greatest dev books ever. Yes, the same Joel and Jeff that inhabit spots 1 and 3 in Jurgen Appelo's top 100 software dev blogs.
Here's the offending quote, as spoken by Jeff:
I don't want to come out and say I'm against [unit] testing, because I'm really not. Anything that improves quality is good. But there's multiple axes you're working on here; quality is just one axis. And I find, sadly, to be completely honest with everybody listening, quality really doesn't matter that much, in the big scheme of things.Here's Robert's reaction:
I was riding my exercise bike, listening to Stack Overflow #38 when I heard Jeff Atwood and Joel Spolsky say “Quality just doesn’t matter that much.” I nearly fell off my bike.The condemnation would have been much harsher if "Uncle Bob" hadn't interpreted the offending comments generously.
I mean this is Joel Spolsky right? His buddy Jeff makes this incredibly dumb statement and Joel grunts his approval. WTF?
This is the kind of idiotic statement I would expect to hear from junior hackers, or people who haven’t written very much code.
Joel may be aware of the controversy, because he promptly posted on his own blog part of the transcript from the podcast, which I don't recall him ever doing before. Read it and form your own opinion about the context of Jeff's comments.
I will have my own opinion about it tomorrow after you've had a chance to consider your own.
Saturday, January 31, 2009
Career advice
Facing job uncertainty? What steps are the right ones for your career?
I will have more to say about these issues later, but today, I just want to put out a simple, guiding maxim. Because it is simple, you can use it as the bedrock for deciding what to do. All my career philosophies flow from this starting point.
Simply put: Be Excellent.
There is a shortage of excellence, and there will always be a shortage. Managers kill themselves trying to find excellent people. Whatever your job is, be one of those people.
Yes, there are additional things you can do to help your odds, but all things start with your personal excellence. This is far more than half the battle.
When evaluating two jobs, take the one that provides the best opportunity to be excellent.
Do you find yourself stuck in a job that isn't challenging enough? Do your work efficiently, and then use the rest of the day on side projects. Come up some ideas that interest you. Dedicate yourself to them. You are truly reporting to yourself, and only you will know whether you "met your deadlines". The purpose is to challenge yourself, push yourself. To use a metaphor, if your goal is to run a good marathon, you have to be training constantly.
Excellence rises to the top. I fundamentally believe that. Stop worrying about the minor details, and focus on excellence.
I will have more to say about these issues later, but today, I just want to put out a simple, guiding maxim. Because it is simple, you can use it as the bedrock for deciding what to do. All my career philosophies flow from this starting point.
Simply put: Be Excellent.
There is a shortage of excellence, and there will always be a shortage. Managers kill themselves trying to find excellent people. Whatever your job is, be one of those people.
Yes, there are additional things you can do to help your odds, but all things start with your personal excellence. This is far more than half the battle.
When evaluating two jobs, take the one that provides the best opportunity to be excellent.
Do you find yourself stuck in a job that isn't challenging enough? Do your work efficiently, and then use the rest of the day on side projects. Come up some ideas that interest you. Dedicate yourself to them. You are truly reporting to yourself, and only you will know whether you "met your deadlines". The purpose is to challenge yourself, push yourself. To use a metaphor, if your goal is to run a good marathon, you have to be training constantly.
Excellence rises to the top. I fundamentally believe that. Stop worrying about the minor details, and focus on excellence.
Friday, January 30, 2009
Dogfooding
Jeff Atwood discusses a particularly vivid example of "eating your own dogfood". In software development, this means using the software you make, thereby displaying confidence in your product.
While I am a big fan of the philosophy, this doesn't really work if the software you make is not for a mass market or for developers. My jobs over the past decade have been creating trading systems and international shipping tracking. Not much use for that on my own desktop.
However, in an earlier post, Jeff says
As managers, we sometimes get the idea, "Hey, I'm a manager now, I don't develop anymore." Or, as developers, we sometimes think, "Hey, I'm a developer, I don't do QA."
Yet, dipping one's toe in these other areas pays innumerable benefits. Some companies train their managers with a starting rotation on the front lines; I'm completely in favor of that.
In a previous job, I was put in charge of a fairly large group, where the programmers did both development and support. I took some shifts working the "hotline", taking calls from users.
Here are some of the specific benefits that came out:
This is not dogfooding in the traditional sense. However, being forced to live in the environment that surrounds you, that you contribute to -- developers taking a QA turn or going on a sales call, managers taking a developer turn or answering the hotline, etc. -- is the same philosophy applied differently.
Dogkenneling, perhaps?
While I am a big fan of the philosophy, this doesn't really work if the software you make is not for a mass market or for developers. My jobs over the past decade have been creating trading systems and international shipping tracking. Not much use for that on my own desktop.
However, in an earlier post, Jeff says
if you can't dogfood, consider working the help desk for a few days. I'm serious. There's nothing quite as effective as sharing the customer's pain.I can't agree more with Jeff's suggestion. Not only do you get a great view of what your customer is thinking, but you get a great view of what the team is thinking.
As managers, we sometimes get the idea, "Hey, I'm a manager now, I don't develop anymore." Or, as developers, we sometimes think, "Hey, I'm a developer, I don't do QA."
Yet, dipping one's toe in these other areas pays innumerable benefits. Some companies train their managers with a starting rotation on the front lines; I'm completely in favor of that.
In a previous job, I was put in charge of a fairly large group, where the programmers did both development and support. I took some shifts working the "hotline", taking calls from users.
Here are some of the specific benefits that came out:
- I got a deep understanding of the user's pain points (Jeff's point), which helped with decisions about priority.
- I talked to and developed relationships with a set of users I might not have otherwise me.
- I got a deep understanding of the cost of the user's problems, which helped with decisions about resource cost (for both fixing and not fixing).
- The technical and business skills and knowledge of each developer became apparent when trying to find the right people to help with a given problem.
- I combed through the code first-hand, getting a view of its quality and organization.
- I had to familiarize myself with the dev tools and processes.
- I received a first-hand view of how the team worked together.
- These activities were not viewed as "management prying" because they were part of an actual goal-oriented effort.
- Based on this knowledge, I devised a more efficient support and development schedule.
- Because the schedule was based on line experience, it naturally included many of the developers' own concerns, and not just a plan "dropped from the sky".
This is not dogfooding in the traditional sense. However, being forced to live in the environment that surrounds you, that you contribute to -- developers taking a QA turn or going on a sales call, managers taking a developer turn or answering the hotline, etc. -- is the same philosophy applied differently.
Dogkenneling, perhaps?
Thursday, January 29, 2009
Grass farming as software metaphor
Bruce Eckel writes that organic grass farmers show us something about software development.
What fascinates me about this is that it's the same old tools, applied differently. The farmer jokes about "being a grass farmer," but by seeing that everything hangs on growing the best grass that you can, I think he has cracked the code of farming.The point is that you can drive revolutionary ideas by focusing on the most important input. I would add the same is true for driving excellence.
Wednesday, January 28, 2009
Best software dev books
I'm in the middle of reading Agile Software Development, and it has already cracked my top 5 favorite software development books of all time. A more detailed review will be forthcoming.
My five favorite software development books (with links to Amazon because the reviews can be helpful):
Code Complete by Steve McConnell
Agile Software Development, Principles, Patterns, and Practices by Robert C. Martin
Effective Java by Joshua Block
Refactoring by Martin Fowler
Thinking in Java by Bruce Eckel
Also see this somewhat scientifically compiled list of the best software dev books of all time by Jurgen Appelo. Perhaps not surprisingly, three of mine show up in the top 10.
I see I have left off The Mythical Man-Month, which is a classic; very insightful and still highly relevant. That one probably would bump Thinking in Java, but I'm giving Eckel extra points for being a vanguard and publishing for free. I'm surprised more people have not followed this path -- and yes, I ended up buying a hard-copy. I haven't read five in the top ten.
My five favorite software development books (with links to Amazon because the reviews can be helpful):
Code Complete by Steve McConnell
Agile Software Development, Principles, Patterns, and Practices by Robert C. Martin
Effective Java by Joshua Block
Refactoring by Martin Fowler
Thinking in Java by Bruce Eckel
Also see this somewhat scientifically compiled list of the best software dev books of all time by Jurgen Appelo. Perhaps not surprisingly, three of mine show up in the top 10.
I see I have left off The Mythical Man-Month, which is a classic; very insightful and still highly relevant. That one probably would bump Thinking in Java, but I'm giving Eckel extra points for being a vanguard and publishing for free. I'm surprised more people have not followed this path -- and yes, I ended up buying a hard-copy. I haven't read five in the top ten.
Tuesday, January 27, 2009
On becoming a manager
I like this description of becoming a manager from Rands in Repose. If you're thinking you might want to be a manager, this gives you a pretty good idea about how you would spend your day if you're doing it right.
I would summarize a manager's duties to the team as "empower, motivate, and mentor". It's that simple. Make sure your team has the tools. Remove obstacles. Find out what motivates each of them individually and figure out how to supply it. Personally train them. Use mistakes as moments for expensive learning, not prosecutions.
If you focus on these things, you will succeed. In focusing on these things, you will find yourself doing many of the items on Rands's list.
Your job as a manager is to scale the skills that got you the gig in the first place. You used to be the guy who did the impossible when it came to fixing bugs. Ok, now you’re the guy whose entire team does the impossible bug fixing.One thing to keep in mind is the purpose of a manager. It's important to ground your daily maneuvers in a larger, meaningful plan.
I would summarize a manager's duties to the team as "empower, motivate, and mentor". It's that simple. Make sure your team has the tools. Remove obstacles. Find out what motivates each of them individually and figure out how to supply it. Personally train them. Use mistakes as moments for expensive learning, not prosecutions.
If you focus on these things, you will succeed. In focusing on these things, you will find yourself doing many of the items on Rands's list.
Sunday, January 25, 2009
Software trade-offs
A couple of interesting summaries about very visible software problems.
1. Facebook algorithm to squash spam crushes real accounts. Does benefiting the vast majority justify screwing over a few outliers? Which trade-off better "serves the customer"?
2. On-line game Eve faces financial meltdown. The kicker is that, in a "Being John Malkovich" kind of irony, the real financial meltdown is causing problems for the software company that runs Eve. If money stops functioning in Eve, the game itself could suffer (who wants to be destitute in fiction as well as real life?) -- should the developers step in and fix things, as god?
1. Facebook algorithm to squash spam crushes real accounts. Does benefiting the vast majority justify screwing over a few outliers? Which trade-off better "serves the customer"?
2. On-line game Eve faces financial meltdown. The kicker is that, in a "Being John Malkovich" kind of irony, the real financial meltdown is causing problems for the software company that runs Eve. If money stops functioning in Eve, the game itself could suffer (who wants to be destitute in fiction as well as real life?) -- should the developers step in and fix things, as god?
Friday, January 23, 2009
Strange days
This is a weird time on the job. I work in the financial services industry, which gets hammered daily by new layoffs -- jobs that have disappeared and won't be back for many years, if ever.
And yet, right now there is a labor surplus. Because of all the uncertainty, many people don't have projects to work on, or their manager has been canned and no one's setting priorities.
Usually, people take an opportunity like this to relax. Phone's ringing? There's 3 other guys who can get it. New work request? I'll take a look after a long lunch, or maybe tomorrow since I'm leaving early.
Not these days.
Everyone senses that their job is tenuous. And for the first time in many of these people's careers, there's nothing to jump to.
So, instead, when the phone rings, it gets picked up during the first half-ring. I put in a PC service request that would usually take a few days to get responded to, much less resolved, and someone called me within a half hour, and then sat at my desk for the next 3 hours to solve the problem. People are helpful and polite.
Not to say that it was a bad work environment before. Just that people were very busy, and things often took a long time to get through the sausage grinder.
Just noticing the irony that the appearance of things getting done quickly and working especially well is actually being driven by things not working well.
And yet, right now there is a labor surplus. Because of all the uncertainty, many people don't have projects to work on, or their manager has been canned and no one's setting priorities.
Usually, people take an opportunity like this to relax. Phone's ringing? There's 3 other guys who can get it. New work request? I'll take a look after a long lunch, or maybe tomorrow since I'm leaving early.
Not these days.
Everyone senses that their job is tenuous. And for the first time in many of these people's careers, there's nothing to jump to.
So, instead, when the phone rings, it gets picked up during the first half-ring. I put in a PC service request that would usually take a few days to get responded to, much less resolved, and someone called me within a half hour, and then sat at my desk for the next 3 hours to solve the problem. People are helpful and polite.
Not to say that it was a bad work environment before. Just that people were very busy, and things often took a long time to get through the sausage grinder.
Just noticing the irony that the appearance of things getting done quickly and working especially well is actually being driven by things not working well.
Thursday, January 22, 2009
Antipatterns by Philip Laplante
I loved the idea of this book. Knowing what you don't know, as a starting point, often helps you know more. True story: many years ago I considered writing a dictionary of what things aren't, an anti-dictionary. Some words are simply too big or too ambiguous to get boxed in. What is "life" for example?Similarly, recognizing dysfunction can help you operate more functionally. This book tries to categorize the ways a manager or an organization can be dysfunctional.
One strong point of the book is that the list of antipatterns is pretty thorough. Most of them are instantly recognizable, especially if you've worked in a few companies. Some you recognize, but might not have thought of before as problems, like Warm Bodies -- people who should actually be let go, but just get passed around from one ill-fitting job to another.
The section I liked the best was "Identification". If you answer yes to the questions in this section, you may be facing this antipattern. Many times, these questions were not obvious, and helped illuminate the antipattern.
For example,
Everybody likes John — but no one can figure out what he actually does.is a subtle way of identifying a Warm Body. I knew the antipattern, and have seen people like that, but never thought that the two might be connected (and of course they aren't always).
In addition, the writing was very accessible, and the authors allowed their personality to show, which always makes a book more enjoyable.
Noticeably lacking was what to do when confronted with one of these antipatterns. If you find yourself behaving this way, the advice almost always boiled down to "stop doing it." Not too helpful. Frequently, if you find someone else doing it, the advice was to "try to ignore it" or "schedule around it" or "sit back and laugh about it". Not too helpful.
An even bigger oversight was a lack of examples and explanations of why these behaviors occur, and what, if any, positives arise from them. They did a great job with Rising Upstart -- a young, very eager achiever -- recognizing that this is both a benefit and something that needs to be handled carefully. But most of the time, the antipatterns were treated as an illness that only ogres and irrational people would fall victim to. If these behaviors are rampant, there must be underlying causes.
For example, Mushroom Management -- the problem of managers keeping everyone in the dark (mushrooms grow in the dark) -- was rightfully decried as breeding suspicion, sucking down morale, and being ineffective. Still, some analysis about why managers do this would contribute to a richer understanding of how to deal with it.
One underlying cause is that more communication is not always better. In this depressed economic time, constant communication about the latest management thoughts on layoffs would be counter-productive. Management might be keeping their mouths shut because sensitive decisions are being made. Given that, what is the best way to handle the situation? That becomes a more meaningful discussion.
This book will be most useful to people starting their careers or those who are just beginning to think about moving into management. Many of the antipatterns can be avoided, and identification is half the battle. As an introduction to what not to do, this is a great start.
Wednesday, January 21, 2009
Cohesion and the financial meltdown
One fundamental attribute of good code is cohesiveness. A function with good cohesion does only one thing and does it well. There's plenty of material on this subject in books and on the web.
Sometimes, a good metaphor really brings it home. The current financial meltdown may illuminate the value of cohesion.
The problem with today's banks is that they were trying to do two things.
1. provide banking services to the public (individuals and companies): take deposits and make loans
2. trade and invest for profit
If a company loses money trading, no one really minds. If banks were only trading for profit (or a loss in today's market), we'd let them go under quietly, like the hedge funds.
Unfortunately, because they're also running banking services, people start worrying about access to their cash. The panic of a run on the banks would cause a global calamity. (We're talking large and institutional investors; deposits of small investors are generally guaranteed by the government.) In addition, because the banks need to manage their cash due to their trading and investment losses, they've stopped making loans. Solvent businessses who need a short term loan to expand or cover sudden cost spikes can't get funds.
As a result, we have to support the entire bank, even though we really want to only keep the banking services part. The cost of this lack of cohesion? $700 billion and counting. And that's just maintenance -- doesn't include refactoring.
Sadly, we once had a more cohesive system. It was called the Glass-Steagal Act, the expressed purpose of which was to "prohibit the large private banks whose chief business is investment business, from receiving deposits".
When was Glass-Steagall enacted? During the Great Depression, in order to prevent another global financial crisis.
What company was the the impetus for its repeal? Citicorp. They wanted to merge with Travelers insurance. Yes, the same bank that has received the most bailout funds and will be forced to break up. Here's a brief history.
Your code isn't going to cost $700 billion to maintain, no matter how badly written. But, as a percentage of your staff's time and budget, a systemic lack of cohesion makes a huge impact. Eventually, the changes required can overwhelm your ability to do anything without massive investment, e.g., throwing it away.
Sometimes, a good metaphor really brings it home. The current financial meltdown may illuminate the value of cohesion.
The problem with today's banks is that they were trying to do two things.
1. provide banking services to the public (individuals and companies): take deposits and make loans
2. trade and invest for profit
If a company loses money trading, no one really minds. If banks were only trading for profit (or a loss in today's market), we'd let them go under quietly, like the hedge funds.
Unfortunately, because they're also running banking services, people start worrying about access to their cash. The panic of a run on the banks would cause a global calamity. (We're talking large and institutional investors; deposits of small investors are generally guaranteed by the government.) In addition, because the banks need to manage their cash due to their trading and investment losses, they've stopped making loans. Solvent businessses who need a short term loan to expand or cover sudden cost spikes can't get funds.
As a result, we have to support the entire bank, even though we really want to only keep the banking services part. The cost of this lack of cohesion? $700 billion and counting. And that's just maintenance -- doesn't include refactoring.
Sadly, we once had a more cohesive system. It was called the Glass-Steagal Act, the expressed purpose of which was to "prohibit the large private banks whose chief business is investment business, from receiving deposits".
When was Glass-Steagall enacted? During the Great Depression, in order to prevent another global financial crisis.
What company was the the impetus for its repeal? Citicorp. They wanted to merge with Travelers insurance. Yes, the same bank that has received the most bailout funds and will be forced to break up. Here's a brief history.
Your code isn't going to cost $700 billion to maintain, no matter how badly written. But, as a percentage of your staff's time and budget, a systemic lack of cohesion makes a huge impact. Eventually, the changes required can overwhelm your ability to do anything without massive investment, e.g., throwing it away.
Tuesday, January 20, 2009
Open office spaces reduce productivity?
A recent study finds that open office space reduces productivity, results in more illnesses, and is universally disliked.
I'm going to take the unpopular side of this argument (with one caveat). I'm a strong believer in the social life of information, and I think cubes are a great way to facilitate that.
When I started working, everyone had their own office or shared one with one or two other people, similar to what Joel Spolsky advocates. This worked well, or maybe it just seemed normal because that's the way it was.
Sometime in the 90s, everything changed to cubes. I hated them. All cubes were the same then -- about 5.5 feet tall. They are the tall ones with the overhead storage in this picture. You could only see the tops of people's heads when they stood up. I would frequently think about how to enclose the roof and add a door. The lack of privacy really bothered me.
Then, around 2002, my new job had cubes about 4.5 feet high. It was a lot more open -- and I liked it a lot more than the taller cubes! If we had a production emergency, everyone could stand up and talk to each other. Communication was a lot easier. At some point, I was offered my own office (which had a good view), and I turned it down because I would be less productive: if I wanted any information, I would have to go around and ask people. In fact, I thought the partitions should be a little lower, maybe 4 feet.
Last year, I moved to a new location. The cubes here are about 3.5 feet high. Too low. You can see the person on the other side of the partition even when sitting down.
Based on these experiences, I think the optimal height is tall enough to not see anyone when you're sitting, but low enough to let everyone see each other when standing.
The caveat to this whole thing is that conference rooms that can also function as private phone rooms should be plentiful. Plentiful enough so that teams can usually meet at a moment's notice without a reservation. This alleviates the privacy issue and further encourages collaboration. You can actually take a tour of Joel's new digs.
Not having access to the study, it is difficult to know what it really studied. It's not clear whether loss of productivity is just self-reported, due to time out due to sickness and turnover, or actually quantified in some official economically measured way.
I'm also willing to bet that most of these offices didn't have enough conference / private rooms.
I'm going to take the unpopular side of this argument (with one caveat). I'm a strong believer in the social life of information, and I think cubes are a great way to facilitate that.
When I started working, everyone had their own office or shared one with one or two other people, similar to what Joel Spolsky advocates. This worked well, or maybe it just seemed normal because that's the way it was.
Sometime in the 90s, everything changed to cubes. I hated them. All cubes were the same then -- about 5.5 feet tall. They are the tall ones with the overhead storage in this picture. You could only see the tops of people's heads when they stood up. I would frequently think about how to enclose the roof and add a door. The lack of privacy really bothered me.
Then, around 2002, my new job had cubes about 4.5 feet high. It was a lot more open -- and I liked it a lot more than the taller cubes! If we had a production emergency, everyone could stand up and talk to each other. Communication was a lot easier. At some point, I was offered my own office (which had a good view), and I turned it down because I would be less productive: if I wanted any information, I would have to go around and ask people. In fact, I thought the partitions should be a little lower, maybe 4 feet.
Last year, I moved to a new location. The cubes here are about 3.5 feet high. Too low. You can see the person on the other side of the partition even when sitting down.
Based on these experiences, I think the optimal height is tall enough to not see anyone when you're sitting, but low enough to let everyone see each other when standing.
The caveat to this whole thing is that conference rooms that can also function as private phone rooms should be plentiful. Plentiful enough so that teams can usually meet at a moment's notice without a reservation. This alleviates the privacy issue and further encourages collaboration. You can actually take a tour of Joel's new digs.
Not having access to the study, it is difficult to know what it really studied. It's not clear whether loss of productivity is just self-reported, due to time out due to sickness and turnover, or actually quantified in some official economically measured way.
I'm also willing to bet that most of these offices didn't have enough conference / private rooms.
Sunday, January 18, 2009
To do today
If you're a developer, you're asked to do a lot: deliver creative solutions on extremely tight deadlines that are robust enough to withstand unforeseeable and, frankly, unbelievable misuse and abuse from users. Meanwhile, you have to stay on top of technology, deal with the personalities around you, navigate all the infrastructure, and have a life.
I know all this. I once compiled a list of over a hundred attributes a coder could be evaluated on, and each of those could be decomposed into multiple sub-attributes, so believe me, I do know all this. I lived it for many years.
Still, I'm going to add something to your pile, near the top of the list.
Communicate with your user.
This means getting access as often as possible to product owners. Ask lots of questions right to the experts. Hopefully you do your own demos to them as well.
On a daily basis, you should see someone on the business. "Any reactions to the new order entry screen?" "How are the requirements looking for New Customer?" If it's 3 pm and you haven't talked to anyone on the business side, take a 5 minute break, walk to the trading floor or the sales cubes, or whatever business it is that you support, and ask "How's the market?" "You see what Competitor A released last week?"
If you don't have someone with whom you can do this without feeling awkward, that's a clear indication that you aren't doing this enough. Over time, you'll find some people who are easy to approach and open to talking to you.
Daily conversation keeps you in the loop. More importantly, it establishes a collegial basis on which to have difficult discussions that could come up later. It's going to be a lot easier to ask your sales expert questions about customer demand while setting requirements if it's not the first time in 3 months that you're talking to her.
I know all this. I once compiled a list of over a hundred attributes a coder could be evaluated on, and each of those could be decomposed into multiple sub-attributes, so believe me, I do know all this. I lived it for many years.
Still, I'm going to add something to your pile, near the top of the list.
Communicate with your user.
This means getting access as often as possible to product owners. Ask lots of questions right to the experts. Hopefully you do your own demos to them as well.
On a daily basis, you should see someone on the business. "Any reactions to the new order entry screen?" "How are the requirements looking for New Customer?" If it's 3 pm and you haven't talked to anyone on the business side, take a 5 minute break, walk to the trading floor or the sales cubes, or whatever business it is that you support, and ask "How's the market?" "You see what Competitor A released last week?"
If you don't have someone with whom you can do this without feeling awkward, that's a clear indication that you aren't doing this enough. Over time, you'll find some people who are easy to approach and open to talking to you.
Daily conversation keeps you in the loop. More importantly, it establishes a collegial basis on which to have difficult discussions that could come up later. It's going to be a lot easier to ask your sales expert questions about customer demand while setting requirements if it's not the first time in 3 months that you're talking to her.