June 15, 2009
In product design, “roll the DICEE.” That’s an acronym. “D” is for deep, which to Kawasaki means thinking about features that go beyond the norm. One of his favorite “deep” ideas: Fanning Reef sandals, which have a bottle opener built into the sole. “I” is for intelligence, as seen in the design of Panasonic’s BF-104 flashlight, which uses batteries of three different sizes to accommodate the random mix of extra batteries many people have around the house. “C” is for complete — or being not just a product, but including support and service. The first “E” is for elegance: Beauty matters, according to Kawasaki. “Companies should have CTOs — chief taste officers,” he said. The second “E” is for emotive. “Great products generate strong emotions: Think Harley Davidson, Macintosh.
Comments (View)
June 12, 2009
The reality is that the browser vendors have the ultimate veto on everything in the spec, since if they don’t implement it, the spec is nothing but a work of fiction. So they have a lot of influence—I don’t want to be writing fiction, I want to be writing a spec that documents the actual behaviour of browsers.
Comments (View)
June 10, 2009
effectiveness of execution is a function of the quality of the idea multiplied by the executor’s commitment to make it work. Smart people — especially engineers or technically gifted professionals — can get so wrapped up trying to improving quality a little that they may damage commitment a lot.
Comments (View)
June 3, 2009
Site blocking non-IE/Gecko browsers is usually incompetence. iTunes deliberately blocking Pres would be malice.
Comments (View)
May 30, 2009
Every software developer has the desire to look smart and competent in the eyes of her peers. Well, OK, perhaps not every developer, but every one who cares at all about her work. When you know you’re going to get a code review, the way you write code changes instantly. You’re going to be extra careful to document properly, do input validation, handle corner cases, write good tests, and think about scalability and error-handling.
Comments (View)
May 4, 2009
with Ajax — you’ll still have to hand-tune the code so that it works on multiple browsers. Less work, but not work that I want to do at all. Why spend company resources on these problems when you can just put in an intermediate layer and completely eliminate the issue?
Comments (View)
April 17, 2009
Although I remain a fan of test driven development, the speculative nature of the time investment is one problem I’ve always had with it. If you fix a bug that no actual user will ever encounter, what have you actually fixed? While there are many other valid reasons to practice TDD, as a pure bug fixing mechanism it’s always seemed far too much like premature optimization for my tastes. I’d much rather spend my time fixing bugs that are problems in practice rather than theory.
Comments (View)
March 21, 2009
Most people make the mistake of thinking design is what it looks like,” says Steve Jobs, Apple’s C.E.O. ”People think it’s this veneer — that the designers are handed this box and told, ‘Make it look good!’ That’s not what we think design is. It’s not just what it looks like and feels like. Design is how it works.
Comments (View)
March 20, 2009
When a company is filled with engineers, it turns to engineering to solve problems. Reduce each decision to a simple logic problem. Remove all subjectivity and just look at the data. Data in your favor? Ok, launch it. Data shows negative effects? Back to the drawing board. And that data eventually becomes a crutch for every decision, paralyzing the company and preventing it from making any daring design decisions.
Comments (View)
March 18, 2009
You need a framework? What is this, a framework? You don’t need a framework. They told you you need this. You don’t need this. You need a painting, not a frame.” — Klaus Kinski
Comments (View)