Category Archives: The Business

I am giving you the business.

The Business The Innerweb

Why I Do Not Yammer

July 7, 2012 – 7:38 pm

Yammer, the enterprise social network, has an epic fail for a brand name.  Who in their right mind wants to yammer?  Is that a pleasant word?  No, my friend, it is not.  Here are some definitions found online for the word “yammer”:

  1. to whine or complain
  2. to make an outcry or clamor.
  3. to talk loudly and persistently.

So, this is supposed to make my work life better?  To have yet another channel of communication I must attend to — this one purpose-built for people to whine or complain loudly and persistently?

Yes, Twitter is also a silly brand-name, but at least the word “twitter” brings connotations of merrily chirping birds.  Yammer sounds like a headache.

Message to branding wizards: respect the meanings of words.  Yammer is a horrible name for something that you want people to like and use.

Message to the working world: if your boss tells you, “We’re all going to Yammer now, it’s some next-gen Internet shit that will help us synergize,” or something to that effect, please tell him or her, “Sorry, but I think that’s the dumbest name for a communication product I’ve ever heard.  In the name of intelligent life on Earth, let’s not use it.”

Now, I’ll admit, at least 95% of my irritation with Yammer is because their name is asinine.  But having actually used it at my actual job, I can also say that the marginal benefit of having a Twitter-for-the-enterprise deliver the random thoughts of my co-workers (who do, in fact, have high quality random thoughts) to my desktop or mobile device nearly instantaneously is far outweighed by the negative effect of distraction.  So, really, I’ve tried it and I can do without, thank you very much.

Also, to be clear — I wish the hard working folks at Yammer the best of luck.  I hope they’re all rolling in money, post-acquisition.  And I also hope that they all get to move on to something else soon and work on a product with a better name.

Permalink | Comment (0)
Java Open Source Ruby Software Engineering The Business The Innerweb

QCon San Francisco 2010 Redux

November 7, 2010 – 1:11 am

So, I just got back from QCon SF 2010 last night.  All in all, a very good conference.  Rather than write up any kind of extensive summary, I’ll offer up my rapid digest of the major themes from the sessions I attended.  Without further ado, here it is in outline form:

  1. Dealing with data at large scale
    1. OLTP
      1. Those who can get away with it are using systems that have more flexible consistency models than traditional RDBMS (CAP theorem trade-offs)
        1. Most using some form of eventual consistency
        2. Many sites implementing their own Read-Your-Own-Writes consistency on top of more general storage systems
        3. These systems must deal with data growth (partitioning data across nodes)
        4. Must deal with hot spots (redistributing / caching hot data across many nodes)
        5. Must deal with multiple data centers (some are simply punting on this)
      2. Twitter and Facebook both built their own key-value stores on top of MySql, Memcache
        • Twitter’s solution seemed a little cleaner, Facebook’s a little more crusty
      3. Amazon S3: also key value store with own caching, replication, consistency models
        • This one had the most sophisticated seeming solution for dealing with hot spots
    2. OLAP
      1. Lots of people using Hadoop to crunch offline data
        1. Good tools for workflow of jobs, dependency management, monitoring are essential
        2. Quantcast found that EC2 was not adequate for their needs in terms of throughput compared to an owned, highly-tuned cluster, though it has improved over time
          • still good to have on hand for surge capability
    3. Operating on the public cloud
      1. Increased demand for monitoring — and most monitoring tools not built for cloud instances that wink in and out of existence
      2. Increased demand for fault-tolerance — latency can vary more widely, hardware failures happen out of your control
      3. Increased demand for sophisticated deployment automation
      4. Motivation is that you want to use a cloud, not build one
        1. Capacity planning is difficult when you’re in a huge growth scenario
        2. Leverage the staffing and expertise of the public cloud companies (Amazon, Gigaspaces, etc)
        3. Data center is a large, inflexible capital commitment
      5. Traditional CDNs are still necessary and useful for low-latency, high bandwidth media delivery
      6. PCI compliant storage in the cloud is not a solved problem
    4. Serious interest in alternative languages, both on and off the JVM
      1. There are lots of serious choices available in this sphere (scala, jruby, javascript -> node.js, erlang, clojure)
      2. Lots of enthusiasm for JVM, less enthusiasm for oracle’s ability or intention to be good stewards of it
    5. Though there were many very good sessions, especially in the Architectures You Always Wondered About track, in terms of sheer rock-star appeal these two presentations appeared to be the standouts that had everyone talking:
      1. LMAX – How to do over 100k concurrent transactions per second at less than 1ms latency
      2. Node.js
Permalink | Comment (1)
Software Engineering The Business

business and engineering

July 29, 2008 – 1:46 am

I’ve been thinking lately about the balancing act that a lot of engineering managers have to do between serving the needs of “the business” and serving more technological motivations. It’s certainly a tightrope walk. On one hand, the manager’s job is to keep their team’s activity in budget and in line with the higher level goals of the business. I haven’t had those responsibilities, but I can see that they’re both necessary and full of difficulties. Standing opposite of that perspective is the need to stay on top of technological change. Things move fast in the software world, and people who stand still are frequently left behind.

My impression is that the most common mistake that otherwise smart, responsible engineering managers make is to focus on the business aspects of their responsibilities to the exclusion of the technology aspects. This is understandable — presumably their training and earlier professional experience is in technology and thus the general business aspect of the job is what demands their extra attention. However, I’m of the firm opinion that losing enthusiasm for technology, or losing touch with what’s happening with technology is a cardinal sin for someone in technology management.

It’s not just that those sorts of loss represent a dangerous detachment from one’s roots, but also that they take away what would be the technology manager’s edge. They put one in the position of simply being a “person who knows how to talk to the engineers”. There are probably people like that graduating from business school every day. A far rarer creature is the one who could build the system from the ground up by themselves using all of the latest technologies and who also understands how to guide their team to fulfilling the needs of the larger business. It’s the latter person who is in a better position to deliver innovative and timely solutions.

Permalink | Comment (0)