Teams and Complexity
Let's pretend you're a car mechanic (I don't know, maybe you are). But you don't work at some shop in town, you work at a bigtime auto-maker onsite at the factory. You help build cars from scratch. You work with a lot of other car mechanics, and various engineers of different levels. If we were looking at the 1910s, you might be working for Henry Ford on one of the first ever assembly lines. Either way, you have a specific part of the car you're responsible for. Your skills probably extend beyond that, and you might work on a different part of the car each day as your manager moves you around to keep the factory efficient.
One of your coworkers, Bob, is a superb engineer. He is very good at building cars, far better than you, and he does it faster than everyone else. Your boss really likes him. You often get stuck after him in the assembly line, so you know exactly what sorts of things he does. He's not sloppy, but he likes to do things his way. He will sometimes disassemble and rebuild the entire engine to make it work the way he wants it to. Your boss agrees that his way is best, because he is fast. So you have learned to live with his way of doing it. Sometimes it works well, sometimes it doesn't, but that's just how things go.
You like working with Bob. Your cars are done fast and you get productivity bonuses. Bob is fun to talk to because he's so smart anyway. But one day Bob does something different from how you're used to. It has happened before--he'll come up with some trick to be slightly more efficient and you have to learn from it--but this time it's different. This time, it's a big change. On top of that, just as you're trying to figure out what changed, a new guy, Tom, joins the team. Your manager sees potential in Tom and sticks him in your position, moving you to work on a different part of the car.
Tom doesn't understand the new thing Bob is doing either. But it's worse than that. Bob does a LOT of unique things. You are able to explain a few things you've learned about Bob's style with Tom on your lunch break each day, but even after several weeks he still hasn't picked up on all the different little tweaks. Your boss is frustrated because Tom is making Bob look bad by slowing down the completion of his cars, and lowering the quality as well.
Tom even figures out the new big thing that Bob did, but he's struggling a lot. Just as he gets into the swing of things, Bob changes something again. The manager gets fed up and puts you back in place of Tom. You have spent weeks doing things the normal way and have forgotten many of the tricks that you're used to doing with Bob. It takes you some time to get back into the swing of things. Moreover, you never learned about the big thing that Bob had changed before you left, let alone all the other new tweaks he's made since you changed roles.
You try and get a rundown from Tom, but he's not really great at explaining things. His skill is with cars, not people. You are at a loss and you struggle for several weeks as well. Overall, the factory loses months of productivity before one of you figures Bob out enough to get caught up.
Now, imagine that's software development.
Because it is.
Don't be Bob.
Document your changes. Work to fit existing patterns of the team. Agree on big changes so EVERYONE benefits from efficiency increases.
If Bob rebuilt the alternator, he needs to remember to keep the mounting brackets in the same place so it still fits in the car. This is contract programming. Keep your inputs and outputs the same even as you improve things in individual functions. Use inputs and outputs rather than events so that your code can be followed and understood easily.
One of your coworkers, Bob, is a superb engineer. He is very good at building cars, far better than you, and he does it faster than everyone else. Your boss really likes him. You often get stuck after him in the assembly line, so you know exactly what sorts of things he does. He's not sloppy, but he likes to do things his way. He will sometimes disassemble and rebuild the entire engine to make it work the way he wants it to. Your boss agrees that his way is best, because he is fast. So you have learned to live with his way of doing it. Sometimes it works well, sometimes it doesn't, but that's just how things go.
You like working with Bob. Your cars are done fast and you get productivity bonuses. Bob is fun to talk to because he's so smart anyway. But one day Bob does something different from how you're used to. It has happened before--he'll come up with some trick to be slightly more efficient and you have to learn from it--but this time it's different. This time, it's a big change. On top of that, just as you're trying to figure out what changed, a new guy, Tom, joins the team. Your manager sees potential in Tom and sticks him in your position, moving you to work on a different part of the car.
Tom doesn't understand the new thing Bob is doing either. But it's worse than that. Bob does a LOT of unique things. You are able to explain a few things you've learned about Bob's style with Tom on your lunch break each day, but even after several weeks he still hasn't picked up on all the different little tweaks. Your boss is frustrated because Tom is making Bob look bad by slowing down the completion of his cars, and lowering the quality as well.
Tom even figures out the new big thing that Bob did, but he's struggling a lot. Just as he gets into the swing of things, Bob changes something again. The manager gets fed up and puts you back in place of Tom. You have spent weeks doing things the normal way and have forgotten many of the tricks that you're used to doing with Bob. It takes you some time to get back into the swing of things. Moreover, you never learned about the big thing that Bob had changed before you left, let alone all the other new tweaks he's made since you changed roles.
You try and get a rundown from Tom, but he's not really great at explaining things. His skill is with cars, not people. You are at a loss and you struggle for several weeks as well. Overall, the factory loses months of productivity before one of you figures Bob out enough to get caught up.
Now, imagine that's software development.
Because it is.
Don't be Bob.
Document your changes. Work to fit existing patterns of the team. Agree on big changes so EVERYONE benefits from efficiency increases.
If Bob rebuilt the alternator, he needs to remember to keep the mounting brackets in the same place so it still fits in the car. This is contract programming. Keep your inputs and outputs the same even as you improve things in individual functions. Use inputs and outputs rather than events so that your code can be followed and understood easily.
Comments
Post a Comment