Twitter moving to the JVM more and more

The important part of this presentation is about the virtual machine and it’s performance/scaling. Not the language. In fact if he never mentioned languages at all the presentation is still valuable.

This is more tricky than might be imagined. It’s a gallery of modules. It’s a development environment. It’s a hosting environment. It’s a core library. And not always in this order.

It’s exciting stuff to think about. And it’s really cool to think about doing it with JavaScript (client and server sides). A few things that cause concern are the definitions of things.

• What is a module?
• What is a component?
• Is there a difference?
• Or are components applications?
• What does “development environment” mean?
• Does hosting mean you get what you get or does it mean you can get what you want?

It’s answers to these questions that are critical in designing a system like this.

Fun stuff.

There’s an old joke about the C programming language that says it allows you to shoot yourself in the foot. And mostly that is a fair statement to make, with one caveat. The caveat is: if you don’t know what you’re doing, you will shoot yourself in the foot. And this isn’t a software programming thing. You can say this about a lot of things. But with software it just so happens that as a lesser experienced developer you are capable of creating and doing quite a number of things with the power to shoot yourself in the foot and not know it until there’s blood everywhere.

Creating libraries and systems that can be reused and won’t allow the user to do something bad (knowingly or not) is really hard to do. How do you write a recipe for a casserole that prevents the cook from burning it? Or how do you give someone directions to your house that prevents them from missing the street sign? Now imagine writing a recipe for a casserole that allows someone else to write their own recipe for a casserole? That’s what a software library should do when it’s really good.

It’s difficult if the target audience of the library or system is what some call “junior”. This is to say they have less experience or don’t have the skill set utilized in the library. A Java developer using a JavaScript library for example. Juniors may barely have experience with JavaScript but now be tasked with using this library. Obviously a good library will help them do things with the limited experience. But that doesn’t help them with the things outside of the library. And it certainly won’t prevent all the mistakes that can be made.

I was reminded of this today as I was putting together a desk I bought from Target. The instructions were written with a tone of “don’t worry we’ve written instructions to all but do the work for you.” Pretty bold claims. Then I imagined myself without the experience I have with regular tools. What if I wasn’t sure what a Phillips screwdriver was? And what if I didn’t know the difference between that and a flat-head? Sure there is a picture showing both, but the screws provided accept both. Hmmm. One is certainly better than the other for this setup, but what if I didn’t know better. The problem is the instructions gave me just enough to get the work done, but not prevent blood. What was missing was experience or an education of how to use the tools and in what context they’re suited best.

It’s my opinion that what is really missing in a lot of software development is education. Not the school kind of education, but the hands-on side-by-side kind. Giving presentations, pair programming and one-on-one work are a few ways to help educate. In most cases it just takes time, sitting with a junior and showing them. Write some code. Make some changes. Explain. Rinse and repeat. It’s quite alright to develop libraries and systems that make mistakes go away. But it would be even better to educate. With an educated development crew, the libraries can focus on doing cool stuff and drop the need for all the preventative stuff. Teach the developer to prevent mistakes themselves.

Educating the junior isn’t easy. In fact it’s down-right hard. Each developer learns differently and at varying pace. But if taught there is more to gain than what a perfectly written library could ever achieve. In fact that is the crux of my thought. More juniors turned into seniors is always a better investment. A library may prevent the majority of mistakes but it will always be just a library. A developer who is educated will always be capable of producing more.

I work in a company that is pretty typical with corporate hierarchal authority. There are your C level people, VPs and all kinds of middle management. Mostly it makes sense who is who.

It’s only confusing however at the lower levels. The levels where there isn’t a hierarchy. In most cases the upper levels of authority like to empower the lower levels (they say they do at least). That word empowerment is funny. By definition it means to relinquish power to someone else. All well and good. But does that mean that every subordinate has authority? And what are the boundaries to that empowerment? When everyone has the power to make a decision, who gets the last one? There has to be a final decision right?

In software development some would call this “design by committee” and generally it’s with a bad connotation. The dislike for committees is likely due to the belief that there ought to be a final decision in software design. Even if that decision is temporary or up for change later, it’s kind of final and work can move forward. Otherwise if there isn’t a final decision work doesn’t progress. Instead it’s debated and deliberated ad nauseam.

There are good reasons to have committees. There are also very good reasons to debate decisions. Some decisions are long lasting and making the wrong call could effect a large number of people in a harmful way. These kinds of decisions need thorough analysis. But those kinds of decisions are few and far between. Really far between. If decisions are rated on a scale of 1-5 with 5 being “really impacting” and 1 being “harmless to all” I would guess that 90% of all decisions are below a 3. Committees should be for the 4 & 5 decisions. In all other cases there should be only one person making the decisions. Leave the debating to the important stuff. One person should make a call on the rest allowing everyone to move forward.

The trouble is when there isn’t a hierarchy at the levels where 90% of decisions exist. Those decisions are then left for the upper levels of authority to make. And then the volley starts. Upper levels say “go ahead with whatever you think best” and then lower levels say “we’ve come up with a bunch of options – which one do you want” and then back and forth. Empowerment is great, but it’s not always useful for a group or committee.

For me personally, it’s frustrating when groups don’t have a single lead, decision maker or tie-breaker. It’s really aggravating in some cases. It’s pretty often that I really want to make the call, and most often I do voice my opinion. Sometimes I get it right and others will follow. Sometimes I get it wrong and someone else gets it right. Generally I’m Ok with this (but often I think my decision is better for whatever ego driven reason). I’m sure many others feel this same way, it’s pretty natural I’d guess. And I’m sure there are others that don’t really care to make a decision, rather they’d prefer to be told. This is fine too, in fact it would argue my point that each level of organization ought to have one decision maker. Consider what would happen to a team that is full of people not interested in making a decision but have been empowered to do so?

Decision making occurs everyday. There ought to be someone designated to do just that at all levels of an organization. At least someone designated as a tie-breaker.

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.

Widgets are those things that the library creates for you like text box, button, drop-down and the infamous Calendar. And in doing so the library relieves you of some effort, and/or provide you some uniformity. That second bit is what my co-workers always bring to the table. Their point is that if you have 100 developers all building software for your website – you really want them building these widgets in the exact same way to help with maintenance/updating and general look and feel. And that’s a huge point. It’s critical. And on occasion they bring up companies like Apple to point to the fact that when you build software for the Mac you get these “widget” libraries built in, so that your app looks like a “Mac app”. If the core library gets updated to change the menu bars for example, your app receives the same treatment for free. No work on your part.

I always retort with “Ok but let’s not build every single widget out there for our library” or more often “we don’t need a library that has all that built in already.” And what I mean by that is, in my opinion, I’ve never seen websites in particular use the exact same widgets across multiple pages. Sure there are the few, staple widgets that in fact are the same across whole sites. But that list is small. No more than 10. Everything else is some variation of a staple. And if that’s the case it would be better to have a library that provides the absolute core set of widgets, but has huge extensibility built into it. Which is to say, a developer could start with the core widget, but extend it to add features for his/her own needs.

The bottom line is that there has to be uniformity across all the widgets (colors, button positions etc). Most often this is referred to as HIG (Human Interface Guidelines). However, it’s my opinion that HIG should not always be followed. Developers always start with HIG, but usually it falls away after a special new feature is requested and it doesn’t quite fit into whatever HIG they’ve adopted. What do you do? Do you change the intent of the new feature to match the HIG? Or do you side-step the HIG to get the new feature just right? And why would a JavaScript library be involved in that decision?

That last question is always where I end. Why would I use a library that caused me to choose one way or the other? If for example the library had “all the widgets I needed” with little extensibility, I’d be forced to look at reducing the feature possibly to fit into the capability of the library or because of the HIG. And is the HIG always the final answer? But if the library had all the extensibility I needed, is it more possible I could meet the HIG by developing a 1-off widget?

This is a tricky situation. There are a lot of ramifications in both directions. Generally speaking you’ll stay out of trouble with a library that “does it all”. And more often than most people would like to admit, you’ll encounter a circumstance where that library doesn’t do “this one thing”. I don’t claim to be right, but I stand by my style and philosophy. I usually lean on the side of “give the developers the room” instead of the other side “give the developers all they’ll need”.

Regarding expectations, I’ve noticed that those who are expected of and feel they deliver on those expectations often get disappointed. This is usually due to the fact that what they delivered was expected and therefore not praised as some work of heroics. Or maybe they weren’t praised at all. Generally: do as you’re asked and nothing happens.

Put another way, those who continue to deliver as expected are generally asked to do more of the same. And with each delivery less and less praise is received (if at all). This is strictly because it is expected to be done. However this disappoints those who deliver on expectations because everyone could use a “pat on the back”.

Now consider those who deliver more than expected. This often receives some form of “praise”. Naturally praise is given when “above and beyond the call of duty” work is performed. For those who did the work ,this feels great. And sometimes it’s motivational. People will want to do it again.

Let’s then consider when “above and beyond the call of duty” work is performed again and again. That creates a new normal. A new expectation level. Above and beyond is now expected. Praise then wanes. Disappointment brews in those who do the work. This demotivates those doing the work. Sometimes indignation creeps into those doing the work.

In all cases bad blood is created between those asking for the work and those doing the work.

In my opinion there are things that each side can change that may prevent disappointment and bad blood.

For those doing the work: do it for yourself – not for praise from others. Remember that work is what you make it. If you are lucky enough to really enjoy your work, leave it at that. If you don’t enjoy your work, well that’s an entirely different problem. Expecting praise will lead to disappointment because it’s never enough. Face it, people are busy and what you do in the big picture is yours. No one else is going to really appreciate your work. Learn to praise yourself and learn to need only yourself to feel good about what you do. If you are happy doing exactly as you’re expected, good for you. The world needs more of you. If you want to do more and go beyond the call of duty, good for you. You should be proud of yourself for being a person who wants to do more. But in either case don’t get ruined when others don’t provide you some form of recognition. Recognize yourself.

For those asking for the work: remember what people are sacrificing. At work it’s easy to say that within the window of 8-5, people are willingly giving up life’s pleasures such as free time and leisure activities. But don’t forget that there are emotional and psychological sacrifices made all the time. Pride and ego are big things, and you shouldn’t inadvertently stomp all over them by simply forgetting to throw a little praise around. If people are delivering on your expectations, remind them that you know. Let them know that you’re paying attention. Rub their pride a little with an easy “thanks” or “good job”.

“No good deed goes unnoticed”. Bullshit. They do all the time. So keep doing those deeds for yourself and learn to notice others doing the same.