Archive for February 2012
If I had one bit of advice to someone thinking of a startup—including myself, at times—it would be this. Solve a genuine problem, even a trivial one, that you actually have, and that isn’t being adequately solved by an existing solution. Then think about how you can get money for solving that problem. Be wary of scenarios in which your revenue base and your customer base have no overlap.
If I had a second bit of advice, it would be this. Is the elevator pitch for your new startup—no matter how sincerely you believe in its fantastic future—at its heart a variant of, “Think [well-known service name] but with [added feature or new twist]”? If it is, you’d better know somebody willing to call bullshit.
[Seems like right fine advice…]
Source: Coyote Tracks
At first read I agreed with Cross completely, but you know, there’s still a lot of successful products out there that don’t provide a good user experience. Apple is successful by (mostly) providing very good UX and that’s certainly influencing the current generation of designers, but it’s not the only path to success—and there’s an awful lot of work influenced only by Apple’s superficial aesthetics.
[In the end… it’s not about aesthetics. It’s about making tasks easier to accomplish. And about understanding what people were trying to do when they did something and being smart about how you react to it. the aesthetics are the final piece to a very complicated and difficult puzzle. ]
Source: Coyote Tracks
Particularly powerful are the newly-released copies of the IBM concentration camp codes. IBM maintained a customer site, known as the Hollerith Department, in virtually every concentration camp to sort or process punch cards and track prisoners. The codes show IBM’s numerical designation for various camps. Auschwitz was 001, Buchenwald was 002; Dachau was 003, and so on. Various prisoner types were reduced to IBM numbers, with 3 signifying homosexual, 9 for anti-social, and 12 for Gypsy. The IBM number 8 designated a Jew. Inmate death was also reduced to an IBM digit: 3 represented death by natural causes, 4 by execution, 5 by suicide, and code 6 designated “special treatment” in gas chambers. IBM engineers had to create Hollerith codes to differentiate between a Jew who had been worked to death and one who had been gassed, then print the cards, configure the machines, train the staff, and continuously maintain the fragile systems every two weeks on site in the concentration camps.
Newly-released photographs show the Hollerith Bunker at Dachau. It housed at least two dozen machines, mainly controlled by the SS. The foreboding concrete Hollerith blockhouse, constructed of reinforced concrete and steel, was designed to withstand the most intense Allied aerial bombardment. Those familiar with Nazi bomb-proof shelters will recognize the advanced square-cornered pillbox design reserved for the Reich’s most precious buildings and operations. IBM equipment was among the Reich’s most important weapons, not only in its war against the Jews, but in its general military campaigns and control of railway traffic. Watson personally approved expenditures to add bomb shelters to DEHOMAG installations because the cost was born by the company. Such costs cut into IBM’s profit margin. Watson’s approval was required because he received a one-percent commission on all Nazi business profits.
[In an odd coincidence, I was discussing IBM’s role in the holocaust just this weekend. Thanks T., for the pointer to the article.]
Put differently, it’s understood that all software changes incur some risk, and it’s critical to be able to manage this risk on your own terms. Taking that risk in development is good because by definition that’s when you’re incorporating and testing software changes. On the other hand, if you’re shipping production software, you probably don’t want to take this risk when cutting a release candidate (i.e. build time) or when you actually ship (i.e. deploy time) because you want to validate whatever you ship.
You can address a simple case of this problem by only depending on specific versions of packages, allowing no semver flexibility at all, but this falls apart when you depend on packages that don’t also adopt the same principle. Many of us at Joyent started wondering: can we generalize this approach?