Something that makes a difference that you can do right away...
Most development organizations are often like overloaded computers -- their CPU monitors pegged out at 100% most of the time, with an occasional brief drop. This is not exactly an environment where you can expect to make wholesale, immediate changes, so I'd like to talk about something even maxed-out organizations might be able to handle. I'm not saying this slight change won't have to be squeezed in, but it won't take that much squeezing, and the benefit is enormous.
What I'm talking about is interviewing developers at the end of their projects to record their thinking. Note that this is not the same as asking developers to record their thoughts themselves -- this has been proven time and again not to work well. A key ingredient is a technically-knowledgeable and articulate interviewer who digs out the relevant thinking behind a project and records it for the next developer.
For example, imagine your company produces cell phone games, and one of your developers has recently completed the first version of "Battleship". The developer finished the job more or less to the satisfaction of management (the developer didn't use the planning I talk about elsewhere, so the project did not exactly end quietly and smoothly), and is ready to work on his next game.
In the meantime, your company is preparing to release "Battleship" to customers. Once the game is on the market, probably some bugs will be discovered and need to be fixed, and marketing will want to add some features for a new version.
Your software development management has decided to assign this follow-on work to a more junior developer. He is encouraged to approach the original developer with any questions he has.
In reality several things will happen. The original developer will be immersed in his new project, so when the junior developer approaches him, he will generally be cranky. Why? Because the original developer's memory of what he did in the "Battleship" project has faded, and it is sometimes painful to refresh your memory about code, especially when you may have been too clever. Secondly, the original developer, like most typical developers, may have expectations that anyone with a reasonable IQ should be able to figure things out from the source code, so the question-asking is just a lazy short-cut. Third, there might be things in the code the original developer is not particularly proud of.
In any event, the junior developer does not get nearly enough guidance, and resorts to "software archaeology" to reconstruct the original developer's thinking from the source code. At this point, the junior developer may begin to develop migraines, especially if the original developer did not write particularly clear and well-formatted code.
Eventually the junior developer submits some bug fixes and modifications to the code. Regularly, quality assurance finds broken features and new bugs that are the result of the junior programmer's assumptions about the code. Fortunately for your company, quality assurance is able to find all such major flaws.
This type of scenario occurs regularly in software development organizations -- a code hand-off with a promise for support from the original developer hardly ever works. Human nature almost guarantees a rocky road ahead. Also, there is a forced quality to the process, and anything with a forced quality usually means that the process needs to be broken down into smaller pieces.
The piece that is missing is the interviewing I mention above. The trick is to get the right person to do the interviewing and recording.
First the person has to be a programmer or former programmer (a really good former programmer is ideal). Nothing will annoy a developer more than an interviewer who knows little or nothing about programming. A common background in programming gives the developer a sense of kinship with the interviewer, which builds trust and rapport between the two. This bond allows the interviewer to press with questions that would irritate the developer when asked by someone else. This goes double when the interviewer asks the developer to explain something a second time.
Secondly, the person has to have a keen sense of what to ask. When I serve as an interviewer, I focus on terms which haven't yet been defined. For example, when I interviewed a developer about a simulator program he had written, he mentioned a php interface layer. I know what php is, and I have a general notion of interface layers, but I didn't know what it meant for this particular program. When I asked the developer to explain this further, our conversation yielded some key information the source code by itself did not reveal plainly.
Thirdly, the person has to be able to articulate the information so the next developer can easily digest and apply it. It seems to me that having a keen sense of what to ask and articulating the answers for the next developer go hand in hand -- the path the interviewer follows is probably the same path the next developer will follow when trying to get his head around the code. So if you can find a person who developers like talking to about their projects, chances are good this person can also record the answers in a useful way for the next programmer.
Of course, capturing a developer's thinking requires some of the developer's time. In an environment which is pegged out to 100% most of the time, you might not see how there is time for interviewing. However, the more you work interviewing into the development process, the easier the going will be somewhat down the road. Junior developers won't have to spend senior developers' time asking questions (essentially doing interviewing), senior developers won't be interrupted nearly as much and will be able to focus on their current projects, and you won't risk having products go out the door with errors based on faulty assumptions from the source code. The bottom line is squeezing in the interviewing into the process makes an overall difference in a relatively short time.
When is the best time to squeeze in the interviewing? At the very end of the project. Ideally, the interviewing should take place after the product has shipped and the developer is not under any pressure to fix "the last bug". At this point, the developer is the most relaxed, and his memory of his thinking behind the code is still fresh.
Where should the interviewers information go? Ideally in the source code. Tools such as Doxygen make it quite easy to keep a developer's thinking and code side-by side in the same file. Another approach is to create a wikipedia, but I'm a bit leery of keeping the thinking in one place and the code in another. Word documents come in a distant third.
No matter where you store the developers' thinking, the point is that it won't just be evaporating with their fading memories. Perhaps your company's CPU meter might begin to dip below 100% a bit more often, all while your company wastes less time and money on software disasters in the field.
What I'm talking about is interviewing developers at the end of their projects to record their thinking. Note that this is not the same as asking developers to record their thoughts themselves -- this has been proven time and again not to work well. A key ingredient is a technically-knowledgeable and articulate interviewer who digs out the relevant thinking behind a project and records it for the next developer.
For example, imagine your company produces cell phone games, and one of your developers has recently completed the first version of "Battleship". The developer finished the job more or less to the satisfaction of management (the developer didn't use the planning I talk about elsewhere, so the project did not exactly end quietly and smoothly), and is ready to work on his next game.
In the meantime, your company is preparing to release "Battleship" to customers. Once the game is on the market, probably some bugs will be discovered and need to be fixed, and marketing will want to add some features for a new version.
Your software development management has decided to assign this follow-on work to a more junior developer. He is encouraged to approach the original developer with any questions he has.
In reality several things will happen. The original developer will be immersed in his new project, so when the junior developer approaches him, he will generally be cranky. Why? Because the original developer's memory of what he did in the "Battleship" project has faded, and it is sometimes painful to refresh your memory about code, especially when you may have been too clever. Secondly, the original developer, like most typical developers, may have expectations that anyone with a reasonable IQ should be able to figure things out from the source code, so the question-asking is just a lazy short-cut. Third, there might be things in the code the original developer is not particularly proud of.
In any event, the junior developer does not get nearly enough guidance, and resorts to "software archaeology" to reconstruct the original developer's thinking from the source code. At this point, the junior developer may begin to develop migraines, especially if the original developer did not write particularly clear and well-formatted code.
Eventually the junior developer submits some bug fixes and modifications to the code. Regularly, quality assurance finds broken features and new bugs that are the result of the junior programmer's assumptions about the code. Fortunately for your company, quality assurance is able to find all such major flaws.
This type of scenario occurs regularly in software development organizations -- a code hand-off with a promise for support from the original developer hardly ever works. Human nature almost guarantees a rocky road ahead. Also, there is a forced quality to the process, and anything with a forced quality usually means that the process needs to be broken down into smaller pieces.
The piece that is missing is the interviewing I mention above. The trick is to get the right person to do the interviewing and recording.
First the person has to be a programmer or former programmer (a really good former programmer is ideal). Nothing will annoy a developer more than an interviewer who knows little or nothing about programming. A common background in programming gives the developer a sense of kinship with the interviewer, which builds trust and rapport between the two. This bond allows the interviewer to press with questions that would irritate the developer when asked by someone else. This goes double when the interviewer asks the developer to explain something a second time.
Secondly, the person has to have a keen sense of what to ask. When I serve as an interviewer, I focus on terms which haven't yet been defined. For example, when I interviewed a developer about a simulator program he had written, he mentioned a php interface layer. I know what php is, and I have a general notion of interface layers, but I didn't know what it meant for this particular program. When I asked the developer to explain this further, our conversation yielded some key information the source code by itself did not reveal plainly.
Thirdly, the person has to be able to articulate the information so the next developer can easily digest and apply it. It seems to me that having a keen sense of what to ask and articulating the answers for the next developer go hand in hand -- the path the interviewer follows is probably the same path the next developer will follow when trying to get his head around the code. So if you can find a person who developers like talking to about their projects, chances are good this person can also record the answers in a useful way for the next programmer.
Of course, capturing a developer's thinking requires some of the developer's time. In an environment which is pegged out to 100% most of the time, you might not see how there is time for interviewing. However, the more you work interviewing into the development process, the easier the going will be somewhat down the road. Junior developers won't have to spend senior developers' time asking questions (essentially doing interviewing), senior developers won't be interrupted nearly as much and will be able to focus on their current projects, and you won't risk having products go out the door with errors based on faulty assumptions from the source code. The bottom line is squeezing in the interviewing into the process makes an overall difference in a relatively short time.
When is the best time to squeeze in the interviewing? At the very end of the project. Ideally, the interviewing should take place after the product has shipped and the developer is not under any pressure to fix "the last bug". At this point, the developer is the most relaxed, and his memory of his thinking behind the code is still fresh.
Where should the interviewers information go? Ideally in the source code. Tools such as Doxygen make it quite easy to keep a developer's thinking and code side-by side in the same file. Another approach is to create a wikipedia, but I'm a bit leery of keeping the thinking in one place and the code in another. Word documents come in a distant third.
No matter where you store the developers' thinking, the point is that it won't just be evaporating with their fading memories. Perhaps your company's CPU meter might begin to dip below 100% a bit more often, all while your company wastes less time and money on software disasters in the field.
posted by John Keklak at
8:47 AM
0 Comments:
Post a Comment
<< Home