I watched a presentation today from a Facebook engineer that ended with valuable information. Generally an interesting presentation about the ups and downs they faced with their code. Surprisingly blunt about technology choices as well.
Around 46:40 he talks about Practical Advice. This is the part that caught me.
Evolution of Code Design at Facebook
Don’t Branch
This I wholeheartedly agree with. In my opinion when you decide to branch code to do any form of refactoring you immediately create new problems for yourself. The first problem is “when” to merge back into trunk. Do you merge after everything in your branch is perfectly tested? Or do you wait till both your branch and trunk are perfectly tested? If there was bug fixing going on in trunk while you’re branched testing has to occur for both – but which version do you accept – the trunk or the branch?
The second problem is what to do with conflicts of the merge that exist on the edges of your changes. Do you refactor the trunk just enough to fit the edges? Or do you change your branch to accomodate those edges in trunk? Do you allow these edges to change your design in the branch? And how much time do you spend doing this – just enough to mash it together or enough to have long lasting durability?
The easy answer in my opinion is stay in trunk. Get over your fear of “what happens when my code change breaks the rest of it”. That’s what revisions are for and if you’re smart with your unit testing and judicious with your commits you should never run into broken builds. Most often in my experience developers who immediately reach for a branch are developers who don’t have sufficient tests for their code (me included).
Confession: I am often saying “I’ve never been mad at myself for branching”. And the reason I say this is because I work(ed) in environments where trunk is abused and brittle. Or often too many developers are making too many changes at once. I say it with the sentiment that I want to branch and not have to worry about what the flaky trunk might do. And when I merge, my branch is the winner in all cases. But always (and I mean always) this causes me to have to make code changes in trunk after I merge. Always. And usually afterwards I say “should’ve stayed in trunk”.
Take advantage of product churn
Ah. I love this one. It’s so obvious but yet so hard to really get. In most large websites there is a product group of folks who decide the features. They change their minds a lot. And that is exactly their job. So when they do, why would you stick with a design and/or architecture that solved the previous problem. Or why would you try to design something so long lasting? Take advantage of a clean slate.
There are plenty of arguments to be made for architecting solid systems that can support change. My point is don’t get bound up in architecture decisions so tightly that when change does occur you become adverse. Be flexible and open to the idea that product teams may come to you and say feature X is the next best thing. And that feature may create a ripple in your architecture. If it does, roll with it and re-architect.
It’s my experience that the reason why you get this adversity to re-architect is generally due to the size of the development staff. When you’re dealing with a large staff it is nearly impossible to make quick changes to the architecture. Every developer has to be at a minimum aware of the change, and most of them often implement the change. And when the number of developers is high, the slower the change can occur.
Focus on usability
This is targeted at developer APIs and frameworks, and I do agree but I’m less adamant about it. Or should I say that my version of adoption isn’t so much about winning hearts and minds as much as working with people willing to adopt. And there is a big difference. Top down mandates are a result of working with a development staff that is just not very good with adoption. Organic adoption happens with a certain chemistry and culture. Develop those things first then adoption comes with it. This is a tricky bit to do. And in my experience top down mandates have always been easier (especially in larger development groups). I wish it were different, and I realize my personal style is much different than others.
It all depends at which level you are. For instance I hate being told “which way to do it”. But if I’ve come up with a better way I wish I could give the top down mandate. Organic adoption is always better, but it just doesn’t always work.
Generally I agree with all of these kinds of advice. But admittedly I’m more liberal in my approach to design/architecture/coding. I find myself more open than others to change and especially using yet unfamiliar technology. I dislike rigor and unnecessary structure or process, but I’m not opposed to smart and reasonable standards. But the advice given was sound in my opinion.
