Being visible is often encouraged during a crisis. When the software isn't working right, I try to next to my business users, take the heat, then figure out how to can make a quick improvement.
Similarly, when a company is doing badly, the leaders need to get in front of their groups. The leaders showing their faces can help rally the troops.
It's sad to report, then, that the opposite seems to be happening in my group. While the CEO has done a good job with his emails, our group leaders have really botched it.
The head of the business unit has scheduled, canceled, and rescheduled his meeting with the IT staff four times. The CIO has scheduled, canceled, and rescheduled his meeting with our IT staff three times. Both of these meetings are now scheduled for late this month. We'll see what happens.
Meeting the "people", spreading optimism, sharing a vision -- this is one of the completely free things that a leader can do that can make a big difference. It assures people that their work is important and valued. Canceling, on the other hand, demonstrates that many other things have priority.
Yes, I'm sure both of these men are busy. But they also surely know the importance of keeping commitments. If their schedules prevent them from making a one hour commitment, they shouldn't do it. At this point, we'd be far better off if they'd simply never bothered.
If being visible helps with crisis management, what does being noticeably invisible do?
Thursday, May 14, 2009
Tuesday, May 12, 2009
Slow software practices
Alex Tabarrok highlighted this chart about eating. Somewhat paradoxically, more time spent eating actually resulted in lower obesity.I wondered whether a similar effect might exist for software.
It's easy to think of a hypothesis where this could be true. Quickly built software, with fingers flying, usually allows little time for planning. The goal is to get the code out as soon as possible, and lots of code is what happens.
All that code begets more code fixes. Also, the code likely doesn't involve a lot of abstraction, having been built for some specific cause, the emergency of the day. Thus the next emergency requires new, specific code for it, as well.
Perhaps a slow software movement is what we need. Of course, our company owners and business managers would freak out if we started saying that we're adopting "slow software practices".
So, of course, we call it other things -- requirements gathering or architecture review or quality control. But at the heart, one of the main elements of all of them is to slow things down, to create room to stop and think.
Keep that in mind the next time you're facing a project. Yes, it needs to get done right away, but invest in yourself and the project, and slow down.
Monday, May 11, 2009
Good is bad, better is worse
The economy seems getting better. The markets the past couple weeks might even be called good.
All of that is bad news for my company. I will not mention my company's name, but suffice to say that it is a large Wall Street investment bank.
Here's my company's current plan: cut costs, avoid losses, reduce risk. This is, I think, a recipe for disaster. An investment bank only grows by taking risks. That's what you get paid for! The idea that you could back into profitability by reducing losses goes against the business model. It's tantamount to not servicing the airplanes in order to save money.
The worst part is, an almost tangible sense of disillusionment is settling in among the troops. Last week, I felt surrounded by it. Two things always happen in these situations:
1) First, the best people leave. So far, that hadn't really happened, mainly because the economy stunk. Now with growing hope at the macro level, people realize they have options. I only know of a little turnover, but I can seriously feel it in the air. A flood of exits wouldn't surprise me at all.
2) When the best people leave, the good ones follow. The company that remains resembles the decrepit local mall, where no one really shops anymore, and the staff of teenagers doesn't care about the store, service, or customers. They're just drawing a check. I've personally seen increasing evidence of this.
If you're a manager or have any personal influence, you can do something about this. But, as with many situations, if you're someone who might try to do something about this, you'll most likely be one of the flood going out the door (see #1 above).
When things getting better are bad for the company, the game is surely up.
All of that is bad news for my company. I will not mention my company's name, but suffice to say that it is a large Wall Street investment bank.
Here's my company's current plan: cut costs, avoid losses, reduce risk. This is, I think, a recipe for disaster. An investment bank only grows by taking risks. That's what you get paid for! The idea that you could back into profitability by reducing losses goes against the business model. It's tantamount to not servicing the airplanes in order to save money.
The worst part is, an almost tangible sense of disillusionment is settling in among the troops. Last week, I felt surrounded by it. Two things always happen in these situations:
1) First, the best people leave. So far, that hadn't really happened, mainly because the economy stunk. Now with growing hope at the macro level, people realize they have options. I only know of a little turnover, but I can seriously feel it in the air. A flood of exits wouldn't surprise me at all.
2) When the best people leave, the good ones follow. The company that remains resembles the decrepit local mall, where no one really shops anymore, and the staff of teenagers doesn't care about the store, service, or customers. They're just drawing a check. I've personally seen increasing evidence of this.
If you're a manager or have any personal influence, you can do something about this. But, as with many situations, if you're someone who might try to do something about this, you'll most likely be one of the flood going out the door (see #1 above).
When things getting better are bad for the company, the game is surely up.
Thursday, May 7, 2009
Bruce Eckel, publishing revolutionary
According to my recollection, Bruce Eckel put out the first digital book for free at the same time he had a best-selling hard copy at the book store. I believe the free version played a big role in Thinking in Java selling so well. At my dot-com, everyone who learning java started with his book, being free, and then eventually most of us bought it.
He made his book not only free on-line, but downloadable as both pdf and html. He didn't try to ramp up website stats by making you read the html on his site.
I actually thought that Bruce's successful example would herald a new day when free digital versions of book would become more common. Trying to break through a cluttered market can be difficult, and offering a free version might be the answer.
That day never came. So Bruce remains an anomalous experiment. I'm glad it paid off for him.
Bruce's latest idea (part of this interview) is equally brilliant.
A truly radical and fitting end to a book that started radically as well.
He made his book not only free on-line, but downloadable as both pdf and html. He didn't try to ramp up website stats by making you read the html on his site.
I actually thought that Bruce's successful example would herald a new day when free digital versions of book would become more common. Trying to break through a cluttered market can be difficult, and offering a free version might be the answer.
That day never came. So Bruce remains an anomalous experiment. I'm glad it paid off for him.
Bruce's latest idea (part of this interview) is equally brilliant.
I hope to make [the latest version of Thinking in Java] a community effort, to be published electronically under the creative commons.Not that we need intro to java books so much these days -- but all the more reason to embed it into the landscape permanently. Give it to the software community, who knows what it will turn into. At the least, it could become the final, definitive book on learning java as a beginner.
A truly radical and fitting end to a book that started radically as well.
Wednesday, May 6, 2009
Everyone becomes incompetent
The quote comes from this chapter in Scott Berkun's book Beautiful Teams. I particularly like the first and last sentences of this excerpt:
Bad projects take on a life of their own, and even good people can get taken down by them. We like to believe that good project and team management and solid developers prevent or overcome bad projects, but that's often not true. Bad things happen to good people all the time.
Everyone, to a person, will end up working on a fair number of bad projects in their careers. In some cases, there's nothing you can do about them -- except learn from them. Figure out what made them bad, understand the warning signs, and consider what might have made a difference.
From reading Berkun, I get the sense he does this very well, which make his Microsoft anecdotes very powerful.
If enough big things go wrong, everyone becomes incompetent. Everyone gets ugly. People quit. Despair rose. Managers stormed out of meetings and heavy things were thrown across boardrooms. Months flew by and therapy bills rose. As other parts of the project were completed, we tried not to notice the gaping Channels-shaped black hole at our center, slowly pulling everything inside.I remember Channels well. I never used it, and always disabled it immediately, and occasionally it would reappear again. It was intrusively annoying, much like Windows Messenger now.
Bad projects take on a life of their own, and even good people can get taken down by them. We like to believe that good project and team management and solid developers prevent or overcome bad projects, but that's often not true. Bad things happen to good people all the time.
Everyone, to a person, will end up working on a fair number of bad projects in their careers. In some cases, there's nothing you can do about them -- except learn from them. Figure out what made them bad, understand the warning signs, and consider what might have made a difference.
From reading Berkun, I get the sense he does this very well, which make his Microsoft anecdotes very powerful.
Monday, May 4, 2009
Excellence is the best job security
A few months back, a friend asked me a question.
He was in the middle of developing several new major features for his application at his investment bank. Meanwhile, he expected layoffs within a few months. As a result, new features weren't being discussed until the layoffs occurred. Was it wise to finish off his work, even though that would leave him with nothing to do at the time that layoffs were likely? Isn't that like asking to be laid off?
Situations like these make me re-examine my motto "always put yourself out of a job." Maybe this -- a crisis of a lifetime in his industry -- was the exception to the rule.
But I told him that he should continue to work at his best rate. By pushing himself, he'd keep his mind sharp. He'd get to finish the project and understand it thoroughly. He'd burnish a reputation as a professional programmer who did excellent work. Whether or not his name ended up on the list, all of these factors would make him either a stronger developer at his current place of work or a stronger candidate for the next one.
Last week, his company did have those layoffs. But, we'll never know if he was on the list, because a couple weeks before, he accepted a great new job. Some of the experience he earned in his last project made him very attractive to his new employer.
I take no credit for his success; obviously, he did all that on his own. But it is nice to see one's personal theory get validated in real life, especially in a tough market like the current one.
He was in the middle of developing several new major features for his application at his investment bank. Meanwhile, he expected layoffs within a few months. As a result, new features weren't being discussed until the layoffs occurred. Was it wise to finish off his work, even though that would leave him with nothing to do at the time that layoffs were likely? Isn't that like asking to be laid off?
Situations like these make me re-examine my motto "always put yourself out of a job." Maybe this -- a crisis of a lifetime in his industry -- was the exception to the rule.
But I told him that he should continue to work at his best rate. By pushing himself, he'd keep his mind sharp. He'd get to finish the project and understand it thoroughly. He'd burnish a reputation as a professional programmer who did excellent work. Whether or not his name ended up on the list, all of these factors would make him either a stronger developer at his current place of work or a stronger candidate for the next one.
Last week, his company did have those layoffs. But, we'll never know if he was on the list, because a couple weeks before, he accepted a great new job. Some of the experience he earned in his last project made him very attractive to his new employer.
I take no credit for his success; obviously, he did all that on his own. But it is nice to see one's personal theory get validated in real life, especially in a tough market like the current one.
Thursday, April 30, 2009
What else I hate about Microsoft "programming"
Answer: I never know what's actually going on!
I work with some guys who are pretty knowledgeable about Microsoft development, very solid guys.
Still, when something goes wrong -- the data load craps out, the website doesn't show some reports, the reports server doesn't respond quickly -- the usual answer is to simply restart. "Restart IIS" or "delete the reports and then re-deploy them" or "delete all the data from that table and reload it from scratch". Sometimes, I'll have an error that will persist for half a day and then suddenly disappear, and they'll say, "Yeah, that happens sometimes, you just keep trying."
Restarting frequently works. If you've ever worked on a support desk, you know that one of your friends is the "restart your PC". That often resolves whatever weird error your user has.
But that isn't solving the problem, it's just erasing the situation that created it, in the hopes that it doesn't occur again.
I think part of the problem is that Microsoft targets users (in this case developers) who just wants to get it done, and not users who want to know the dirty details. Creating anything involves going through a wizard process. They spend lots of resources making sure things happen automatically.
What they don't spend their resources on is making the underlying mechanics visible. Typically, you'll get an error, and then the strategy involves looking up the cryptic error message in Google. From that, many different suggestions will be returned, and you look through each one to see if it applies to you. This is not debugging.
As a result, I never feel confident that things will work correctly. I never feel confident that when things fail, I will understand why they're failing. I never feel confident that if I don't know why things are failing, I can debug it to the point where I can find a root cause.
It takes impressive effort to automate so much, and for a lot of people -- Microsoft's target audience, presumably -- this gets them to the point they need to get to. So, this is not intended to be a Microsoft bashing exercise.
At the end of the day, though, as I mentioned before, if all programming was strictly programming on the Microsoft platform, I doubt I would have lasted long as a programmer.
I work with some guys who are pretty knowledgeable about Microsoft development, very solid guys.
Still, when something goes wrong -- the data load craps out, the website doesn't show some reports, the reports server doesn't respond quickly -- the usual answer is to simply restart. "Restart IIS" or "delete the reports and then re-deploy them" or "delete all the data from that table and reload it from scratch". Sometimes, I'll have an error that will persist for half a day and then suddenly disappear, and they'll say, "Yeah, that happens sometimes, you just keep trying."
Restarting frequently works. If you've ever worked on a support desk, you know that one of your friends is the "restart your PC". That often resolves whatever weird error your user has.
But that isn't solving the problem, it's just erasing the situation that created it, in the hopes that it doesn't occur again.
I think part of the problem is that Microsoft targets users (in this case developers) who just wants to get it done, and not users who want to know the dirty details. Creating anything involves going through a wizard process. They spend lots of resources making sure things happen automatically.
What they don't spend their resources on is making the underlying mechanics visible. Typically, you'll get an error, and then the strategy involves looking up the cryptic error message in Google. From that, many different suggestions will be returned, and you look through each one to see if it applies to you. This is not debugging.
As a result, I never feel confident that things will work correctly. I never feel confident that when things fail, I will understand why they're failing. I never feel confident that if I don't know why things are failing, I can debug it to the point where I can find a root cause.
It takes impressive effort to automate so much, and for a lot of people -- Microsoft's target audience, presumably -- this gets them to the point they need to get to. So, this is not intended to be a Microsoft bashing exercise.
At the end of the day, though, as I mentioned before, if all programming was strictly programming on the Microsoft platform, I doubt I would have lasted long as a programmer.
Wednesday, April 29, 2009
What I hate about Microsoft "programming"
Answer: it doesn't feel like programming!
For the first time in a very long time, I'm doing development on a pure-Microsoft app: sql server, asp.net front end, sharepoint, etc. This is all new technology to me, though of course it is similar to other things I've done.
What's brilliant about Microsoft stuff is it can generate a multi-layer, multiple-technology application in a very short time.
Along the way, I write a few queries and such, but mostly I find myself configuring. Configure the reports server to talk to the database. Configure the web server so it doesn't have port conflicts. Configure the deployment tool to generate to the right location. Draw lines between two tables to configure the data mapping.
I'm not suggesting this is easy. The details behind each configuration holds many hours of potential problems, and expertise pays for itself.
In the end, though, I feel more like a sys admin than a programmer. Perhaps it is a compliment to Microsoft that entire apps can be built without knowing much about code. But, just as I was never interested in being a sys admin, I never would have become a programmer if this is all it consisted of.
For the first time in a very long time, I'm doing development on a pure-Microsoft app: sql server, asp.net front end, sharepoint, etc. This is all new technology to me, though of course it is similar to other things I've done.
What's brilliant about Microsoft stuff is it can generate a multi-layer, multiple-technology application in a very short time.
Along the way, I write a few queries and such, but mostly I find myself configuring. Configure the reports server to talk to the database. Configure the web server so it doesn't have port conflicts. Configure the deployment tool to generate to the right location. Draw lines between two tables to configure the data mapping.
I'm not suggesting this is easy. The details behind each configuration holds many hours of potential problems, and expertise pays for itself.
In the end, though, I feel more like a sys admin than a programmer. Perhaps it is a compliment to Microsoft that entire apps can be built without knowing much about code. But, just as I was never interested in being a sys admin, I never would have become a programmer if this is all it consisted of.
Tuesday, April 28, 2009
Return of the bonus
After all the recent talk about remaking Wall Street and changing the culture of greed, the bonus claws back.
Yes, these people work hard, and they generate a lot of money for their companies. I call that having a job. The vast majority should get a reasonable salary and then a very modest bonus. Then, by all means, give a bigger bonus to reward the high producers to separate them from the middle of the pack. But the middle of the pack guys make huge money. That makes no sense.
According to the article above: "Historically, investment banks have paid workers about 50 cents for every dollar of revenue." If that doesn't shock you, then nothing I could say could change your opinion.
Just keep in mind that the bankers in Iceland didn't do anything worse than what happened here in the U.S. The only difference is, their economy wasn't large enough to bail out their financial industry. So, before we return to "normal", don't forget how bankers are viewed in Iceland!
[Goldman Sachs], which nearly halved its compensation last year, set aside $4.7 billion for worker pay in the quarter. If that level continues all year, it would add up to average pay of $569,220 per worker — almost as much as the pay in 2007, a record year.Not to pick on Goldman -- they're just the example -- but crazy, out sized bonuses create the wrong incentives. Especially in a culture of money, they distort the entire system.
Yes, these people work hard, and they generate a lot of money for their companies. I call that having a job. The vast majority should get a reasonable salary and then a very modest bonus. Then, by all means, give a bigger bonus to reward the high producers to separate them from the middle of the pack. But the middle of the pack guys make huge money. That makes no sense.
According to the article above: "Historically, investment banks have paid workers about 50 cents for every dollar of revenue." If that doesn't shock you, then nothing I could say could change your opinion.
Just keep in mind that the bankers in Iceland didn't do anything worse than what happened here in the U.S. The only difference is, their economy wasn't large enough to bail out their financial industry. So, before we return to "normal", don't forget how bankers are viewed in Iceland!
Monday, April 27, 2009
Firing up the troops
A friend of mine works at a financial firm that had big layoffs last week. On Friday, after 4 brutal days of layoffs, the COO held a town hall with several hundred people at the corporate headquarters.
Out of that speech, here's the line that my friend remembered:
"As you know, we have a lot fewer people now, so everyone here will have to work harder and longer hours."
Message to COOs (and other executives): if that's what's in your head, better to keep your mouth shut. All the time you and your staff spent putting the powerpoint together, arranging the room and AV equipment, and assembling everyone for the town hall would be better spent focusing on business problems.
I'm sure nice words surrounded that sentence -- things like "Our people are our most valuable asset" and "Market conditions forced us to make these difficult choices" -- but none of that rings with authenticity. The bit about working harder? That sounds very real.
I doubt many people physically walked out, but I'm sure a large percentage mentally did. As soon as the market turns, those people will walk out. They're fired up all right.
A speech like that isn't communication and it isn't leadership.
Out of that speech, here's the line that my friend remembered:
"As you know, we have a lot fewer people now, so everyone here will have to work harder and longer hours."
Message to COOs (and other executives): if that's what's in your head, better to keep your mouth shut. All the time you and your staff spent putting the powerpoint together, arranging the room and AV equipment, and assembling everyone for the town hall would be better spent focusing on business problems.
I'm sure nice words surrounded that sentence -- things like "Our people are our most valuable asset" and "Market conditions forced us to make these difficult choices" -- but none of that rings with authenticity. The bit about working harder? That sounds very real.
I doubt many people physically walked out, but I'm sure a large percentage mentally did. As soon as the market turns, those people will walk out. They're fired up all right.
A speech like that isn't communication and it isn't leadership.
Thursday, April 23, 2009
Swimming is Agile
I've now swam 1 mile -- 32 times up and back in a half-Olympic sized pool -- 3 times in the last week. Today I realized that I organized my swimming routine iteratively: each set builds on the last and accomplishes something new.
1. 5 laps doing the breast stroke (aka frog kick) with little effort. The main point is to limber up.
2. 5 laps doing the breast stroke with effort.
3. 5 laps doing the crawl (aka freestyle) with only leg effort. I keep my fingers separated to minimize any temptation to pull and don't do any reaching with my arms, focusing totally on leg technique. Some people use a kickboard for this kind of practice, but I'm too lazy to stop.
4. 5 laps doing the crawl with leg effort and arm technique. I add arm technique, but my arms don't really do any pulling, just go through the proper motions.
5. 5 laps doing the crawl with leg effort and arm pulling. This might be called real swimming.
6. 5 laps doing the crawl with leg effort and fast arm pulling. My arms are a blur (I like to think), pulling non-stop.
7. 2 laps of my choice: either continue with the crawl or backstroke.
Two advantages become apparent. First, the last two laps are a freebie, even though they're not; the fact that I choose keeps them from being a chore. Second, breaking it up makes it feasible; if I started on set one and had to count to 32, the goal would be too far ahead to mentally grasp. I can count up to 5 comfortably. I never, ever think during my 5th set, "Wow, this is my 25th lap!"
Note that I didn't plan it that way. Before I reached a mile, I had similar divisions, with fewer laps.
Perhaps iterative development infects everything you do, or some people just think that way.
1. 5 laps doing the breast stroke (aka frog kick) with little effort. The main point is to limber up.
2. 5 laps doing the breast stroke with effort.
3. 5 laps doing the crawl (aka freestyle) with only leg effort. I keep my fingers separated to minimize any temptation to pull and don't do any reaching with my arms, focusing totally on leg technique. Some people use a kickboard for this kind of practice, but I'm too lazy to stop.
4. 5 laps doing the crawl with leg effort and arm technique. I add arm technique, but my arms don't really do any pulling, just go through the proper motions.
5. 5 laps doing the crawl with leg effort and arm pulling. This might be called real swimming.
6. 5 laps doing the crawl with leg effort and fast arm pulling. My arms are a blur (I like to think), pulling non-stop.
7. 2 laps of my choice: either continue with the crawl or backstroke.
Two advantages become apparent. First, the last two laps are a freebie, even though they're not; the fact that I choose keeps them from being a chore. Second, breaking it up makes it feasible; if I started on set one and had to count to 32, the goal would be too far ahead to mentally grasp. I can count up to 5 comfortably. I never, ever think during my 5th set, "Wow, this is my 25th lap!"
Note that I didn't plan it that way. Before I reached a mile, I had similar divisions, with fewer laps.
Perhaps iterative development infects everything you do, or some people just think that way.
Tuesday, April 21, 2009
Don't let the uncertainties stop you
I might agree with just about everything Johanna Rothman has to say about the Big Agile Survey, such as:
Some things should be implemented with extreme care and well-understood benefits. Much of software development falls in this category. But most things in life don't, and that includes everything that happens on a blog.
Surveys about any practices without considering the industry, the products, and the management don’t tell you much. People lie to themselves about what they are really doing.but I still think it's a good idea. I'm sure Jurgen will get the most benefit, so that's point 1. Point 2 is it doesn't really harm anyone. Point 3 is that things that might benefit you a lot and don't hurt anyone else are worth trying at least once. He might get some interesting insights into the Agile market. At worst, he'll learn something about running surveys.
Some things should be implemented with extreme care and well-understood benefits. Much of software development falls in this category. But most things in life don't, and that includes everything that happens on a blog.
Comprehensive Agile survey
Jurgen Appelo is running a big survey to try to identify what Agile practices actually get used.
I like the idea of the survey because I've often wondered how much real pair programming actually occurs. I've never run into it personally, nor have I run into someone who had done it.
Mostly, I wonder how many implementations match what I read to be the definitive way to do it: 2 coders partnering, then switching partners, and thus tasks, every 4 hours. Everyday, a coder would have 2 partners and up to 2 tasks. I believe I read this in Robert Martin's Agile Principles, Patterns, and Practices (one of the best programming books I've ever read), though I could be wrong. 2 partners and 2 tasks everyday seems crazy to me.
Unfortunately, after taking the survey, it doesn't seem like I will get a good answer to my question, as the questions are not that granular. I will note, however, that pair programming seems to have one of the lowest adoption rates among the well-known, often-mentioned Agile practices (e.g., user stories, scrum, TDD, etc.)
But that's okay, it's still useful to take the survey, so go ahead.
I like the idea of the survey because I've often wondered how much real pair programming actually occurs. I've never run into it personally, nor have I run into someone who had done it.
Mostly, I wonder how many implementations match what I read to be the definitive way to do it: 2 coders partnering, then switching partners, and thus tasks, every 4 hours. Everyday, a coder would have 2 partners and up to 2 tasks. I believe I read this in Robert Martin's Agile Principles, Patterns, and Practices (one of the best programming books I've ever read), though I could be wrong. 2 partners and 2 tasks everyday seems crazy to me.
Unfortunately, after taking the survey, it doesn't seem like I will get a good answer to my question, as the questions are not that granular. I will note, however, that pair programming seems to have one of the lowest adoption rates among the well-known, often-mentioned Agile practices (e.g., user stories, scrum, TDD, etc.)
But that's okay, it's still useful to take the survey, so go ahead.
Monday, April 20, 2009
Make it easy
When I started graduate school, I could do about 12 laps. Yesterday, after almost 3 years, I swam a mile for the first time: 32 laps. As you might imagine, it took lots of work, and regular "practice", 2 or 3 times a week.
This might paint a picture of me as a very driven person or someone very conscientious about healthy living, but the fact is, I had help from external forces: free use of the pool for students, availability of the pool during late hours, cheap locker rental and towel usage fees.
Take away even one of those factors, and it's likely I wouldn't have done it.
Many times as development managers, we like to create laws that result in good code. "Check in all your code immediately, create unit tests first, indent your code" etc.
That's fine, as far as it goes, and then the second thing that has to happen is the manager needs to make it as easy as possible to obey.
I find agile methods help in this area. An experienced developer, who already believes, can set up the continuous build environment or create the TDD base modules. The others, who need coaxing along, can then participate with little, or at least much reduced, effort.
Management tools include the carrot and the stick, but for "good health" processes and admin, I suggest taking the time to make it easy.
This might paint a picture of me as a very driven person or someone very conscientious about healthy living, but the fact is, I had help from external forces: free use of the pool for students, availability of the pool during late hours, cheap locker rental and towel usage fees.
Take away even one of those factors, and it's likely I wouldn't have done it.
Many times as development managers, we like to create laws that result in good code. "Check in all your code immediately, create unit tests first, indent your code" etc.
That's fine, as far as it goes, and then the second thing that has to happen is the manager needs to make it as easy as possible to obey.
I find agile methods help in this area. An experienced developer, who already believes, can set up the continuous build environment or create the TDD base modules. The others, who need coaxing along, can then participate with little, or at least much reduced, effort.
Management tools include the carrot and the stick, but for "good health" processes and admin, I suggest taking the time to make it easy.
Friday, April 17, 2009
Estimations and deadlines
One critical division between mid-level coders and seniors coders: willingness to set a deadline for themselves.
"When do you think you'll have that done?"
Senior developer: "Next Friday, assuming there's no surprises with the vendor feed."
Junior or mid-level developer: "Um, I don't know yet."
I understand the reluctance to give a date. I understand that unexpected problems arise. I also understand that managers often try to hold you to your date, even if it's a "wild guess."
Here's the deal though:
1. Your manager should help you create more time if you need it.
2. The more skilled you are, the better able you are to anticipate currently unknown but potential problems, and build that into your time.
3. The more skilled you are, the better able you are to articulate what potential delays might occur such that your users, fellow developers, and manager understand why you're saying the work will take two weeks instead of one.
4. The more skilled you are, the more likely you are to give deadlines that you can meet or beat most of the time.
Don't fall into the trap of believing that being clever enough to wiggle out of giving a due date is a skill that shows your experience. In fact, the opposite is true: strong developers give dates.
"When do you think you'll have that done?"
Senior developer: "Next Friday, assuming there's no surprises with the vendor feed."
Junior or mid-level developer: "Um, I don't know yet."
I understand the reluctance to give a date. I understand that unexpected problems arise. I also understand that managers often try to hold you to your date, even if it's a "wild guess."
Here's the deal though:
1. Your manager should help you create more time if you need it.
2. The more skilled you are, the better able you are to anticipate currently unknown but potential problems, and build that into your time.
3. The more skilled you are, the better able you are to articulate what potential delays might occur such that your users, fellow developers, and manager understand why you're saying the work will take two weeks instead of one.
4. The more skilled you are, the more likely you are to give deadlines that you can meet or beat most of the time.
Don't fall into the trap of believing that being clever enough to wiggle out of giving a due date is a skill that shows your experience. In fact, the opposite is true: strong developers give dates.
Wednesday, April 15, 2009
Job losses
A friend pointed out a verbal fight that broke out at a financial firm. The head of the division has an internal blog, on which he wrote something like "as widely reported, additional job losses will be coming in the next few weeks".
Many people commented on the blog. One person took great umbrage at the word "job losses". Her point was that losses are accidental, mistakes. Because the head of the division was directly responsible for cutting staff, and, as a senior executive, possibly involved with the strategies that led to the debacle that led to the need to cut staff, she felt he was trying to use language to wiggle out of any responsibility. (I can't help but note her "bravery," since her name was posted next to her comment.)
I do have some sympathy for the executive. I think the tone he attempted to convey was the seriousness of the situation. You might say, "I'm sorry for your loss" at a funeral, and the emotions at the firm are funereal.
On the other hand, the whole language around layoffs has gotten far too soft and annoying.
When I started my career, companies regularly called layoffs either layoffs or terminations. Laid off employees regularly stated, "I was fired." If you wanted to be doubly sure no one thought you got canned for cause, you said, "I was laid off."
Since then, execu-speak has gone wild. In the late 80s, we started calling it "downsizing" or "trimming". This parallels the time when workers stopped being people and became "human resources". Later "right-sizing" tried to replace "downsizing", but thankfully failed. Around the turn of the century, "cutting" or "reducing headcount" dominated.
The one I hate the most is "redundancies". To me, the word is a joke. Redundancies occur when two firms merge; as a result, some people are laid off. At some point in just the past few years, it became applicable to all layoffs. If a company decides to cancel a product line and lays off the 500 employees that worked on it, they'll say they had 500 redundancies. Redundancy means you had 2, so you got rid of 1. In these cases, they're left with 0.
The old words remain, but the new words become widely adopted. They seem softer and, because they're impersonal, you can say them without feeling insensitive. And, I do believe that much of their appeal comes from the fact that it indicates that the executive who makes the decision had no responsibility in the matter.
The woman's real message is: if you're going to fire people, own up to it. Hear, hear! Being so wiggly about it can be, in itself, a form of insensitivity.
Many people commented on the blog. One person took great umbrage at the word "job losses". Her point was that losses are accidental, mistakes. Because the head of the division was directly responsible for cutting staff, and, as a senior executive, possibly involved with the strategies that led to the debacle that led to the need to cut staff, she felt he was trying to use language to wiggle out of any responsibility. (I can't help but note her "bravery," since her name was posted next to her comment.)
I do have some sympathy for the executive. I think the tone he attempted to convey was the seriousness of the situation. You might say, "I'm sorry for your loss" at a funeral, and the emotions at the firm are funereal.
On the other hand, the whole language around layoffs has gotten far too soft and annoying.
When I started my career, companies regularly called layoffs either layoffs or terminations. Laid off employees regularly stated, "I was fired." If you wanted to be doubly sure no one thought you got canned for cause, you said, "I was laid off."
Since then, execu-speak has gone wild. In the late 80s, we started calling it "downsizing" or "trimming". This parallels the time when workers stopped being people and became "human resources". Later "right-sizing" tried to replace "downsizing", but thankfully failed. Around the turn of the century, "cutting" or "reducing headcount" dominated.
The one I hate the most is "redundancies". To me, the word is a joke. Redundancies occur when two firms merge; as a result, some people are laid off. At some point in just the past few years, it became applicable to all layoffs. If a company decides to cancel a product line and lays off the 500 employees that worked on it, they'll say they had 500 redundancies. Redundancy means you had 2, so you got rid of 1. In these cases, they're left with 0.
The old words remain, but the new words become widely adopted. They seem softer and, because they're impersonal, you can say them without feeling insensitive. And, I do believe that much of their appeal comes from the fact that it indicates that the executive who makes the decision had no responsibility in the matter.
The woman's real message is: if you're going to fire people, own up to it. Hear, hear! Being so wiggly about it can be, in itself, a form of insensitivity.
Tuesday, April 14, 2009
Making Things Happen by Scott Berkun
I basically picked it up Scott Berkun's Making Things Happen because I enjoy Scott's blog, and some other writers had good things to say about the book. When I started reading I couldn't understand the hype. How did this get a second edition?After a while, I realized the book shouldn't be read cover to cover. Or, rather, that's only part of its value.
It has a second use as a desk reference for all those problems that a project manager or team lead might run into, almost like an encyclopedia. He covers items big and small, over an extremely wide range, such as:
- What's the best way to run a meeting?
- What should you do if you've tried everything and you can't get someone to respond to your request?
- How can you improve your decision making?
- What's the best course of action if you're the new PM on a project and the Coder Who Knows Everything seems disrespectful of you?
- What options do you have if higher-ups require the team to follow processes that you disagree with or the team hates?
- Are work politics evil?
In the end, the breadth of the material, delivered succinctly but with personality, impressed me. The book offers a comprehensive list of real-life issues and strategies.
New managers could read the whole thing and use it as an initial template, weeding out what doesn't work for them. More experienced managers can dip into it when needing guidance on a particularly thorny project.
Making It Happen is a practical guide for project success.
Monday, April 13, 2009
Give the country singer the writing tasks
I'm still watching Celebrity Apprentice. In fact, it's the only show I watch -- not because it's the best show on, but it comes on at a convenient time for me, and after following a show for a while, it's more interesting.
The show offers numerous examples of bad project management on a weekly basis. Donald Trump may be the worst manager I've ever seen.
One trend I noticed: Almost every week, someone says something like, "I hate [Bob]. He's a useless slacker and an idiot." This usually happens on the team that loses. Then, the next week, Bob will be a shining star, usually if that team wins.
The key to a contestant's output almost always revolves around the task(s) they're given. Did they understand what's expected of them? Did they feel the task utilizes their skills? Did they understand the value of it? Did they feel they could contribute more? In many cases, contestants weren't even assigned tasks.
Country singer Clint Black pisses people off regularly, but this week, everyone loved his ideas involving clever text snippets. Herschel Walker alternates between being non-existent to highly useful, depending on how straightforward the work is. As a counter example, Jesse James, of West Coast Choppers fame, makes heavy contributions in design and marketing, but this week he held back valuable donors from his team (so that he could save them for his own use).
That guy on your team who you hate because you think he's selfish, a slacker, and an idiot? If you're the project manager, maybe that's your fault.
The show offers numerous examples of bad project management on a weekly basis. Donald Trump may be the worst manager I've ever seen.
One trend I noticed: Almost every week, someone says something like, "I hate [Bob]. He's a useless slacker and an idiot." This usually happens on the team that loses. Then, the next week, Bob will be a shining star, usually if that team wins.
The key to a contestant's output almost always revolves around the task(s) they're given. Did they understand what's expected of them? Did they feel the task utilizes their skills? Did they understand the value of it? Did they feel they could contribute more? In many cases, contestants weren't even assigned tasks.
Country singer Clint Black pisses people off regularly, but this week, everyone loved his ideas involving clever text snippets. Herschel Walker alternates between being non-existent to highly useful, depending on how straightforward the work is. As a counter example, Jesse James, of West Coast Choppers fame, makes heavy contributions in design and marketing, but this week he held back valuable donors from his team (so that he could save them for his own use).
That guy on your team who you hate because you think he's selfish, a slacker, and an idiot? If you're the project manager, maybe that's your fault.
Thursday, April 9, 2009
So influence me already!
Personal note: I have to admit, my job over the past several months has been a challenge.
For the past several years, I ran teams of various sizes, 4 - 16 people. But, since a major change last year, no one has reported to me. Everyone that I worked with reported to someone else. My role, on several projects, has been basically that of an "advisor". I was expected to have expertise, and to utilize that expertise in these projects to help guide them to success.
In other words, I generated my own responsibilities. My job was to identify work that needed to be done, and then convince others. If they agreed, they committed their own time or that of team members; if not, they could just ignore me.
My responsibilities have thus been entirely about influencing others. It's a role that requires my active effort. As with a lot of coders, my first instinct is to identify something that needs to be done and then just do it myself.
Once, on a big testing day, I felt we needed a central command point. I wasn't sure why. But, I arranged for an all-day open conference line, and told people I'd just wait there in case issues came up. Then I sat on the call, not really sure if anyone would need it. Over the course of the day, many people popped in and out, and we resolved a lot of problems quickly.
All of this has convinced me that managing requires fewer direct commands and more persuasion, motivation, selling -- various manners of putting oneself out in public in a vulnerable way. By this demonstration of beliefs in action, one can influence others. That's really what the game of management is about.
For the past several years, I ran teams of various sizes, 4 - 16 people. But, since a major change last year, no one has reported to me. Everyone that I worked with reported to someone else. My role, on several projects, has been basically that of an "advisor". I was expected to have expertise, and to utilize that expertise in these projects to help guide them to success.
In other words, I generated my own responsibilities. My job was to identify work that needed to be done, and then convince others. If they agreed, they committed their own time or that of team members; if not, they could just ignore me.
My responsibilities have thus been entirely about influencing others. It's a role that requires my active effort. As with a lot of coders, my first instinct is to identify something that needs to be done and then just do it myself.
Once, on a big testing day, I felt we needed a central command point. I wasn't sure why. But, I arranged for an all-day open conference line, and told people I'd just wait there in case issues came up. Then I sat on the call, not really sure if anyone would need it. Over the course of the day, many people popped in and out, and we resolved a lot of problems quickly.
All of this has convinced me that managing requires fewer direct commands and more persuasion, motivation, selling -- various manners of putting oneself out in public in a vulnerable way. By this demonstration of beliefs in action, one can influence others. That's really what the game of management is about.
Wednesday, April 8, 2009
How compensation can be strategic
Every company pays people. How strategic can it be?
One strategy: pay everyone a lot of money. In theory, money buys the best talent. In practice, it may just buy expensive talent. What kind of people does a company with huge pockets attract? (And don't forget: Amazon.com's Jeff Bezos says frugality helps to drive innovation. For my money, Amazon.com is the most innovative large company today.)
Lots of Wall Street firms have paid lavishly for short term results. What kind of behavior did such a pay system encourage?
Many companies just pay people the going rate when they're hired, and then hope to keep raises down. Eventually, current workers can earn more money by quitting and applying for the open positions. What kind of people stay at a company that pays them less than new hires, who know less than they do?
As I've written about before, a system like Fog Creek's tries very hard to signal that merit will drive all pay, by being as explicit as possible about the differences between levels. Everyone makes the same as everyone else who works at the same level. What kind of incentives are created when a company focuses so intently on merit?
At companies like Google, the differences in levels may not be as specific, but in order to get to the next one, employees have to "apply" for it. This involves writing a resume and gathering letters of recommendations from others in the firm. Anyone can nominate themselves, and one's manager cannot prevent it. What kind of message does the company send to its employees about who is responsible for their career? What kind of people would be attracted to such a system?
In the end, a company's strategy relies on having the right people to identify, develop, and execute it. To tweak an old saying, a company full of guys carrying hammers will see everything as a nail. A company's compensation system attracts people with certain tools in their toolkit.
One strategy: pay everyone a lot of money. In theory, money buys the best talent. In practice, it may just buy expensive talent. What kind of people does a company with huge pockets attract? (And don't forget: Amazon.com's Jeff Bezos says frugality helps to drive innovation. For my money, Amazon.com is the most innovative large company today.)
Lots of Wall Street firms have paid lavishly for short term results. What kind of behavior did such a pay system encourage?
Many companies just pay people the going rate when they're hired, and then hope to keep raises down. Eventually, current workers can earn more money by quitting and applying for the open positions. What kind of people stay at a company that pays them less than new hires, who know less than they do?
As I've written about before, a system like Fog Creek's tries very hard to signal that merit will drive all pay, by being as explicit as possible about the differences between levels. Everyone makes the same as everyone else who works at the same level. What kind of incentives are created when a company focuses so intently on merit?
At companies like Google, the differences in levels may not be as specific, but in order to get to the next one, employees have to "apply" for it. This involves writing a resume and gathering letters of recommendations from others in the firm. Anyone can nominate themselves, and one's manager cannot prevent it. What kind of message does the company send to its employees about who is responsible for their career? What kind of people would be attracted to such a system?
In the end, a company's strategy relies on having the right people to identify, develop, and execute it. To tweak an old saying, a company full of guys carrying hammers will see everything as a nail. A company's compensation system attracts people with certain tools in their toolkit.
Saturday, April 4, 2009
Big companies with few compensation levels?
In my last post on Fog Creek's 9 compensation levels (everyone in the company makes one of 9 numbers), I said that a bigger company would require more levels, which complicates the whole matter.
What about big companies that seem to defy this rule? Goldman, Sachs, for example, proudly has only about 3 titles. Google is another big company with a flat hierarchy. Both companies are hugely successful.
If a company grows but keep only a few number of levels, then it needs to offer big bonuses. Big bonuses are a back door way to differentiate compensation while maintaining a simple base structure.
Goldman, Sachs has done this for years; there aren't many promotions, but bonuses vary wildly. Google provides big bonuses through stock options.
Joel alludes to "a generous profit-sharing plan", but offers no other details. Does everyone get the same share of the profit? Or everyone at the same level? If not, are the bonus numbers still made public like the salaries? How does the size of the bonuses compare to base compensation? Answers to these questions make all the difference.
Then, the bigger question remains: what happens when profits slow down? If the company is bonus dependent, sometimes looked like an "incredible company culture" disappears along with the profits, and just as quickly. GS is about to find out; super-sized paychecks have gone the same way as trans fats at McDonald's. Google is about to find out; while they already repriced everyone's underwater options, stock market doldrums means compensation will basically be declining.
When the bonus pool runs dry, people start wanting more explicit ways to estimate their annual income, and managers need new tools to differentiate the strong from the weak. All of which means more compensation levels.
What about big companies that seem to defy this rule? Goldman, Sachs, for example, proudly has only about 3 titles. Google is another big company with a flat hierarchy. Both companies are hugely successful.
If a company grows but keep only a few number of levels, then it needs to offer big bonuses. Big bonuses are a back door way to differentiate compensation while maintaining a simple base structure.
Goldman, Sachs has done this for years; there aren't many promotions, but bonuses vary wildly. Google provides big bonuses through stock options.
Joel alludes to "a generous profit-sharing plan", but offers no other details. Does everyone get the same share of the profit? Or everyone at the same level? If not, are the bonus numbers still made public like the salaries? How does the size of the bonuses compare to base compensation? Answers to these questions make all the difference.
Then, the bigger question remains: what happens when profits slow down? If the company is bonus dependent, sometimes looked like an "incredible company culture" disappears along with the profits, and just as quickly. GS is about to find out; super-sized paychecks have gone the same way as trans fats at McDonald's. Google is about to find out; while they already repriced everyone's underwater options, stock market doldrums means compensation will basically be declining.
When the bonus pool runs dry, people start wanting more explicit ways to estimate their annual income, and managers need new tools to differentiate the strong from the weak. All of which means more compensation levels.
How to get paid at Fog Creek
Joel Spolsky shared his company's compensation system in one of the "serious" April Fool's Day posts:
Compensation is one of the critical levers that contribute to the culture of a company. At the same time, the culture of a company will greatly affect how compensation gets interpreted. Different sized companies with different cultures in different industries need different compensation systems. There's no one right answer.
Joel has clearly thought a lot about what he wants compensation to say about and how he wants it to affect his company. That, in itself, is at least half the battle.
The best part of Joel's system is that it prevents newcomers from making more money than the existing employees, which I see all the time. Most companies I've worked for just hire people, and rising market prices force salaries higher for the last one in the door -- even if people that already work there have equal skills, not to mention that they already understand the specific intricacies of the application and company processes.
Another underlying principle of Joel's system is to make everything transparent, so that everyone understands how their compensation is set. Lack of objectivity (or just the perception of it) really angers employees, either killing their motivation or resulting in their departure.
His system also removes favoritism, or at least discourages it by forcing it out to the open.
Two things prevent this structure from being more widely adopted:
In Fog Creek's system, every employee is assigned a level. Currently, these levels range from 8 (for a summer intern) to 16 (for me). Your level is calculated formulaically based on three factors: experience, scope of responsibility, and skill set. Once we determine your number, you make the same as every other employee at that level.I always appreciate companies that try new compensation schemes, and even more if they share it with the world.
Compensation is one of the critical levers that contribute to the culture of a company. At the same time, the culture of a company will greatly affect how compensation gets interpreted. Different sized companies with different cultures in different industries need different compensation systems. There's no one right answer.
Joel has clearly thought a lot about what he wants compensation to say about and how he wants it to affect his company. That, in itself, is at least half the battle.
The best part of Joel's system is that it prevents newcomers from making more money than the existing employees, which I see all the time. Most companies I've worked for just hire people, and rising market prices force salaries higher for the last one in the door -- even if people that already work there have equal skills, not to mention that they already understand the specific intricacies of the application and company processes.
Another underlying principle of Joel's system is to make everything transparent, so that everyone understands how their compensation is set. Lack of objectivity (or just the perception of it) really angers employees, either killing their motivation or resulting in their departure.
His system also removes favoritism, or at least discourages it by forcing it out to the open.
Two things prevent this structure from being more widely adopted:
- Small companies usually spend little time thinking about organizational issues. They're completely focused on staying alive by developing new product and new customers. But that's a bit like not implementing daily builds or automated testing because the focus is on writing new code.
- As a company grows larger, it requires increasing numbers of levels. Fog Creek currently has 9 different salaries in any given year. Given that they probably have less than 200 people, they might have 25 people in a level. Now imagine they have 2,000 people, resulting in over 250 people in some levels. The range of skills at each level will vary much greater; i.e., Ann, a level 11 who just missed getting level 12, will be closer in skill and contribution to Bob, who just barely made level 12, than to Clark, who just barely made level 11. The problem with having more buckets, though, is that in makes the gradations harder to define in a simple chart like Fog Creek's.
Wednesday, April 1, 2009
No kidding
April Fool's Day means some serious posts get dismissed as jokes, while joke posts receive serious attention. The world has enough opinions, running the full spectrum, that it can be difficult to tell. Good fun!
Tuesday, March 31, 2009
Is software evil?
Michael Osinski compares his creation -- software that enabled the creation and selling of complex mortgage products -- to another "evil engineering" feat, The Manhattan Project.
It remains far short of the old Manhattan Project though on the evil scale. A better metaphor would be the creation of some math formulas that the engineers used in the Manhattan Project. The toxicity resides in the product, not so much in the tool that created the product.
But, still I find the question intriguing: should software engineers consider the ethical ramifications of their work?
Would you have any problems being hired to write software that:
Also, somewhere between the first and the last, everyone finds a line that they wouldn't cross (or at least think they wouldn't).
Think about the application you work on. Could someone likely be hurt by it? Is it likely to be used for illegal purposes? Should you care?
I have been called the devil by strangers and “the Facilitator” by friends. It’s not uncommon for people, when I tell them what I used to do, to ask if I feel guilty.Osinski claims his software, Intex, dominates all the investment bank mortgage departments, and I can confirm that my investment bank used and continues to use it. So, Intex certainly played a role in the financial crisis.
It remains far short of the old Manhattan Project though on the evil scale. A better metaphor would be the creation of some math formulas that the engineers used in the Manhattan Project. The toxicity resides in the product, not so much in the tool that created the product.
But, still I find the question intriguing: should software engineers consider the ethical ramifications of their work?
Would you have any problems being hired to write software that:
- recorded key entries and mouse clicks without the user's knowledge?
- tracked people's on-line browsing behavior without their knowledge?
- breaks passwords through repeated guess submissions?
- connected adults looking to cheat on their spouses?
- scanned public email of all Americans, not just those suspected of illicit behavior?
- simply stored and queried the data from the database of public email?
- infiltrated government servers and stole political information, such as GhostNet?
- disabled thousands of servers, i.e., a worm or virus?
- stole money from people's checking accounts?
Also, somewhere between the first and the last, everyone finds a line that they wouldn't cross (or at least think they wouldn't).
Think about the application you work on. Could someone likely be hurt by it? Is it likely to be used for illegal purposes? Should you care?
Monday, March 30, 2009
Better software through connecting
This past weekend, I went to the dreaded DMV -- Dept of Motor Vehicles. If any government agency brings forth horrifying images of incompetence, bureaucracy, and disaffected employees, it's the DMV. Even though I was just renewing my license, I took a huge book, in preparation for long waits and lines.
I never even cracked the book. I was in and out within 15 minutes.
Actually, I can't remember ever having a bad experience at the DMV. Mediocre, maybe, but not bad. Yet, the imagery persists in my mind, and I would guess most people's.
I was thinking about this because it seems like a large percentage of IT shops have similar reputations. They do decent work, pump out a good share of deliverables, chip away at the list of problems. Yet, they are perceived as slow, lazy, and second-rate.
Some problems are about basic management, all of which practices like Agile addresses: expectation setting, progress tracking, frequent user feedback, quick error identification.
But, it's often not a competence issue. At the DMV, where things were effective enough, what I noticed is that none of the employees seemed happy. Occasionally, you'd see them joke with each other, but the customers were like fish they had to process. All interactions were perfunctory, not personal.
Government agencies don't have a lot of leeway to show personality, but there's no real excuse for a software dev team.
No matter how good your applications are, a weak relationship with your users will doom you to a negative or, at best, mediocre reputation.
If your users work in the same building or nearby, one of your primary jobs is to get physically in front of them regularly. Daily is about the right frequency, for every person on the dev team from the intern to the manager. Ask how things are going. Get to know them as people. Connect.
As technical people, we often focus on the technical specifics that our users request. We neglect the personal aspect of the job. Yet, the definition of a service is that it's personal. The products get outsourced.
It costs nothing to be friendly and engaged with your users. The payoff is that your apps will be better, even if they're the same.
I never even cracked the book. I was in and out within 15 minutes.
Actually, I can't remember ever having a bad experience at the DMV. Mediocre, maybe, but not bad. Yet, the imagery persists in my mind, and I would guess most people's.
I was thinking about this because it seems like a large percentage of IT shops have similar reputations. They do decent work, pump out a good share of deliverables, chip away at the list of problems. Yet, they are perceived as slow, lazy, and second-rate.
Some problems are about basic management, all of which practices like Agile addresses: expectation setting, progress tracking, frequent user feedback, quick error identification.
But, it's often not a competence issue. At the DMV, where things were effective enough, what I noticed is that none of the employees seemed happy. Occasionally, you'd see them joke with each other, but the customers were like fish they had to process. All interactions were perfunctory, not personal.
Government agencies don't have a lot of leeway to show personality, but there's no real excuse for a software dev team.
No matter how good your applications are, a weak relationship with your users will doom you to a negative or, at best, mediocre reputation.
If your users work in the same building or nearby, one of your primary jobs is to get physically in front of them regularly. Daily is about the right frequency, for every person on the dev team from the intern to the manager. Ask how things are going. Get to know them as people. Connect.
As technical people, we often focus on the technical specifics that our users request. We neglect the personal aspect of the job. Yet, the definition of a service is that it's personal. The products get outsourced.
It costs nothing to be friendly and engaged with your users. The payoff is that your apps will be better, even if they're the same.
Friday, March 27, 2009
7 things that make a good manager
My manager being out on jury duty has led me to continue to muse about what makes a good manager. I'm thinking about it in terms of software teams, which means managers on car production lines could be very different.
I figure I've had about 20 jobs in my life, starting with the afternoon paper route I took on when I was 10. So, I must have had around 30 direct managers during that time. Surprisingly, I can only think of one or two that I absolutely could not work with. Of course, some were mediocre, but still had valuable good qualities. Several have been outstanding. Perhaps I have been lucky.
Here's my list of the most important things that a manager does, in order:
1. creates an environment that enables you to succeed. This can include both positive attributes (e.g., gives you enough authority to make the decisions that you need to, provides access to the required resources) and negative (e.g., beats back and filters scope changes and new requests, shields you from the political noise).
2. challenges you with "stretch" assignments in new areas. This could be new technology, leadership, or new responsibilities. In any case, you face the requirement to develop new skills, and that keeps it interesting. Of course, you have to be ready for it, and a good manager knows how far to stretch you.
3. ensures you are properly rewarded for your efforts. Many developers I've worked with have a difficult time asking for a raise or expressing their desire to be promoted. A good manager takes care of that and fights hard to get you recognized, while you are toiling away behind the scenes, away from the spotlight.
Both 2 and 3 are really flip sides of the same coin: motivation. There are numerous ways to motivate people, but they essentially boil down to personal development or public recognition. Everyone wants both, but everyone also has priorities, so some people will prefer 2 to 3, and others the reverse.
4. mentors and teaches. I have really appreciated managers that were vastly better than me, and I loved to step back and watch them work. The great ones explained their methods, identified areas where I could improve, and presented these issues to me in a way that encouraged me to do better -- as opposed to feeling worse and inadequate.
5. provides vision. At the "worker bee" level, it can be hard to see where the department is heading, much less the company. You might feel your efforts are Sisyphean, pointless. A good manager provides strategic direction and explains how your efforts contribute to that, while maintaining honesty and authenticity.
6. organizes the team to encourage interaction. Your co-workers represent your best learning opportunities. A group that works together will be more powerful than a bunch of individuals pursuing their own goals. Frequent and positive interactions often require the right structure or the right incentives to encourage them.
7. acts as a friend. Some people have told me they didn't want to be too "chummy" with their workers out of fear that they wouldn't get the respect they needed on the job. I've never understood this. I consider myself friends with all of the best managers I've had -- people I would want to invite to my sister's wedding. I maintain that it's always easier to work with people that you have a friendly rapport with than those you have only a business relationship with. Especially in software development, respect comes from being effective, useful, and knowledgeable, not from having a commanding personality.
I figure I've had about 20 jobs in my life, starting with the afternoon paper route I took on when I was 10. So, I must have had around 30 direct managers during that time. Surprisingly, I can only think of one or two that I absolutely could not work with. Of course, some were mediocre, but still had valuable good qualities. Several have been outstanding. Perhaps I have been lucky.
Here's my list of the most important things that a manager does, in order:
1. creates an environment that enables you to succeed. This can include both positive attributes (e.g., gives you enough authority to make the decisions that you need to, provides access to the required resources) and negative (e.g., beats back and filters scope changes and new requests, shields you from the political noise).
2. challenges you with "stretch" assignments in new areas. This could be new technology, leadership, or new responsibilities. In any case, you face the requirement to develop new skills, and that keeps it interesting. Of course, you have to be ready for it, and a good manager knows how far to stretch you.
3. ensures you are properly rewarded for your efforts. Many developers I've worked with have a difficult time asking for a raise or expressing their desire to be promoted. A good manager takes care of that and fights hard to get you recognized, while you are toiling away behind the scenes, away from the spotlight.
Both 2 and 3 are really flip sides of the same coin: motivation. There are numerous ways to motivate people, but they essentially boil down to personal development or public recognition. Everyone wants both, but everyone also has priorities, so some people will prefer 2 to 3, and others the reverse.
4. mentors and teaches. I have really appreciated managers that were vastly better than me, and I loved to step back and watch them work. The great ones explained their methods, identified areas where I could improve, and presented these issues to me in a way that encouraged me to do better -- as opposed to feeling worse and inadequate.
5. provides vision. At the "worker bee" level, it can be hard to see where the department is heading, much less the company. You might feel your efforts are Sisyphean, pointless. A good manager provides strategic direction and explains how your efforts contribute to that, while maintaining honesty and authenticity.
6. organizes the team to encourage interaction. Your co-workers represent your best learning opportunities. A group that works together will be more powerful than a bunch of individuals pursuing their own goals. Frequent and positive interactions often require the right structure or the right incentives to encourage them.
7. acts as a friend. Some people have told me they didn't want to be too "chummy" with their workers out of fear that they wouldn't get the respect they needed on the job. I've never understood this. I consider myself friends with all of the best managers I've had -- people I would want to invite to my sister's wedding. I maintain that it's always easier to work with people that you have a friendly rapport with than those you have only a business relationship with. Especially in software development, respect comes from being effective, useful, and knowledgeable, not from having a commanding personality.
Wednesday, March 25, 2009
Software development as group activity
The stereotype of a software developer is a kind of loner cowboy who gets the job done.
What bugs me about this is that, occasionally, a developer will create something from scratch that the guy in the next cube built a couple years ago. Or the implementation will be ill-conceived, even though the best architect sits no farther than a paper airplane could fly.
This makes me appreciate Agile development. I find it gets developers talking, even if it's simply an extended version of, "I'll do this, you do that." Developers who talk about their work are more likely to generate new ideas or solve problems effectively.
Teams are powerful.
In my experience, the basic tenets of Agile development -- e.g., daily scrum, rapid iterations, burndown, backlog -- together provide a useful scaffolding for getting individuals to work as a team. The first time I got all the pieces working, I was actually amazed at how the team took off on its own. The individual parts of Agile practices actually serve as a metaphor for a team: each part can be ineffective by itself, but together they become very powerful.
I only wish for better alternatives to pair programming. The guidelines for pair programming seem oppressive -- switching pairs every 4 hours! I haven't yet met anyone who actually does it as specified, and I haven't been courageous enough to try it myself (nor strong enough to convince any of my bosses).
But I definitely like the idea of getting programmers to work even closer together.
Jeff Atwood mentioned a very clever idea (which he apparently had 4 years ago) for how to screen for developers who will be more inclined to work with others:
What bugs me about this is that, occasionally, a developer will create something from scratch that the guy in the next cube built a couple years ago. Or the implementation will be ill-conceived, even though the best architect sits no farther than a paper airplane could fly.
This makes me appreciate Agile development. I find it gets developers talking, even if it's simply an extended version of, "I'll do this, you do that." Developers who talk about their work are more likely to generate new ideas or solve problems effectively.
Teams are powerful.
In my experience, the basic tenets of Agile development -- e.g., daily scrum, rapid iterations, burndown, backlog -- together provide a useful scaffolding for getting individuals to work as a team. The first time I got all the pieces working, I was actually amazed at how the team took off on its own. The individual parts of Agile practices actually serve as a metaphor for a team: each part can be ineffective by itself, but together they become very powerful.
I only wish for better alternatives to pair programming. The guidelines for pair programming seem oppressive -- switching pairs every 4 hours! I haven't yet met anyone who actually does it as specified, and I haven't been courageous enough to try it myself (nor strong enough to convince any of my bosses).
But I definitely like the idea of getting programmers to work even closer together.
Jeff Atwood mentioned a very clever idea (which he apparently had 4 years ago) for how to screen for developers who will be more inclined to work with others:
I have my own theory about the ideal way to interview developers: have the candidate give a 10 minute watercooler presentation to your team on something they've worked on. I think this is a far better indicator of success than a traditional interview. You'll quickly ascertain:This is absolutely something I will try.
- Is this person passionate about what they are doing?
- Can they communicate effectively to a small group?
- Do they have a good handle on their area of expertise?
- Would your team enjoy working with this person?
Tuesday, March 24, 2009
Are you a good manager?
One simple measure of your value as an employee: when you say you're taking a few days off, how concerned is your manager?
Does the opposite also hold true? Yes, it's a crude measure, and it's just one, but I think it goes the other way, too.
If you manage people, do you think they're relieved when you're out of the office, or are they worried? Are they more productive, or less?
My boss has jury duty, so she's out for at least a couple days, and possible more. That worries me. Every day that she's out, I get increasingly bogged down by administrivia, "emergency of the hour" fire drills, unfocused and not well considered requests, and thorny problems that don't seem to have good answers. These issues grow until, after a couple weeks, it takes most of my day.
One of the most important jobs of a manager is clearing and filtering impediments, interruptions, and distractions so that the people that work for you can do their jobs. Clearly, my manager does that.
On the other hand, we've all heard of the opposite type, too -- the kind you wish would just leave you alone. The kind that everyone's glad when he's on vacation. I've been fortunate not to have very many of these in long career.
Do you manage people? Which type are you?
Does the opposite also hold true? Yes, it's a crude measure, and it's just one, but I think it goes the other way, too.
If you manage people, do you think they're relieved when you're out of the office, or are they worried? Are they more productive, or less?
My boss has jury duty, so she's out for at least a couple days, and possible more. That worries me. Every day that she's out, I get increasingly bogged down by administrivia, "emergency of the hour" fire drills, unfocused and not well considered requests, and thorny problems that don't seem to have good answers. These issues grow until, after a couple weeks, it takes most of my day.
One of the most important jobs of a manager is clearing and filtering impediments, interruptions, and distractions so that the people that work for you can do their jobs. Clearly, my manager does that.
On the other hand, we've all heard of the opposite type, too -- the kind you wish would just leave you alone. The kind that everyone's glad when he's on vacation. I've been fortunate not to have very many of these in long career.
Do you manage people? Which type are you?
Monday, March 23, 2009
Data hell, part 2
A question came in, What do I mean by data hell exactly? (Presumably from a UI guy :-)
Here are some of the characteristics:
1. duplicate data in multiple tables. Of course, data from one table doesn't match the others -- it never does because that's what happens with duplicate data.
2. no primary keys on tables. How to identify programmatically the exact row that you want? Not easily. Sometimes filters work in the right context -- e.g., "I know know there's only one manager in New Jersey, so I can filter to New Jersey and get the right manager." Painful.
3. columns that act as pseudo-primary keys vary by table, even if it's the same data. For example, every car has a unique license plate. That's the primary key for Table1. Wait, every car also has a VIN. That's the primary key for Table 2. Now join them together. Exactly.
4. the pseudo-primary keys aren't reliable. The column in Table1 that holds license plates has VINs for some rows. The join suggested in #3 to Table2 actually works -- sometimes. When? Hard to say.
5. cross-keys aren't reliable. To solve the problem, VIN is often added to Table1 or license to Table2. If you're really "lucky", as I am, you'll have both in both. Unfortunately, sometimes the two keys are out of sync, as predicted in #1: a car gets in Table1 with the one license and VIN, the VIN matches to a VIN in Table2, but that row in Table2 has a difference license.
6. multiple naming conventions. Can't remember if the column is spelled "licenseNum", "LicenseNum", "license_num" or other variations with "number", "no", etc.? That's because each table has a different variation. Often, a table will be consistent with itself (though often it won't be), but different programmers add new tables and bring their own convention without concern for fitting in.
7. just lots and lots of bad or missing data. Data entry just not happening reliably.
What do you do about it? It depends on how much time you have.
If it's a long project, you painstakingly fix the data in some key tables, make sure the input processes are clean. Then you build out from there, either refactoring tables or fixing data at each point along the way. All the while, you try to fit in other business requests as you can.
Sometimes, the business can't wait, and the requests pile up faster than you can take them off. Your only hope is to hire some good database developers and work like crazy. Keep at least one or two of them away from the firing lines, so they can fix things in the background.
Worst is if it's a short-term project. You might think that, being short-term, that is the easiest. Ride it out until it winds down, right? If you've been an app developer for any amount of time, you know that apps very rarely die. If the app works, someone will find a use for it. But, because it's considered short-term, no funds will be invested. It will go on living like a zombie. The people who keep these things going are real heroes.
Here are some of the characteristics:
1. duplicate data in multiple tables. Of course, data from one table doesn't match the others -- it never does because that's what happens with duplicate data.
2. no primary keys on tables. How to identify programmatically the exact row that you want? Not easily. Sometimes filters work in the right context -- e.g., "I know know there's only one manager in New Jersey, so I can filter to New Jersey and get the right manager." Painful.
3. columns that act as pseudo-primary keys vary by table, even if it's the same data. For example, every car has a unique license plate. That's the primary key for Table1. Wait, every car also has a VIN. That's the primary key for Table 2. Now join them together. Exactly.
4. the pseudo-primary keys aren't reliable. The column in Table1 that holds license plates has VINs for some rows. The join suggested in #3 to Table2 actually works -- sometimes. When? Hard to say.
5. cross-keys aren't reliable. To solve the problem, VIN is often added to Table1 or license to Table2. If you're really "lucky", as I am, you'll have both in both. Unfortunately, sometimes the two keys are out of sync, as predicted in #1: a car gets in Table1 with the one license and VIN, the VIN matches to a VIN in Table2, but that row in Table2 has a difference license.
6. multiple naming conventions. Can't remember if the column is spelled "licenseNum", "LicenseNum", "license_num" or other variations with "number", "no", etc.? That's because each table has a different variation. Often, a table will be consistent with itself (though often it won't be), but different programmers add new tables and bring their own convention without concern for fitting in.
7. just lots and lots of bad or missing data. Data entry just not happening reliably.
What do you do about it? It depends on how much time you have.
If it's a long project, you painstakingly fix the data in some key tables, make sure the input processes are clean. Then you build out from there, either refactoring tables or fixing data at each point along the way. All the while, you try to fit in other business requests as you can.
Sometimes, the business can't wait, and the requests pile up faster than you can take them off. Your only hope is to hire some good database developers and work like crazy. Keep at least one or two of them away from the firing lines, so they can fix things in the background.
Worst is if it's a short-term project. You might think that, being short-term, that is the easiest. Ride it out until it winds down, right? If you've been an app developer for any amount of time, you know that apps very rarely die. If the app works, someone will find a use for it. But, because it's considered short-term, no funds will be invested. It will go on living like a zombie. The people who keep these things going are real heroes.
Thursday, March 19, 2009
I had forgotten what data hell felt like
Now I remember, thanks to the new databases I have inherited!
That is all.
That is all.