Slashdot Mirror
Twitter's Tech Lead On Making Software Engineers More Efficient
Tekla Perry writes: "Engineering productivity is hard to measure," said Peter Seibel, the tech lead of Twitter's engineering effectiveness group. "But we certainly can harm it." Seibel spoke this week at the @Scale conference in San Jose, hosted by Facebook. He says in large companies one third of software engineers shouldn't be working on the company's products, but should be dedicated to making other engineers more effective. "As an industry we know how to scale up software," he said. "We also know how to scale up organizations, to put in management that lets thousands of people work together. But we don't have a handle on how to scale up that intersection between engineering and human organization. And maybe we don't understand the importance of that. We massively underinvest in this kind of work."
Yes, the company is now profitable and revenue continues to grow, with 2015 revenue expected to be around $2 billion.
I don't get the point of Twitter and don't use Twitter. Having said that, anyone who has thousands of engineers and coders and the project doesn't completely explode has probably learned a few lessons along the way. I'm sure I could learn some things from them. Also, I'm willing to learn from anyone who has brought it billions of dollars.
The attitude of people here suggesting there is nothing to be learned from Twitter's experience is silly - because we've ALL built multi-billion dollar companies around a platfom"with tens of millions of users, right? They only have a few tens of millions of users, they don't know anything about scale. We all know way better than them, because each of has BILLIONS of users on our servers, right?
Not really. People keep coming up with new management fads which then fade away and get replaced, but eventually they all come back to MMM and realize it had it right. If you can't understand the concepts in the Idiot's Guide to the Volkswagen Beetle, you will be utterly unable to understand a modern car. Understanding the older stuff is an absolute prerequisite to becoming an expert, even for software, and it's a shame so many incompetent programmers refuse to believe this.
It's not even just for programming that's dysfunctional, everything gets screwed up with management. I see software people whine that it should be done like other engineering, except that other engineering is dysfunctional as well. Seriously, picking pre-built and well tested components, applying the math, and creating a circuit is a myth too. Most places just cobble things together, they'll argue forever about saving two cents on a board but then go and add a component that's never used. If the boss designs part of it then everyone's too afraid to correct it, or politics gets involved. When it's done, it's tossed over the brick wall to software who are told to work around any defects.
Time for a couple of rants from an old man.
Engineer: I think this word is used far too much. People are not engineers just because they can write code or install applications or whatever. 'Engineer' should describe a mindset, I think: the sort of analytical can-do attitude that some people seem to have quite naturally, which makes them look at structure and seek rational solutions. The archetypical engineer, to me, would be the magnificantly named Isombard Kingdom Brunel.
Effective: This, if I remember correctly, describes the fact that something works. An effective solution is one that gives the desired result - it may not be efficient, though, meaning that it works well, quickly or whatever. No, I couldn't be bothered reaching for one of the countless, online dictionaries, because when you are old, you just know you are right, never mind the facts ;-)
So, that out of the way, and assuming that we are talking about real SW engineers and their efficiency - is that really what holds back projects? Looking at other sectors of production in wider sense, like manufacturing or building construction, the role of the engineer is not actually to whip out as many engineering solutions as possible, but to find the relatively small number of good solutions to structural problems, and to communicate this effectively (and not necessarily efficiently) to the workers. I think it is the same situation we have in software production; calling the everyday coding staff 'engineers' is little more than a bluff - a trick to make people feel they are somehow at a higher level than the common factory worker, so they don't notice how they are actually treated in a rather shoddy way.
Don't get me wrong, though, I think being a SW worker is a very worthy profession; I am one myself, and I think it is something to be proud of. I also think it is a load of nonsense to say that it is somehow our fault that SW projects don't go as well as management would like - at the end of the day, this is a management issue. As a coder, developer, or if you must, engineer, you should be able to rely on managers to make sure that things like good communication and documentation practices as well as other best practices are worked into the team. I think this is what the article is saying as well, although from the 30secs of skimming I didn't see him actually pointing the finger at management as such.
I seriously doubt that. Creation of large pieces of software is abysmally inefficient in basically all examples I have seen. The only exception are situations where a small team of up to 5 people does it all, akin to Brook's "Surgical Team'. These small teams are routinely much more efficient and effective than teams of 20, 30 or 50 people. It has been known since Brook's seminal "the Mythical Man-Month" that creating software does not scale and the only way to accelerate a project is to use better people, but not to use more of them after a certain, very low limit.
As to scaling up organizations, measuring things is more difficult here, but my impression is that something very similar applies: In a large organization, bureaucracy, meetings, infighting, careerism, etc. kill so much productivity, that it is often surprising they get anything done at all.
I think this person has no clue what he is talking about.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Since the mid 1970's every single study shows that the ideal work environment for programmers is a private office (even a very small one) where they can shut the door and mute a phone. Interruptions are the enemy of software productivity. Despite all the evidence, Silicon Valley pushes the open office concept. The rationale is that this improves collaboration, but studies have shown this is another myth and that collaboration isn't really improved by these office layouts.
We all know the reason for this is to save money on office space. But the real question to ask is given the talent shortage and the need to improve productivity is this a "penny wise pound foolish" approach.