Mark Gregory Turansky

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.

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.

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.

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.

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.

The New Yorker has published an article on Nathan Myhrvold’s Intellectual Ventures, a think tank that brainstorms new ideas, patents them, and licenses their subsequent ownership of that new “intellectual property.”

The point of incredulity, for me, came when I read this quote from Bill Gates:

They also came up with this idea to stop hurricanes. Basically, the waves in the ocean have energy, and you use that to lower the temperature differential. I’m not saying it necessarily is going to work. But it’s just an example of something where you go, Wow.

The article talks about Alexander Graham Bell and his genius, and how Myhrvold is inspired by Bell. But Bell didn’t simply think up the telephone and patent it; Bell actually invented the telephone!

Intellectual Ventures files up to 500 patents a year. There are no inventions here, mind you, just ideas. You know the patent system is broken when a company can obtain a government-granted monopoly on an idea like preventing a hurricane and sue the bejeezus out of someone who might actually figure out how to control Mother Nature.

Ideas are cheap. Ideas are easy. It’s the implementation that is hard. The research and successful development of a seemingly impossible idea is worthy of a patent, not the brainstorming for the idea itself. How would you like to solve an impossible problem only to be rewarded with a lawsuit by a troll with a submarine patent who’s put zero work into solving the hard problem? Yeah, that’s what I thought.

The Great Indian Outsourcing movement will be over within two years.

That’s what an architect turned blogger who writes anonymously from Bangalore is predicting. The author is writing from the movement’s Ground Zero, so he may have better insight than the rest of us. But I’ve got good anecdotal evidence from a local outsourcing company that lends weight to his prediction.

I live and work in Charleston, S.C., an area known more for its beautiful beaches and gorgeous live oak trees than high technology (though we do have Robert X. Cringley). But Charleston’s location can attract businesses that don’t necessarily need high technology, just smart people. Outsourcing is one of those types of businesses.

I know personally a project manager at a local outsourcing company. Our daughters go to school together. We were talking at a recent birthday party about outsourcing, cost, and the availability of talent. Business is booming, but it has little to do with cost, she tells me. She says its the lack of local talent that drives most of their business. They deal largely with the marketing end of technology, making websites and fancy Flash applications. Madison Avenue marketing firms would rather hire local Flash experts, she says, but they’ve hired them all. They’d prefer the rapid turnaround that local talent can give them. There just aren’t enough talented people in NYC to fill the huge demand, so they outsource to Charleston, S.C. In turn, this local company sends the work to a development center they own in Costa Rica. Costa Rica is, I’m surprised to learn, a hot up-and-coming technology spot. And you don’t have to wait 12 hours for Costa Rican project managers and developers to reply to email or voice mail.

The Tired Architect – our Bangalorian blogger – talks about the availability of talent in Eastern Europe and China, and there’s obviously talent in Central America. Brazil is another up-and-coming technology hot spot.

I agree with The Tired Architect that India’s monopoly on the outsourcing market is over.

I think the claims made by the people hawking this book are some of the most disingenuous things I’ve ever read:

http://sourcemaking.com/design-patterns-simply

They are selling a rehash of the classic Gang of Four (GoF) Design Patterns book as a PDF, making preposterous claims which I’ll cut & paste here. You can’t make this stuff up.

The Whys:

Why should I read it?
When you finish reading this book, you can go to your boss and ask him for a promotion.

Why? Because using design patterns will allow you to get your tasks done twice faster, write bugless code and create an efficient and reliable software architecture.

How to become programming guru?
The main difference between a programming guru and a novice is the knowledge of secret coding tricks, as well as awareness of most cornerstones and the ability to avoid them.

Design patterns were created as a Bible of avoiding problems related to software design. Isn’t it a true guru’s handbook?

“Bugless code” after learning design patterns! I must be a poor learner, because I still have bugs in my code and I’ve lived with the GoF book for many years now. Unless you are writing code for the space shuttle, you’ve probably written your share of bugs, too. And bosses don’t give promotions because you read a book about patterns. Mine gave me promotions because of hard work, passion, and creativity in problem solving.

“Testimonials”
If you follow through to the order page, you see the publisher is based in the Ukraine. That explains the broken English “testimonials”:

Daniel Sommers, UK

I have learned all design patterns about a 3 days with this book. Thank you very much!!!!

and

Jeremy Parkinson, USA
Four month ago I was just coder in Boeing corp. I had a lot things to learn to get a level up in my skills, and I started with this book. Now I am a software architect and I happy, because nobody in my department is so good with programming as me!

I’d be pissed off if I were Boeing. That “testimonial” makes me think the talent there must be terrible. Boeing does “aerospace engineering.” Rocket scientists. Literally. I suspect they are a smarter bunch than “Jeremy Parkinson.”

Free Book Offer:

Buy our book now and get a free gift! (limited offer)
It is classic “Design Patterns” book by “Gang of Four”.

Amazon is selling the classic GoF book for $38, but this publisher is going to sell you a PDF for $20 and give you a $38 book for free. If they gave a single GoF book away for free, would that be considered a “limited offer”?

The odd thing is that the quality of the rest of the site appears, at first blush, quite good. The writing on the pages describing each of the patterns is good and without any outlandish claims. It makes me wonder if they didn’t get that copy from somewhere else. Regardless, the content on the site is sufficiently good that one wouldn’t need to buy their PDF.

Save your money. Or better yet, buy the real GoF book. It’s a classic for a reason, and there are products that nicely complement the book, like a wall poster detailing the original patterns in a striking visual way.

Fred Brooks famously wrote about accidental vs. essential complexity in his seminal essay No Silver Bullet. If you’ve not read it, I think you owe it to yourself to borrow someone’s copy of the Mythical Man Month and check it out. I believe No Silver Bullet provides a corollary to business and corporate quarterly earnings.

Briefly, Brooks asserts that accidental complexity is the “how” part of programming, such as how we manage memory, parse text, or use editors to write code. Garbage collected languages help manage memory, excellent libraries have emerged to help us parse text (like RegEx), and IDEs get better every single year with support for code completion, intellisense, refactoring tools, and even support for dynamic languages!

Each of these improvements, while welcome, only address the construction process of building software. None of the examples mentioned help attack the “essential” complexity of solving the problem at hand. No amount of tooling will help organizations better understand the problem, increase quality, improve poor designs, or otherwise reduce the complexity of the problem itself. Software construction — the act of actually writing software — is a small fraction of the cost and schedule, while requirements analysis, specification, design, and thorough testing for software fidelity represent the large majority of cost and time when building a product. No tools exist to slay this werewolf. Writing software is hard.

I’d like to posit that business governance is no different. Within a business, there are accidental and essential problems to solve. Both affect the bottom line, but the former will not provide an order of magnitude growth and the latter will always be a hard problem to solve. Wall Street likes to see companies constantly growing to justify any premium or P/E ratio given to the stock.

Accidental complexities in a business are the expenses incurred by normal operations. Payroll is the largest expense an employer has. Facilities and maintenance is another substantial portion of expenses, as is the cost of goods sold for those manufacturing products.

Organizations can increase quarterly earnings by tackling each of these accidental complexities. A business can find the optimal headcount to keep payroll costs as low as possible. Companies can tap into new green building techniques that put gardens on rooftops which help keep the building cooler, thus reducing the business’ energy costs (with a win/win scenario of helping the environment). A business can find a new paper supplier to reduce the cost of stationery or switch to new technologies to remove the paper trail entirely. Programs like Six Sigma help a business achieve higher quality on manufactured goods, reduce costs, and operate at higher levels of efficiency. Highly effective COOs are worth their weight in gold, but there is a fundamental limitation to each of these examples. All of them tackle accidental complexity, and none of them address the essential problem of growing the business itself.

There is no single expense reduction, no single improvement to operations that will grow a business by an order of magnitude, thus making it accidental complexity. Quarterly earnings improvements provide a temporary boost to the company’s stock price, but is quickly forgotten by Wall Street as they look to the next quarter.

Some companies achieve astronomical top line growth for periods of time. Their stocks may double, triple, or even quadruple in value in a year or two. These are exceptional growth rates for exceptional companies. They are not the norm, nor do they represent an order of magnitude in growth. Eventually, all growth companies slow down as the market changes from a growth industry to a mature one. Just take a look at Microsoft. They post excellent numbers every quarter with consistently growing earnings that are predicted, telegraphed, and boring to analysts. It’s a big, mature company in a huge, mature industry. Today, Microsoft struggles in every market they enter that’s not part of their desktop/office business.

The hard problem of growing a business remains. There is no silver bullet.