How Rogue Techies Armed the Predator, Almost Stopped 911, and Accidentally Invented Remote War

How Rogue Techies Armed the Predator, Almost Stopped 911, and Accidentally Invented Remote War:

On the afternoon of October 7, 2001, the first day of the war in Afghanistan, an Air Force pilot named Scott Swanson made history while sitting in a captain’s chair designed for an RV. His contribution to posterity was to kill someone in a completely novel way.

 

Commentary (Dak):  Ah, the power of a motivated team focused on solving problems rather than just serving the huge organizational process gods.  Those processes have value in terms of scale and defensibility of acquisitions for well understood technologies (K-rations, anyone?) but they have their downsides.

Advertisements

Clueless Companies Can’t Cope

I’m home sick today, so I’m a natural captive audience for free movies, or so I thought.

I was half-watching a movie on Crackle (Sony) on an iPad, and the “preach to the converted” ads for new RIM products were repeated so many times that, frankly, I lost count and I barely managed to finish the movie. The ads, that were amateurish at best, we’re repeated so many times that it made the product offerings look cheesy and irrelevant.

Continue reading “Clueless Companies Can’t Cope”

Quick article excerpt for the day…on Apple’s business strategy and software leadership.

Steve Jobs at the WWDC 07
Image via Wikipedia

There are many useful business strategies for companies, and many of these are executed successfully up to the point of a crisis, at which point the companies must re-invent themselves or die.  It seems to me that most hardware vendors (RIM, Motorola, Scientific Atlanta) are caught in a ‘how do we race to the bottom on price and still preserve our margins?’.

This article (Steve Jobs Speaks Candidly About the State of Apple and Its Competitors.) suggests that Apple does it differently.  There are many interesting points, but this one struck me as being especially important, both in illuminating Apple’s strategy, and in highlighting how real strategies must be explicit, not implicit, and sometimes reinventing the company strategy is the most critical thing that an executive can do.

“Because Apple looks at things from a software-driven standpoint first and then works to iterate and make the product better while keeping the price the same (or lowering the price), as it did with the iPod, the company doesn’t look at its line and make decisions based on features in order to lower the price, expecting the software to magically perform.”

In my opinion, Software requires real investment, process, and sustainability.  As a software leader, I guide the software team to make our work a key feature of what the company is offering to the customer, not an afterthought.  Apple clearly gets it.  Microsoft gets it (finally?); see Windows 7.

RIM *could*, if they make the Blackberry a great platform for developers, and see their own software on it as being pivotal.  RIM still has best-in-class email and instant messaging, and Outlook integration, but these advantages are starting to erode.  There is still time for RIM to awaken, but the clock is ticking…

Thanks again for reading,
Dak

Software architects and strategic decisions: Build, buy, open source, or partner?

I had a conversation today with a former colleague about implementing mission-critical software, and the cost assumptions of Agile methods. He cited “Balancing Agility and Discipline: A Guide for the Perplexed” as an analysis which says Agile assumes as an axiom that the cost of change is constant (in the front end engineering processes, not in remediation, fixes in the field, etc.) Frankly, I suspect that’s because Barry Boehm is a classic “programming in the large” guru, but I haven’t read the book yet. 

This is true (that Agile assumes constant cost of effort) in the sense that it’s held constant in the same sense of any other “assuming all other things are equal, we vary this.”  I see the point, but it seems to me that it’s not true in practice, in my experience, but then, I don’t think many people implement Real True Pure Scrum or Lean or XP or any other agile practices; they typically implement some kind of composite methodology, which merges specifications and design artifacts in the outer feedback loops of (for example) Scrum.

But he did have an excellent…nay, *superb* point: without explicit architecture work as an input to software development, development frequently gets caught in a cycle of relative local improvement, without being able to leap beyond the limitations of the existing or incrementally developed architecture, and sometimes that just won’t get you where you want to go.  I personally believe that these outer feedback cycles, including project kick-off, are the best integration points, and that most people practicing Scrum are working away with the “release and below” of the feedback loops, and neglecting release and multi-release planning entirely.

(I personally like the XP-style feedback loop diagrams on this page…to me, the architectural inputs belong in the outer feedback loop, with tweaking and involvement from the architecture team in the inner loops.)

To me, the point is that as software professionals, we have to be able to make decisions about what we’re going to build, buy, or integrate with, and this meta-decision can easily be a part of the Scrum, XP, or other Agile processes, and we don’t have to model the cost of the estimate purely by (for example) planning poker, especially when there are other costs involved. However, many organizations FAIL to make these decisions, instead always choosing to build, which leads to massive expense overruns, because they are trying to solve the wrong (software architecture) problem.

I’m looking forward to reading the book to see if it provides suitable guidance for practitioners in the field, both that I can use myself, and that I can reference to customers and employers. I generally find (both when working directly for an organization, or as a consultant) that some kind of ‘made to fit’ methodology is what’s really needed…and I haven’t seen that codified. Might have to do it myself, we’ll see.

Comments, insights, or experience are always welcome. More later after I read the book; I’ve always enjoyed Boehm’s work, so I’m looking forward to it.

Thanks,
Dak

The ongoing evolution of technology…Cameras

Digital cameras continue to evolve very rapidly.  (VERY).  Back in April, I passed on a link about a high-speed digital camera, reviewed by David Pogue of the New York Times.  Since then, the field has evolved to the point of having a DSLR that is capable of shooting movies. (And thanks again to Chris Schmitt for sending this along.)

Er, wow. This elevates the DSLR from the ‘better image quality, and, by the way, status symbol’ camera to a real, high-value imaging tool.  It’s also a brilliant move on the part of Nikon:  leverage camera owners existing lens investment; this is what marketing folks call ‘stickiness.’

Aside from being extraordinarily cool in its own rite, this is an important reminder:  innovate, or die.  If you aren’t working to obsolete your product line, rest assured, your competitors are!

Camcorders are now just waiting to shuffle off this mortal coil, in my humble opinion.

Regards,

Dak

A brilliant management two-for-one

There are two excellent ideas in this posting on ZDnet, aside from the observation that you can scale Ruby on Rails if you avoid hitting the disk farm for static content:

1) Have a team devoted to rapid scalable prototyping.  (LinkedIn Light Engineering Development)

2) Use free apps for both proof of concept testing and marketing.

Read and enjoy.

Ruby on Rails: scaling to 1 billion page views per month by ZDNet‘s Dennis Howlett — While a lot of attention has been focused on Twitter with questions about whether Ruby on Rails scales, LinkedIn has been quietly running a RoR application on Facebook that is beating down around 1 billion page view per month. Bumpersticker, a relatively trivial Facebook application that allows you to create a cartoon that you can […]

Best,

Dak

‘Free’ is always good for business

Now that I’ve got your attention, the next best thing to FREE is painless and predictable. Flat rate, as we know from telephony and other similar business models, reduces ambivalence about using a service, and increases the rate at which people BUY.

I received this in email today, and frankly, WOW.

Canada has, relative to the US, a low adoption of mail-order and therefore internet-order business models.

This is a pretty innovative way to get people over that hump. Good work, Ebay and Canada Post

Dak