Archive for category Business

Why Facebook will never catch up to Google

I don’t think Facebook will ever catch up with Google, personally.  Maybe FB knows what everyone “likes” and can sell ads, but Google has equally good data on users.
More than that, they bought all kinds of dark fiber after the dot com bust, created shipping container data centers conveniently located at many of the internet’s peering points, and makes their own servers for mammoth processing and storage capacity.  They are 10 years ahead of FB
And it culminates with this (and I want one!) …

I don’t think Facebook will ever catch up with Google.  FB knows what everyone “likes” and can sell ads, but Google has equally good data on users and also sells ads.  FB knows what people are talking about at any given moment while Google knows what people are interested in and searching for.   Call this one even.

But for years, Google was buying dark fiber on the cheap after the dot com bust.  They’ve created shipping container data centers conveniently located at many of the internet’s peering points.  They’ve created their own servers for mammoth processing and storage capacity.  They are 10 years ahead of FB in hardware and physical infrastructure.

And now this: Google unveils pricing, rollout strategy for high-speed Internet service

Facebook is trendy and users could decide FB is no longer cool at the drop of a hat (though I admit it’s far stickier than that, considering they have years of my pictures and history in a timeline).  Google, on the other hand, is building physical infrastructure in our country, stuff that people will rely on every day of their lives.  It’s the ultimate toll road.

And that’s why Google’s market cap is 4X Facebook’s (and I didn’t even mention Android).

A few rules of business and travel

Business Rule #17432: When travelling on business, work!  There are no interruptions.  There are no kids demanding attention.  It is quiet and it’s the perfect time to focus.  There is no one to answer to about anything, so open the laptop, turn off the TV (why it is even on?), and get to work.

Business Rule #9813: Unless your job requires you to schmooze clients and ply them with liquor, don’t drink.  Not only does it impede Business Rule #17432 above, but the last thing you need is to be hungover during the big conference the next day or not as quick as you’d like to be.  Get to bed early and hit a home run while you’re away.  You’re away from your family, you are sacrificing something, so make it worthwhile!

And this is just a suggestion, but try to get the elite hotel room: 1337 (for hackers only)

leet

Never let a consultant handle your core business

From I, Cringley:

In Minneapolis, Best Buy is known as a body shop.  While they have something like 1000 IT workers, most of them are temporary contractors.  They come and go.  The number of IT people who are Best Buy employees is very small.  Too few to effectively set direction or do things well.  Best Buy depends on an army of consulting firms to do its IT planning and projects.  They do what they are asked to.  Unfortunately there is a big disconnect between what the business really needs and what IT is doing.

Never let a consultant handle your core business.  Every retailer needs to be in the IT business.  Walmart pioneered IT for retailers, what, 40 years ago?  All Best Buy had to do is follow.

Trending local

$45 of every $100 dollars spent at local businesses stays in circulation in the local economy.  The money is spent on local salaries, payments to other merchants, and so on.  A big chain, on the other hand, only keeps $13 in local circulation.  This is the finding of an economic study done in Austin, TX.

Buying local is a nationwide trend.

For years, I’ve seen bumperstickers around Charleston, SC that read “Friends don’t let friends buy imported shrimp” or other slogans mean to encourage support for the local fishing industry.  Other communities have taken the Buy Local idea even further.

One community businessman in Brewton, AL handed out $2 bills to his employees with the rule that after a charitable gift the money must be spent locally.  The bills floated around town and eventually found their way back to his store, which dramatically drove home the point that money circulating in the local economy is its own form of stimulus.

Other communities have encouraged a “10% shift,” which encourages people to redirect 10% of their spending to local businesses or “$20 on the 20th” campaigns where you would spend $20 at a local business on the 20th day of the month.

Best selling author Barbara Kingsolver wrote “Animal, Vegetable, Miracle” about her and her family’s quest to grow or buy only local food for one year. They intimately learned the value of their labor, the strength in their community, and the power of taking control of their health and environment.  They put the kitchen back in the center of their family and learned to work together toward a common goal.  Yes, they had to give up the instant gratification of being able to buy strawberries year-round, but they gained an intense appreciation for delectably fresh asparagus that you can only get by growing it yourself and you can only experience once a year in springtime.

Some may call buying local mini-protectionism, and in a sense it is, but it makes for a strong local community.  It’s kind of like saving your money during a recession.  It’s good for the individual who’s saving, but it’s bad for the overall economy because no one is buying.  But just as saving keeps more dollars here at home than abroad, so too does buying local keep our dollars in our own community.   There are intangible benefits, too, in that communities and families are strengthened as they come together not just for the greater good, but for their own.

5 ways to help your new hire

It’s said that some of the most stressful things you can do in your life are move, have a kid, get married, and start a new job.  It’s all true, too, but this essay focuses on starting a new job because I’ve just started one.

All new employees are vulnerable, regardless of rank or position.  The newbie doesn’t know anyone, doesn’t know the culture, the business, or how to do the job they were hired for.  Yes, they have the skills and are experienced enough to do the job, but they lack all required institutional knowledge to start doing that job on the first day.  It’s a tough position to be in, especially considering the new hire is probably excited and enthusiastic, but rendered utterly impotent by lack of knowledge.

The best way to keep the enthusiasm alive and make that new hire productive is to get them integrated as quickly as possible.  Here are 5 simple things that will reduce downtime, reduce stress, and increase morale for the newbie.  This list is geared towards developers and techies, but some items apply generally.

1.  Make yourself available!

Nothing is worse than being shown your desk or office and then having your guide disappear, leaving you all alone.  Plan on spending time with your new hire or otherwise arranging their first few days to learn from the right people.  Yes, it takes time and everyone is busy with the current release, but abandoning your newbie increases their stress and lengthens the learning curve.

2.  Make sure their PC is ready to go

Twiddling thumbs is bad enough, but not having a PC online with email ready is even worse.  Make sure the new hire can connect to whatever resources they need to do their job.  Many companies achieve most of this by having ghost images of machines with most software pre-installed, but there are necessary network tasks as well.  Email setup?  Is the new hire in the right distribution groups?  All shared drives and other resources given the right permissions?

Make a checklist of all the tasks required to get the new hire into the network and domain.

3.  Hello, World!

The canonical “Hello, World” program proves a lot of things for such a simple application.  It proves that your environment is setup correctly, that you can checkout, build, deploy, and run your code.  It provides a working foundation to build upon and learn within.

What is the “Hello, world” equivalent for real world projects?  A working build from a clean checkout where all unit tests can run, preferably within the IDE, with minimal setup and configuration.

Your new developer needs a checklist of software to install and a simple guide to building and running the project’s unit tests.  I think a checklist is better than a preconfigured environment (from, say, an OS image with everthing preinstalled) because it gives the developer a thorough grounding in the technologies used for the project.  Let them install the build tools themselves and set the appropriate environment variables.  Let them install the source control software and checkout the project.  I believe this gives the new developer a sense of ownership over their PC and deeper project knowledge by knowing how to get it running from the ground up.

It’s true that the new developer will not be truly productive until they gain more intimate knowledge of the code and project, but by having the project running quickly on their local PC, the amount of downtime is lessened and the new developer feels less stress.

 4.  Define your SDLC

How does your new developer get new issues to work and resolve?  What is the process for testing and check-in?  Who are the people responsible for helping the developer get code through the process?

This is basic Software Development Life Cycle stuff and the foundation of the Capability Maturity Model (CMM).  It also helps the new developer feel a whole lot less lost when entering a new environment.

5.   Pair ‘em up!

There’s strength in numbers and comfort in a crowd.  The new hire doesn’t know anyone, so pairing him up with another new hire encourages bonding and forges immediate workplace friendships.  It also helps them both learn more quickly because they are both asking questions and going through it together.  They’ll remember different tidbits when overloaded with too much information in the first couple of days.

If there is only one new hire, have a more tenured employee work with them the first several days.  It’ll slow down the developer who’s been there a while, but it will speed up the new guy.

CONCLUSION

You know your new guy is stressed out and generally uncomfortable.  Making the assimilation process quick and easy is the humane thing to do, but it also makes a lot of business sense.  You are paying that new developer a lot of money.  You should want them to be productive as quickly as possible, as opposed to soaking up company resources.  Make them feel at ease and decrease the learning curve by getting them immersed quickly into the new environment.  It only requires a little bit of planning to keep them busy for the first several days and some basic documentation to get them up and running with a working project.

The above list is certainly not complete, it’s comprised of the first bunch of things that I thought would make my own transition easier. I’m sure a lot of new developers feel as I do when starting a new gig.  Please feel free to leave other helpful tips in the comments.

Two “orders of magnitude” is one too many

An “order of magnitude” gain in efficiency, whether its a business process or computer program, is something to strive for, but two orders of magnitude, despite sounding cool, is one too many.

Why?

Assume you have a perfectly linear process — say, a computer program processing data –  whereby you can add additional processing nodes for parallel processing.  If 1 run of your program takes 1 minute and you’ve got 100 iterations, you can reasonably expect to wait for 100 minutes.

100 units of work x 1 minute per unit = 100 minutes elapsed time

But since your program can scale linearly, you can add an additional program and cut the time in half!

(100 units x 1 minute) / 2 processors = 50 minutes elapsed time

Similarly, you can scale up to 4 processors and reduce elapsed time to 25 minutes.  This is perfect linear scaling and with your big math brain, you figure out that you can get a 10X gain by scaling up to 10 processors!

So far, so good.  10x is an order of magnitude and represents a 90% decrease in elapsed time.

(100 units x 1 minutes) / 10 processors = 10 minutes elapsed time
10 minutes is 10% of the original 100 minute elapsed time. 10x gain!

I think the second order of magnitude is a waste of time.  That’s right, it’s not worth going for another 10x gain.

Why?  It costs too much!

Assume that a server costs $1000 and your process will consume the entire processing capacity of a server.  Scaling up to 10 servers costs $10,000.  You reduced processing time by 90% for $10k.

Math is not on your side for the second order of magnitude.  Taking your elapsed time from 10 minutes to 1 minute is another order of magnitude, but it also is 90% of your cost!

You have a perfectly linearly scalable process, right?  So, reducing your 100 minute elapsed time requires 100 servers at $1000 each.  That’s $100,000!  Meanwhile, already achieved a 90% reduction for $10,000.

90% of the gain is achieved by 10% of the investment.  The remaining 10% of the gain requires 90% of the investment!

Pareto was right.  The 80/20 rule applies, but in our case its 90/10.

The chart below shows two orders of magnitude.  You can’t help but notice the point of diminishing returns.  It doesn’t seem worthwhile to go for that second order of magnitude.

100x.jpg

I’m published, and I struck a nerve.

The JavaLobby (now java.dzone.com) asked to republish my article on human “resources.”  I was happy to oblige!

http://java.dzone.com/articles/were-not-resources

I think the theme of the article touched on a strong undercurrent in the developer community.  My blog post received more than 6k hits over the weekend, has the highest number of comments of all my articles, was republished on JavaLobby, Reddit, and others, and each of the publishers has received a bunch of comments on their repost.

There’s clearly something to the idea that we’re more than just “resources.”  But this is not a new theme or idea.

Forrester Research published a similar article not long ago:  http://blogs.forrester.com/appdev/2008/04/what-is-more-im.html  Similarly, there are several links in the comments of my blog article echoing the same sentiment.

The times they are a-changin’.

This is such an easy concept to grok and an easier one to change.  I suspect that more organizations will begin to rename their “Human Resources Department” to “Human Talent Department.”   It’s definitely more PC and it’s a sign that organizations value the talent their employees provide more than they value the warm body in a cold seat.  That is, unless you’re a government contractor, in which case you really do just want warm bodies.

We’re not “resources”

Resources. It’s a dehumanizing term that is also flat-out wrong for nearly every profession I can think of.

Project planning requires estimates and scheduling. I’ve got no problem with that except when it treats people as interchangeable cogs. In a manufacturing process, skilled workers might be interchangeable. There are only so many ways to stamp out a piece of machinery or otherwise work the assembly line. The process can be perfected to the exact number of steps involved in making a thing. Read The Toyota Way to get a better feeling for how world class manufacturers achieve this.

THESE AREN’T RESOURCES

But there are many, many professions that do not and can not achieve worker utility, where swapping out one “resource” for another is feasible or sensible.

Does George Steinbrenner schedule a “short stop resource” or does he get Derek Jeter? Do they Yankees want homerun hitting A-Rod or a mere “3rd baseman resource”?

Did the Chicago Bulls staff a “shooting guard resource” or did they need Michael Jordan?

Did Apple do well when it had a CEO “resource” or did they achieve the incredible after Steve Jobs came back to lead the company?

Do you want a 1st year medical intern (your “doctor resource”) performing your brain surgery or do you want the foremost expert in the field?

Do you want an “acting resource” or does Brad Pitt have more marquee power?

When was the last time you looked for a “contractor resource” instead of hiring the very best contractor you could find to renovate your home?

Thoughtworkers and creative types are no different. Software engineers are simultaneously creative and logical, and there is an order of magnitude difference between the best and worst programmers (go read Peopleware if you don’t believe this). Because of this difference, estimates have to change based on the “resource,” which means we’re not interchangeable cogs after all.

IT’S THE TEAM, STUPID

You can schedule me to be the Yankees 3rd base resource (thereby saving cost in the Cost-Schedule-Quality tradeoff), but I’m certain the quality of the product would suffer despite the fact that I played little league baseball for years as a kid. Similarly, you can cast me in your movie, but I’m not sure I’d sell any tickets. I wouldn’t do any better running Apple than John Sculley, and you definitely don’t want me performing brain surgery.

Talent matters.

Winning organizations build winning teams, they don’t schedule resources and they don’t break up a winning team. They pay top dollar for top talent knowing that it’s entirely talent that makes a winning team.

Steve McConnell’s widely acclaimed Rapid Application Development ranks “Weak Personnel” as the 2nd classic mistake an organization can make when trying to build software. In discussing teamicide in Peopleware, DeMarco and Lister write “Most forms of teamicide do their damage by effectively demeaning the work, or demeaning the people who do it.”

Talent matters. Treating highly intelligent software developers as “resources” is demeaning, dehumanizing, and ultimately counterproductive to an organization that needs to build and field a winning team.

How to incur 3X costs for 1X worth of functionality

A software development lifecycle that does not include design review early in the process is doomed to poor estimates, cost overruns, and a wildly inaccurate schedule.

Why? Let me tell you what just happened to me.

I picked up a task for a project manager because I had some time free and his resources were completely booked. It was a simple feature with a two day estimate and it was already scheduled for release without having gone through design review. Since it was scheduled, it had a code cutoff date. That was last Friday.

The feature was pretty easy to implement. I needed to add a column to a database table, add support for it in our system, create some services (as in SOA) to change this field, and include the field in our web UI. That’s it. One database column with support for it across our system. Not a hard task.

I implemented the feature within the original estimate, I checked my code into our version control system, signed off on the feature, and asked our Database Engineers (DBEs) to include the new column in our test environment. As far as I know, this was the first time a DBE had a chance to review the feature. They put my change on hold while they suggested moving the field to a different table.

The DBE has a good argument for the field being on the other database table. He may be right. The original requirements may have been good but not good enough. But the problem is this review happened after the entire implementation was said and done.

Changing where the column exists represents a 3X cost of the original feature. The first 1X was the original implementation. Should we choose to move the column, I have to undo the original work and then do it all over again for a different table. Even if undoing the original work isn’t a full X of cost, it is still work I have to do that was not part of the original estimate. Redoing all the work on the new table is a full X of additional cost. We’re at least 2X above the estimate.

A 30 minute design review with the appropriate people would have kept the cost to 1X and given us the right solution the first time. Instead, we’ve got a potentially sub-optimal 1X solution or a 3X correct solution. And this was a simple feature. Larger features with more complex requirements would incur significantly higher cost overruns if not properly designed up front.

Design reviews must be an early part of the process, not an afterthought. It is the only way to avoid 3X overruns.

How To Kill Productivity, Part I

Here’s a surefire, one-step way to sap your staff of two hours of productivity: 1) poorly schedule two hours worth of meetings!

Peopleware famously dissects productivity among thought workers and persuasively argues that environments conducive to developers getting into the “zone” and feeling the “flow” experience higher productivity than those that aren’t so hospitable. Task switching is considered harmful for those whose jobs require deep concentration, high creativity, and other pure thought stuff.

The meeting scenario in this picture may be mocked up, but it has happened to me in real life as I’m sure it happens in many organizations. It’s the quickest, simplest, easiest way to tack two extra hours onto the cost of those two hours of meetings.

howtowastetwohoursofproductivity_.png

How?

Because, like DeMarco and Lister point out, it can easily take 15-30 minutes just to get into the zone!

When the first alert pops up, I’m usually distracted enough from my task at hand. I need to find out where the meeting room is, maybe grab a cup of coffee, and I’ll probably need to use the restroom. That’s 15 minutes gone.

In between meetings we’re catching up on email. And if it’s a slow email day, we’ll read Slashdot or CNN because it’s just not possible to get deeply into the zone in that short window… just to have another alert pop up in 15 minutes. That’s 30 minutes more down the tubes.

After Meeting #2, we’re again catching up on email or making lunch plans. I don’t care if it’s a slow email day AND you brown-bagged your lunch, you’re still not getting deeply into the zone for meaningful work in this 30 minute window. We’re down a full 75 minutes so far.

And after lunch? Too many of other things can distract us from work: more coffee, restroom, email, chitchat in the hallway, food coma, etc. It’s easily another 30 minutes here to even approach the zone, let alone get into it deeply enough before the next meeting alert pops up…

Poorly planned meetings, spaced out as illustrated, are a guaranteed productivity killer.

Switch to our mobile site