Posts Tagged ‘culture’

No Kindle for Me

Sunday, March 1st, 2009

The Kindle 2 is tempting, but I like to own my books. With the Sony Reader or Amazon Kindle, I can’t sell my books.  If either Sony or Amazon goes away, I lose my books. That doesn’t make sense. Gizmodo has an interesting article describing how leasing books and denying the first sale doctrine may be illegal, I’m not hopeful. I’m old fashioned, if I buy a book, I want to own that book and have use of it for the rest of my life. With the Amazon Kindle or Sony Reader, I have it for the life of the respective company or the hardware, whichever expires first.

If I was licensing the book from the publisher and the media was available on all hardware, I’d be less concerned. Even then, though, publishers could go under and sometimes rights holders of media can’t be bothered to keep licensing their copyrighted material. Also, the loss of arbitrage and secondary markets in a license-only world would be troubling, but not a deal breaker for me. Buying the same content again to be usable on the technology du jour is a huge deal breaker.

Drop the DRM, open the format and I’ll buy a kindle.


Do Cubes Make Sense?

Monday, February 23rd, 2009

The people who need solitude the most, software developers, quality engineers, etc. are working in noisy cubes with constant interruption. Meanwhile, managers, whose job is to primarily communicate and organize, have offices. Yet managers spend much of their time away from the offices, communicating to people not in their offices.  Developers who would benefit from doors to close, rarely get them. The logic is managers need doors to close to discuss private matters. In my experience, if I am closing my door a lot, I’m doing something wrong. Why businesses should give developers offices is well-covered in Peopleware, yet most developers remain in cubes.

Cubes made sense, once. In the age of mainframe computing, your IBM 3270 was not portable as it was hardwired to the server. To work, programmers needed to be at their desks. The idea of programmers working from home was not feasible early on. Most everyone in the data processing industry had a cube. Eventually we got modems, SLIP, PPP, broadband connections, laptops and now, wireless. Today, where you can sit, you can work. Beds, coffee shops, couches, air ports, trains are all potential work locations. Why do we still have cubes?

Some people like a small space to personalize that is separate from their home. For some working from home is more distracting than in a cube. Some people like the distractions and opportunities to socialize with co-workers.

Many larger, slow-to-change, businesses have yet to figure out that cubes are overhead and a waste for those who don’t want or need them. Sometimes, corporate culture can be slow to change.

Companies fear that people not co-located won’t work together effectively. I’ve had employees work from home and from the other side of the world effectively. If you have competent people that are motivated, you can trust them.

What would I like to see? A quiet-as-a-library work area, with desks, chairs and couches. Near the work lounge would be numerous small rooms for teams to collaborate. Adjacent to that would be a large space where people could talk, have many white boards, sit down, eat and be noisy. However, some people may need or want a cube – give it to them. However, split some of the cost savings for those who choose less expensive options like working from home or shared work areas. I don’t see a problem with cubes, but if less expensive options exist with equal promise, why not try them?

Ironically, though, after we transition to shared work areas, cubes will become a a luxury. Imagine that.


Favorite Technology Trap

Saturday, January 24th, 2009

Many programmers have a favorite language — usually the one they know best. To me, it’s a fault if the developer sees the language as a hammer and every problem a nail. If hiring a plumber I’d ask, “What is your favorite tool?” The winning answer would be, “Whichever tool suits best suits the problem in front of me.” Experience with a technology should have no bearing on a technical solution, but it often does.

One likable thing about interviewing is meeting others passionate about technology. Recently, after my last company closed, I interviewed. Small, early-stage startups seem to be the most chaotic in technology choices. At early stages, it’s a small group of developers with only one goal: prove the idea works. When I see a baffling choice, like a high-level scripting language, doing CPU-intensive tasks, I ask, “Why?” The more defensive the answer, the more frightened I gets.

Favorite technologies create selective vision for the afflicted. Problems in other technologies are immediately obvious while the favored tool remains The Chosen Answer. Everyone who disagrees is a heretic. Additionally, when you have a favorite technology, and that technology hits its limit, it is somehow acceptable to change the problem.

“Why did you use Java to stream multi-gigabyte files to create SHA-1 hashes?”

“Java has excellent support for databases and creating hash keys.”

“The SHA-1 key generation could not keep up with the stream, missed bytes, and produced the wrong hash key.”

“You’re right – we need to figure out another way to create the hash keys.”

That’s the problem with a favorite tool, you rationalize your way into using it, even when it’s not appropriate. Why would smart people do this?

Their favorite technology is where many invest significant time. Most people want to be in, not out, of their comfort zone. Sticking with a well-known tool is a way to stay comfortable. This is a huge issue with change management. Getting people to learn new skills often meets huge resistance as they fear devaluation while they come up to speed with the new technology.

A way to avoid this trap is to hire engineers who like what they can do with technologies more than any one technology. Ask open-ended questions in interviews, e.g. what languages or platforms they like or don’t like or what kinds of problems they like to solve. Don’t lead the candidate or broadcast your intent, just listen. If you take some time to get to know the candidate rather than asking obscure technology quiz questions, you may be able to figure out if they are already in the favorite technology trap.


Fear of Failure and Quality

Monday, January 19th, 2009

Lydia wrote a great article titled “The Process Trap,” that asks weather company processes help or hinder quality of service. The trap results from a company’s inability to acknowledge and learn from problems. About half of my past workplaces fell into the trap Lydia describes. For individuals, it’s dispiriting to feel “stuck,” and for companies, these are lost opportunities for improvement.

Everyone with whom I’ve worked wanted to provide the best service possible. However, when the penalty for failure is significant, people become fearful. With fear, people’s motivations change — they become less concerned with quality and improvement and more concerned with avoiding failure. Fear of failure is a such a huge detriment to quality that one of Dr. Deming‘s fourteen points for management effectiveness is, “Drive out fear.” Deming wrote that in 1986 for Out of Crisis, so the idea is not new, but not everyone reads Deming.

When customers won’t receive acceptable service, what will employees do when fearful of deviating from standard operating procedures? They will ensure customers receive lousy service. No process will fix that, because it’s an issue of leadership. Somewhere between the person answering the phones and the board of directors, someone has to stop being scared and enable the people under them to do the best work they can. When you’re under a lot of pressure, and most managers are under pressure, it’s hard to be fearless, but not impossible. Absence of fear is necessary because it takes people to improve and adapt processes and people will avoid changing anything when scared.


Hardline Management at Yahoo

Sunday, January 18th, 2009

On ValleyWag, Yahoo CEO Carol Bartz reportedly told staff she would “dropkick to fucking Mars” anyone whose gossip about Yahoo ended up on the blogs. The quote itself was on ValleyWag shortly after. Aside from the obvious fact that treating people with disrespect is wrong and potentially illegal, managers who only care about profits should still avoid this behavior. The key asset of a technology company is not the technology, but the people. Not matter how good your technology is, in a few short years today’s intellectual property will be tomorrow’s commodity.

Threatening employees is demeaning. Your best employees, the ones you want to keep, will have other employment options and, after being repeatedly abused, they will leave. Meanwhile, the people whom you’d better off without, will stay. Demeaning people pushes staff talent the wrong way (down).  In a technology company, this throttles the competitive advantage.

While the threat is strong, this is not strong leadership; it’s not in the company’s interest. Over time, this management style will discourage, demotivate and drain talent, which is especially dangerous for technology companies.