Sneakernet Writ Large
Amazon introduces Snowball appliance for physically importing data to AWS. Fill it then FedEx it.
Programming
Nine Hardest Things…
That programmers have to do. A decent listing. Most people have no idea. It’s especially bad when you can whip together a basic interface that demonstrates what an app can look like and, to some degree even if by faking it, what it can do, and people then take that as an indicator of how little time creating the full thing should take.
BASIC My Dear Watson
I had missed David Brin’s Why Johnny can’t code way back in 2006. The main point is the lack of something like BASIC as a default program/learning tool included on every computer, as was the case for so long in the past. I can see how that could be a problem, leading to fewer kids gaining elementary knowledge of coding early. For my part, my first exposure to BASIC was on a friend’s Radio Shack computer in 1978. I somehow picked up a surprising amount without trying. Next I played with it on a similar computer someone my stepmother worked for had about 1982 – 1983. Might have seen it elsewhere, but don’t remember. Then I had a Radio Shack PC (Pocket Computer) I got for Christmas 1983, and it wasn’t good for much without using its abbreviated version of BASIC. For instance, using I instead of INPUT as part of its command set. 1K of bubble memory required being lean.
Somehow this was capped off by my ending up in Microsoft Visual Basic support, initially supporting VB3 and the final version of each of the DOS BASIC variants, then supporting each VB release through 6. At the end I was one of the two technical supervisors and ran the training.
In any event, it was in conjunction with seeing mention of Brin’s article above that I saw a pointer to Quite BASIC, and online answer the the lack he showcased. I didn’t dive into it, but thought it worth noting. I have kids who are liable to be interested in this sort of thing before you know it.
A Look Back At OS/2
This ends up being a look back at the entire history of the PC, to do it justice and give it context. Via Bill Quick, who used OS/2 more than I did: Half an operating system.
In my case, I had a friend who ran a BBS that gave me my first online experience, and he was an OS/2 fanatic and Microsoft detractor. One of the newsgroups he carried (or maybe it was a Fidonet group) was Team OS/2, for fans and users of the OS. This was int he lead up to the release of OS/2 Warp 3.0, which I went out and bought. That was just before Windows 95 released, after I’d been doing Microsoft Word support for nearly a year. After fifteen months in Word support, I moved to Visual Basic support, but not until I’d received pre-release training on Windows 95. I was blown away by 95, especially given the quality training and a degree of relatively inside insight into the OS.
I gleefully bought Warp and installed it on a 386 I was able to spare for the purpose. In retrospect, I was not sure this was entirely fair, as I installed 95 on a 486. I thought OS/2 was cool, and it installed without real issue, apart from duration. Thing is, it crashed readily. I was shocked it was so unstable, given the hype among the fanatics. By comparison, 95 was a rock. It took almost no time for me to abandon even playing around with OS/2, but I always felt that they could keep trying and it would be great to have the competition.
Some of the details in the article are news to me. Some are not. The heavy hand of the mainframe division of the company was always a factor in the PC division, and even more deadly when it came to OS/2. What a shame. I hadn’t realized, or at least hadn’t remembered, that there was ever any connection between Microsoft’s NT effort and OS/2, apart from competing. I know Microsoft spent what was a staggering sum at the time on developing NT from scratch, which paid off brilliantly.
Finally, it’s easy to look back more dispassionately on Microsoft, now that they remain big and powerful but are no long scarily “monopolistic” in the post-PC era.
Dancing Bubble Sort
Via Warren Meyer, who in turn got it from Flowing Data, it’s a bubble sort demonstrated with Hungarian folk dance:
Giving “Ship Date” New Meaning
Here’s a whole new concept in offshoring. Instead of farming out work to programming groups in different countries, bring developers from different countries to a cruise ship just far enough offshore to be in international waters. Sort of a floating skunkworks for hire.
Via Glenn
Software Project Failure Even Happens To The Feds
Back on January 13, Aubrey Turner noted the failure of the FBI’s terrorism information sharing software project, after spending $170 million. His discussion of how and why software projects is essentially what I would say, so you should read that first and foremost.
I would add that it is well worth reading Rapid Devlopment, by Steve McConnell, and perhaps similar books, if you are in any way involved with a software development project enough to make it worth understanding how they fail and how that can be avoided. That’s the one I am most familiar with and can’t recommend enough.
What reminded me was seeing Michelle Malkin mention the same project failure yesterday, referencing discussions of it by Craig Henry and Photon Courier, which are also interesting, but do not get into the large topic of software project management the way Aubrey Turner did.
I’d comment at length myself if I had more time, but I at least wanted to toss this out there for people to see, and Aubrey represents what I might say.
The Art of Buzz and Timeliness
There have been a bunch of people reading and reviewing or commenting on a recent book by Guy Kawasaki called The Art Of The Start. I am not one of them.
This is an excellent, concerted exercise in using blogs to build buzz for a product. Based on what I have seen, it’s a good book, and one I’d certainly like to read. Would this work for a lousy book? Depends on the honesty of the reviews and whether people just have to “see for themselves,” as so often happens with films panned by the usual crop of critics.
Just that I know of so far, the book has been mentioned at:
Small Business Trends
Dean’s World
BusinessPundit
Scobleizer
Lip-Sticking
Management Craft
Blogcritics in multiple places, here, here, here, and here.
In Anita Campbell’s review, one paragraph that relayed a snippet of Kawasaki’s advice really grabbed me, as it is advice I give, and advice I have direct experience in my business not following:
Ship, Then Test. What he means is for a startup to get a product out the door and into customer hands as fast as possible. That way the company can start bringing in money and start getting customer feedback. No matter what he talks about, he always comes back to what I call the first rule of startups: cash is king.
This is the Microsoft way. Get version 1.0 on the market, blemishes and all. Flow some revenue, and keep improving the product. To a point, first to market, or building share as soon as possible, beats the initial version being flawed. Make it flawed enough and this could fail, naturally. Microsoft no longer needs to do this, but one of their strengths is to always act like a startup, alwasy act like the next Microsoft is chasing them and could catch up.
Some of us who were working in Visual Basic support for Microsoft saw demand from developers for a product that would easily port data between versions of Access, and other which ways. When we started the business, the objective was to create products to be marketed ourselves or to sell as a completed concept to another company that wanted to run with it. That would be our first product, called Data XChange.
We got it most of the way done. It was pretty slick, and worked with Access, plus anything for which you had an ODBC driver, and most ISAM databases. As far as we knew anyway, and with a few issues such as not working properly with indexes from one particular database type.
I didn’t do the programming, and barely understood how the magic worked that my colleagues were performing. My job was going to be more in the realm of production and marketing, as well as helping with testing and support. I was chomping at the bit, seeing it virtually done. I even had the crazy idea of approaching Microsoft about packaging it with or marketing it to buyers of MSDN and/or Access. Audacious.
We ended up never releasing it. Not my choice, as my advice then was exactly Guy Kawasaki’s advice now. That was back in 1997. It was a combination of influences. One was the “it’s not perfect and we cannot release it until it has no bugs” outlook. Another was the “we didn’t write it using the latest and greatest object oriented programming and give it an SDK engine that can be used directly in programs by developers, so hold everything, I am going to rewrite it.” The rest was interpersonal issues between us, and differences between the “create products” and “provide services” outlooks on what the business ought to do. Multiple lessons in that, like the need for a coherent strategy, and a buck stopper or firm method of deciding on and sticking to direction.
The compromise was to create a free “Lite” version for download on our web site, while waiting for the rewrite. That handled only Access, none of the rest, by having the other options disabled.
The rewrite never happened, the product never got released, and within a few years was largely obsolete. Following the advice of getting the product out the door would have completely changed the course of our business, if only by providing a modest trickle of revenue and an incentive to rewrite or revise the program with corrections and improvements. And most of the problems or things that could have been improved would never have been a factor for most buyers. I consider this one of our biggest, if not the single biggest, mistakes as a business.
It’s good advice. If you have never been there, it may sound strange, or be difficult to accept it as such. I’ll definitely have to read the book sometime, and not just the buzz.