Entries Tagged 'Managing Software Developers' ↓

We hired a new QA manager a few weeks ago. He’s a nice guy named Eric and he sits in the cubicle next to mine.

As I was heading out the door the other day he stopped to ask my opinion on a testing approach for a large project his team will begin testing in December. The idea he described is essentially pair testing, along the lines of pair programming, and he mentioned it was a combination of something he did at a previous job and something suggested by our Director of Development, who used to work with Scrum.

Since the project consists of a bunch of applications working together in one ecosystem, it’s going to take a lot of time to run tests on it, and a comparable amount of time just to figure out if the tests are succeeding or failing. The idea is to cut down on QA troubleshooting and data-churning time by having a developer and a tester sit at the same computer and run through tests together.

I’ve read a lot about pair programming but have only done it a handful of times. The concept of pair testing is intriguing because I know how much time our testers spend working on non-testing issues that a developer could likely clear up if they were sitting at the same desk, and I know our code will be more thoroughly tested because of it. That being said, I’m the development lead on the project and I can’t spare a developer for even a few hours right now due to the massive amount of work to do between now and D-day.

It’s quite the conundrum.

The end result: I plan to support the approach on a limited basis until we can measure the benefits and sacrifices that both teams forego to make it work. Obviously we have to get the software written before they can test it, so it will do us no good to pull a developer from a half-finished application to sit with the QA team. But assuming we can eek out the time, something in my gut tells me this is the best way to thoroughly test this beast.

Have you heard of or participated in pair testing? What’s your opinion on whether or not it will benefit both teams (development and QA)?

[ Bookmark this post with del.icio.us (What is del.icio.us?) ]
[ Submit to Slashdot ]

Many of you gasped at the title of this post:

“Become a manager? Has he lost his mind?! I’ll be a coder ’til the day I die!”

I’m not implying that you should give up your coding gloves and step into the ranks of full-time management, but you gain incredible perspective about what makes good and bad developers once you’ve managed a few of them. Even if you never become a full-fledged supervisor, managing a project, being a technical lead, or running your own business are all suitable ways to experience what makes a “better” developer from a different angle.

Before working in software I was a project manager for a large electrical contractor in the bay area. So naturally, when I began my technology career, I quickly moved from writing software to leading projects and managing other developers. Over the next few years I continued to function as a lead/PM until I became the manager of 10 DBAs and developers for the City of Pasadena. And let me tell you, I learned more about what makes a good developer from a management perspective in my short tenure at the City, than in the previous two or three working as a consultant.

Lesson #1: What Makes Someone the Best
One of the first things you’ll learn is who your best developers are and why. And it’s not what you think; often times it’s not the most technically savvy person in a group, rather it’s the one who’s able to make things work with the least amount of management intervention. If you think you have a lot of things to worry about, your manager has to put up with 5 or 10 times more context switches than you do. And when your most critical asset is time, someone who may not be the end-all be-all of personality or technical ability, but who’s able to do a lot of coding without bothering you every few minutes, that developer is worth his weight in platinum.

Lesson #2: It’s Easy to Complain about Your Boss Until You Have to Do His Job
I can’t tell you the shock I felt when I realized for the first time that as a manager the success or failure of a project didn’t rest solely in my hands. The project’s success, and ultimately my success, rested in the hands of programmers whom I had to motivate, work with to ensure they were building the correct software to our development standards, all the while being told by customers and management that we should be doing it faster, for less money, and with less people. It was a horrendous tug-of-war with me in the middle.

In software, as in business, every decision is a compromise. If you’re on the losing end of that compromise it’s easy to complain that the person made a bad decision. For the most part, unless you have an evil boss, she is trying to make the best decisions she can. Trust me, someone who makes a compromise is better than someone who makes no decision at all.

Lesson #3: How to Self-Manage
As a supervisor you can’t get any work done unless your developers learn to be self-sufficient. A large portion of your time should be spent putting out fires (since there are always ample fires to fight), not performing basic developer-related tasks (”For the hundredth time, we use i for our For-Loop variable, not j!”). So as a developer, if you can make something work while bothering your boss even one less time per day, you’re taking a huge burden from his shoulders.

Lesson #4: Do What It Takes to Achieve Results
I’m not an advocate of an unhealthy lifestyle, in fact I’m the guy who takes three week vacations to Africa, but one of the facts of our industry is that there are times when it’s necessary to work overtime. Do what it takes to hit the deadline; don’t make your boss ask you, or worse, order you to stay late. As a developer you can read the writing on the wall and should know well in advance when you need to tell your spouse you’ll be late for dinner.

When it comes time to play, show up and get the job done.

Lesson #5: No Surprises
Surprises are never a good thing in the business world.

I remember being told the day before launch that we weren’t going to hit the deadline. I asked how long they’d known about it and they said a week and a half. Ugh.

If your boss doesn’t require email updates, drop her a 1 or 2 sentence email twice a week letting her know what you did over the last few days and how things are going. I bet it will become standard practice for the entire group. “Pushing” information is a big help when trying to manage many people, and it helps eliminate surprises. Don’t be afraid to share bad news. Bad news in advance is 10-times better than bad news the day everyone else hears about it.

Walk a Mile in My Shoes
Even if you never become a manager, try to walk a mile in your boss’s shoes once in a while. It won’t take long to realize how much you can learn from looking at your job from a different perspective.

[ Bookmark this post with del.icio.us (What is del.icio.us?) ]
[ Submit to Slashdot ]

One of the software architects I work with made a comment the other day that reminded me of something I once said to my dad.

I was working for a large electrical contractor, managing the build-out of our new $6-million corporate headquarters. This was a huge job for a 25-year old, and I was working my butt off trying to keep up with the chaos that is a fast-track construction project.

About two weeks into the project I could already tell who was going to carry their weight and who was going to eat my time like a side order of potato salad. The electrical foreman, while not the most tactful guy, came through on almost all of his promises; when he said something would be done it was done. The architect, although a competent designer, needed two or three reminders before he would send a set of drawings.

After a particularly frustrating day I said to my dad, “It doesn’t take much to be good, you just have to do what you say you’re going to do.” He laughed hysterically, and to this day I smile at the simplicity of that statement.

Whether managing a construction project, developing software, or talking about a new product, just do what you say you’re going to do. If you can accomplish this, people will sing your praises in the hills.

[ Bookmark this post with del.icio.us (What is del.icio.us?) ]
[ Submit to Slashdot ]

Here is an excerpt from my new article:

“The best example of this is a venture funded start-up. Start-ups backed with venture capital are on strict deadlines to reach financial goals or risk having their funding eliminated. As a result they consume new hires with an insatiable hunger, and more than once I’ve seen situations where the development team needs to grow two or three times its size in the span of a few months. If you’re a manager in this situation you’re forced to leave conventional wisdom behind and enter a mode of hiring fast rather than hiring perfection.

Take this not-so hypothetical situation: your current team of 6 developers needs to be at 22 people in 4 months. You have 16 open positions, more than 2.5 times the number of developers on staff, and you need developers who can hit the ground running.

I think I just heard someone scream.”

Read the rest of the article here.

As a rite of passage, every software management author has to give their take on the hiring process (Joel’s, Erik’s, Paul’s). This is mine.

In an ideal world you would take as long as you want to fill a position. This would allow you to be very picky about who you interview and even pickier about who you hire. I’m a staunch supporter of this approach and tend to be a pretty harsh interviewer as a result; at times interviewing 30 or 40 candidates before giving someone the nod.

But sometimes you don’t have the luxury of spending four or five months to fill a position. There may come a time in the life of your company when you’re faced with more job openings than you have developers, and you need to hire people in a hurry.

Hiring Fast
The best example of this is a venture funded start-up. Start-ups backed with venture capital are on strict deadlines to reach financial goals or risk having their funding eliminated. As a result they consume new hires with an insatiable hunger, and more than once I’ve seen situations where the development team needs to grow two or three times its size in the span of a few months. If you’re a manager in this situation you’re forced to leave conventional wisdom behind and enter a mode of hiring fast rather than hiring perfection.

Take this not-so hypothetical situation: your current team of 6 developers needs to be at 22 people in 4 months. You have 16 open positions, more than 2.5 times the number of developers on staff, and you need developers who can hit the ground running.

I think I just heard someone scream.

We could argue all day about the drawbacks to growing a team this quickly, but assume that you’ve been told to hire 16 developers or find yourself a new job (hire or be hired, in other words). Think about it in these terms: any start-up attempting to dominate a rapidly-growing market must take this approach or be consumed by competitors who will.

So the question is: how can we modify the strategies of conventional hiring without throwing them out entirely?

Hiring fast consists of the following steps:

1. Write the Shortest Job Description Ever
2. Skim Resumes Like Crazy
3. Use the Numbers
4. Hold Phone Interviews
5. Finish In-Person

1. Write the Shortest Job Description Ever
Don’t kid yourself, job hunters don’t read long job descriptions. They read bullet points, skip to the required skills section and submit their resume. The shorter your description is, the higher the likelihood you’ve adhered to the single most important tenet of good writing: brevity. A long job description usually means the person writing it doesn’t really know what the candidate will be doing once she’s hired (what I call the kitchen-sink approach). Aside from the Pope, there’s not a job on earth that requires a three page description.

If your description is longer than half a page (three quarters if you use a lot of bullets), revise it.

2. Skim Resumes Like Crazy
Hiring is about playing the numbers; as a manager you’re trying to maximize the chance that the person is going to fit. Since we don’t have time to meet every candidate in person we rely on other means such as resumes and phone interviews to give us a picture of a candidate’s abilities. A resume can get you about 20% of the way, with phone and in-person interviews taking you to 80% (the highest you can get without actually working with someone).

Most managers take resumes too seriously. If you’re spending 15 or 20 minutes reviewing a resume you’re better off spending the time on a phone interview. You can tell a lot more from a conversation than you can from a piece of paper.

Your sole task when reviewing their resume is to decide if the candidate is worth talking to on the phone. You must become fast at skimming resumes; you should be able to evaluate one in 3-5 minutes.

3. Use the Numbers
In his book, Winning, Jack Welch, former CEO of GE, introduced a concept called Differentiation that consists of rating each employee as an A, B, or C according to performance. Intel uses a similar approach. The intent of these scales is to create a common, familiar method of ranking employees. The exact scale is not important; using a consistent metric everyone can understand is the key. In my experience a 10-point scale works best.

My dad has worked in the construction industry since people built skyscrapers out of dirt, and he learned early on how to evaluate electricians. His method is something I call the Rule of Thirds: on a 10-point scale you make money with your 7s, 8s, and 9s, break even with your 4s, 5s, and 6s, and lose money with your 1s, 2s, and 3s. There are no 10s in that list since no one is perfect; the highest possible rating is a 9+.

In every job search there are hires, maybes, and no-hires. Using the Rule of Thirds, 7-9 is a hire, 4-6 is a maybe, and 1-3 is a no-hire.

The only difference between hiring slow and hiring fast is what you do with the maybes; when hiring slow the maybes become nos, when hiring fast you let the maybes proceed to the next round of evaluation. If you’re at the last round (the in-person interview), you should never hire anything less than a 5.

In general, a developer with killer technical ability but so-so people skills is a 7. A developer with fabulous people skills and so-so technical skills is a 6. Someone with the complete package can range from an 8 to 9+.

The key to hiring fast: Always hire 7-9s, never hire 1-4s, and hire as many 5s & 6s as you need until you can find more 7-9s.

4. Hold Phone Interviews
From the time you receive a resume to a scheduled phone interview should be no more than two days. This may sound fast, but it follows from the fact that the best candidates are hired very quickly, if they hit the job market at all. Executing quickly is critical to finding 7s, 8s and 9s.

Phone interviews are the next step of evaluation after reviewing a resume. First round phone interviews should be given by hiring assistants or recruiters and consist of 5-10 short answer technical questions. If the candidate makes it through the first phone interview, call them yourself and ask 10-15 in-depth technical questions. You should keep this call to 20 minutes.

Here are a few tips for this phone call, which is your first real contact with the candidate:

Start with Witty Banter. Psychologists say that 55% of communication is non-verbal. I’ve found that people tend to be very nervous during phone interviews due to the lack of visual cues, and nervous candidates are less likely to give you a true picture of their capabilities. Put them at ease with an introduction and some small-talk, typically relating to something other than work.

Give Them An Outline. Continue with a quick rundown of what to expect during the call. You’re dealing with developers so known, logical steps are helpful.

Ask for Clarification. Next, try to get to the bottom of any ambiguous statements on their resume. This typically involves asking about specific details of their current position, including why they want to leave. Also ask about any outrageous claims or discrepancies.

Ask Technical Questions. Candidates tend to get nervous when answering technical questions so be sure to explain how many questions you’re going to ask and to let them know that you’re not looking to pass or fail them, rather to get an idea of their strengths and weaknesses. Try to stick to more conceptual subjects like architecture and basic programming concepts, as opposed to language specifics.

See If They Have Questions. Since you are their first technical contact with your company they will typically have questions about the size of your team and whether there’s free soda in the lunchroom.

If the candidate is obviously an 8 or better, try to schedule an in-person interview at the end of the call. If not, close the interview and use their 1-10 ranking to decide how to proceed.

6. Finish In-Person
The in-person interview has been discussed in so many articles that I’m not going to beat it to death here. Joel Spolsky’s Guerilla Guide to Interviewing has a good outline for an in-person technical interview. Here are a few of my thoughts:

• Ask a few technical questions that don’t have specific answers and observe how the candidate responds. There are plenty of smart developers, but someone who can translate complex concepts into words is an exception.
• Ask them to write code and watch how they approach the problem. Recursive questions are always fun and help indicate whether or not they understood the things they were taught in their computer science courses.
• Ask any additional technical questions you haven’t covered before now. This is your last chance before making a decision.
• Finally, if you’re at all interested in the candidate, be sure to evangelize your company and answer their questions to the best of your ability. You’re almost to the point where you’re going to make them an offer, so you want to convince them that working anywhere else is a mistake.

Once the interview is complete, use their 1-10 ranking and the Rule of Thirds to help with your hire/no-hire decision, keeping in mind you should never hire less than a 5.

If hiring were easy it wouldn’t be the subject of so many books, articles and seminars. Hiring technical people is extremely challenging, and hiring a whole slew of technical people in a short time can feel like parting the Red Sea. My hope is that this article lends some guidance when you’re forced to hire like a start-up.

“A new developer quits after two weeks. A three-year veteran leaves the company after receiving a 5% raise at his annual review. A project is delivered according to developer estimates but the project manager is fired. An application is built to approved specifications but the client is unhappy. What do all of these situations have in common?

Expectations.”

Read the rest of the article here.

Like a Dilbert cartoon, Paul Vick nails the interactions between project managers and developers in his post How to be a PM at Microsoft.

I laughed out loud more than once.

This reminds me of when I was a consultant and a client decided to add a new feature during a meeting. He asked for an estimate and I told him that it was our policy not to give estimates without being able to sit down and think through a change. He started to get angry and really pushed me for a number so I told him less than two weeks, whcih made him really mad since it was obviously a much smaller change.

My experience with this type of thing is that in a meeting, in front of a lot of people, giving estimates is bad, bad, bad. Even if you’re dead on accurate, if everyone gasps and tells you its too high, you will cave to peer pressure. In the end, we worked through some numbers in the meeting and the client was satisfied, but usually just saying “We don’t give estimates without preparation” is enough to buy you some time.

I leave for Ghana (West Africa) in 48 hours.

Lately, my mind has been filled with thoughts of how a for-profit technology company could be run with social justice as its focus, and along a related line how technology can be used to fight poverty. The reading and writing I’ve done in the past few months has culminated into a new question for me:

What’s the point of technology if we’re not focusing on people?

I don’t mean that we focus on people so we can get more work out of them so we can turn a bigger profit. I mean make people the focus above everything else, even shareholder value. What would that look like?

Stay tuned to hear more.

Here’s an excerpt from my new article, Warning: Bad Specs Hazardous to Productivity:

“So Joe Developer is handed a spec that provides a nice, high-level view of the project and tells him where he needs to end up. He breaks it down into smaller steps, then perhaps into even smaller ones. He takes those tiny steps and begins to translate each one into instructions the machine can understand (aka “writing code”).

Soon after the first or second step he comes upon a task that he can’t easily translate into code. Perhaps it’s a piece of data he needs to display that doesn’t exist in the database, or a conflict emerges that would break existing code if implemented. Not only does he have to stop what he’s doing, but he has to make a phone call, walk to someone’s office, or schedule a meeting in order to get the answers he needs to continue. This is not only a tremendous waste of time in the sense of “he wasn’t at his desk for nine minutes while he asked this question,” but it takes his “flow” and sends it via Pony Express to the other side of the universe.”

Read the complete article here

I was just talking to Keith, a good friend of mine from Sacramento (and the best realtor in town, I might add) and he told me a story about a recent road trip to Oregon.

He and his wife were meeting some friends at a beach house in the middle of nowhere and although they had the address, through a twist of fate they didn’t have directions or a map. Now, in my case I would have hopped onto Google Maps using my new Treo SmartPhone (a used Treo 300 I recently purchased used for $80 on eBay - crazy deal!), but then again there probably wasn’t any cell coverage. Rats!

After driving around for a while they elected to stop at a gas station and ask for directions. The directions included things like “turn off the paved road” and “you’ll have to stop and move some branches to get through this next part,” but with the help of that very nice man they eventually made it to their destination safe and sound.

This tale reminded me of several software projects I’ve worked on.

The Zone
Software developers, by nature and necessity, tend to be focused individuals. To be productive they must slip into a state of intense concentration that most people call “the zone,” but psychologists refer to as “flow.”

By far the most productive time for a programmer is when she’s in the zone, and it can yield three of four times the software (or more, some argue) than when working at her usual pace. Joel Spolsky has covered this many times from many different angles, so I’ll try not to go into too much detail for risk of boring the avid Joel fans (I’m included in that category - see “My Daily Reads” at right).

When in the zone, an algorithm, which is a specific approach to solving a complex problem, become deconstructed into its finest details and sits like a swan, carefully perched in the programmer’s head. As he writes code, the next detail in his mental queue magically surges from his fingertips, instantly translated into the programming language as if it were his native tongue.

These are not conscious steps a developer has to think about or is even aware of, in much the same way an olympic 100 meter runner does not have to think about placing one foot in front of the other; it’s nothing but effortless motion.

The beauty of the zone is the productivity it generates. I’ve personally had 8 hour blocks where I’ve written enormous amounts of software; tasks that would typically take several days to complete.

The curse of the zone is that it’s like a hitting streak; it’s difficult to attain and even harder to hold onto. One distraction can easily bring you out of the zone for 10 minutes or more and may bring you out for the rest of the day. Heck, half the time I’m distracted I wind up checking email, getting some water, and talking to the person in the cube next to me, which pretty much ensures it’s going to take a long time to get back into it.

How Programmers Attack Problems
Since the introduction of the first procedural programming language, ALGOL, in the late 1950s, programmers have been reared to think in small blocks of functionality, also known as functions or subroutines. The process of thinking in small chunks is an easy way to describe and ultimately build a large system that is too complex to understand in its entirety.

As an example, if you hand a programmer a spec that says:

1. Build an e-commerce website

The first thing they will do is break it into smaller pieces, like so:

1. Build a few product pages
2. Build a shopping cart page
3. Build a checkout page that collect address and credit card information
4. And so on…

So Joe Developer is handed a spec that provides a nice, high-level view of the project and tells him where he needs to end up. He breaks it down into smaller steps, then perhaps into even smaller ones. He takes those tiny steps and begins to translate each one into instructions the machine can understand (aka “writing code”).

Soon after the first or second step he comes upon a task that he can’t easily translate into code. Perhaps it’s a piece of data he needs to display that doesn’t exist in the database, or maybe there isn’t enough detail in the spec on how to implement a particular feature.

Not only does he have to stop what he’s doing, but he has to make a phone call, walk to someone’s office, or schedule a meeting in order to get the answers he needs to continue. This is a tremendous waste of time in the sense of “he wasn’t at his desk for nine minutes while he asked this question,” and it also takes his “flow” and sends it via Pony Express to the other side of the universe.

But there is a solution.

Have Your Best People Write Your Specs
Average developers or average business analysts write average specs, and they will cost you tenfold in time, money, and frustration because your best programmers spend priceless hours sitting in conference rooms or, worse yet, sitting at their desk thinking about who they need to talk to in order to get the answers they need to do their job. You may have heard the old software adage (paraphrased and modified):

“A flaw caught in a spec takes 1 minute to fix. A flaw caught during development takes 10 minutes to fix. A flaw caught during testing takes 100 minutes to fix. A flaw caught after release takes…well…let’s just say more than 100 minutes.”

The details that have the greatest impact during development are the unsolved business and architectural issues. These issues must be brought to light before development begins, and the best way to do this is to have your best people writing your specs.

So how does this relate to my friend’s trip to Oregon?

He left Sacramento with the goal of arriving at a beach house. The spec he had gave him a high-level view of where he needed to end up:

1. 123 Old Country Road, Brookings, Oregon

But what he really needed was:

1. Take I-5 north to the Main Street exit in Brookings
2. Turn left at the bottom of the ramp
3. Drive 3 miles until you see a burned down gas station, then make a left off the paved road
4. And so on…

If you feel like developer productivity is in the tank, take a look at your specs. Make sure they’re keeping you on the paved road.

Photos by Sherry