"You own your code and its effects - you design, you test, you code, you monitor. If you break something, you fix it."
I couldn't agree more. The more I work with code and people, the more I realize the importance of this statement. Having separate roles for "Architect", "Programmer", "Tester" and "Support" is excellent if you want to introduce bureaucracy and process into the work place and consider programmers as just "cogs in a machine". It's also excellent if you want to see how work can grind to a halt.
Let people own their work and they will only produce things that they are proud of.
The other thing it introduces though is "not my code". There used to be a guy we used to call the "Teflon Don". You couldn't get a bug to stick to him. He could always find a way to move a bug to someone else -- even if it came back, he would spend more time trying to figure out how to pass it on to someone else, rather than just fix it.
At the end of the day hire good ppl. They'll do the right thing most of the time. Hire the wrong people and you'll find that your incentive structure will always lead to deviant behavior.
"At the end of the day hire good ppl. They'll do the right thing most of the time." - absolutely agree.
No system is perfect, ours is not. You need to decide what is important to your organization and emphasize it - they way we do things here at TA has its downsides, but overall, it works very well for us and what we want to do. The benefits for us significantly outweigh the drawbacks.
It is critical to have a boss who understands how software development works, and that mistakes get made. If anything, my boss wants my team to make more mistakes than we do :-)
I think that's a slight misunderstanding of the article. When Andy talks about 'design' he means the engineering part - design of the code, architecture etc. We have a separate team of graphic designers who do just that and aren't engineers.
Comments
"You own your code and its effects - you design, you test, you code, you monitor. If you break something, you fix it."
I couldn't agree more. The more I work with code and people, the more I realize the importance of this statement. Having separate roles for "Architect", "Programmer", "Tester" and "Support" is excellent if you want to introduce bureaucracy and process into the work place and consider programmers as just "cogs in a machine". It's also excellent if you want to see how work can grind to a halt.
Let people own their work and they will only produce things that they are proud of.
The other thing it introduces though is "not my code". There used to be a guy we used to call the "Teflon Don". You couldn't get a bug to stick to him. He could always find a way to move a bug to someone else -- even if it came back, he would spend more time trying to figure out how to pass it on to someone else, rather than just fix it.
At the end of the day hire good ppl. They'll do the right thing most of the time. Hire the wrong people and you'll find that your incentive structure will always lead to deviant behavior.
(disclosure - I am the author of this article)
"At the end of the day hire good ppl. They'll do the right thing most of the time." - absolutely agree.
No system is perfect, ours is not. You need to decide what is important to your organization and emphasize it - they way we do things here at TA has its downsides, but overall, it works very well for us and what we want to do. The benefits for us significantly outweigh the drawbacks.
It is critical to have a boss who understands how software development works, and that mistakes get made. If anything, my boss wants my team to make more mistakes than we do :-)
But how do you find good engineers who are also good graphic designers? That seems to be the sticking point to me.
I think that's a slight misunderstanding of the article. When Andy talks about 'design' he means the engineering part - design of the code, architecture etc. We have a separate team of graphic designers who do just that and aren't engineers.
Disclosure: I'm an engineer at TripAdvisor.
amen