Dave Rowley's Personal Blog

Old ideas about interactive, distributed apps reimagined in a mobile context

2011-09-02T13:14:00.000-07:00

Over ten years ago, my colleagues and I at Kenamea had some ideas about lightweight desktop apps and event-driven communication models that would allow them to interact with other apps over the internet. Here are some of the considerations that shaped our thinking.

HTML and javascript are pretty powerful, and developers who know how to build user interfaces in HTML and manipulate markup using a browser-based scripting language are more plentiful than developers who know how to write server-side code to implement business logic. We wanted to leverage the growing pool of front-end web developers who might be more accessible to the marketing and business functions within organizations funding web development.
To enable truly interactive applications that communicate with other instances of themselves and other applications/services on the internet, the request/response model of the web is insufficient. We need a reliable messaging infrastructure that provides event-driven communication (i.e. apps that can send and receive messages asynchronously), but do so in a way compatible with the protocols and scale of the web.
One reason web apps succeed is because they are more-or-less client-agnostic (browser compatibility not withstanding), and issues about version control and updates are virtually non-existent.
Web apps often use a lot of bandwidth re-delivering UI elements that don't change from page to page. I'm not talking about graphical assets that get cached by the browser, I'm talking about web servers resending page markup containing new data when really only the data has changed. A more efficient model for interactive apps is to only send new data to the client, and let client-side logic implement how that data is presented in the UI.
To be really useful, networked applications should continue to work, albeit in a limited capacity, when there is no network connection. Web applications typically fail in this regard.
Particularly in conjunction with the above, and to enable store-and-forward messaging, applications need to have non-trivial local persistence. An application-scoped local store of key/value pairs can go a long way to building really interesting client-side apps.

Back in the day, we addressed these considerations by building internet-scale messaging infrastructure (to accomodate issues 2, 4 and 5 above), along with a client-side app environment that allowed developers to build interesting apps in HTML+javascript, with access to services that address issues 1, 3, 5 and 6. Namely, these services included:

A platform-specific framework that runs applications built using HTML and javascript. Apps have access to javascript objects and events that provide bi-directional messaging services (e.g. send a message to an individual app instance, send a message to a topic to which all app instances listen, receive a message from an app or topic).
A facility for installing, registering, and updating apps. Once installed, the app instance is registered with the messaging platform so it can send and receive both point-to-point and topic-based messages. App updates are delivered as system messages, and the client-side framework manages the installation and data migration seamlessly.
App-scoped local store of key/value pairs, accessible via javascript.
Offline functionality—apps within this framework work offline since the HTML, javascript, and other assets associated with the app are stored locally, and the local store is always accessible. Outbound messages are queued for delivery when connectivity is restored, and inbound messages are queued in the cloud until the app reconnects.

Today, I read a lot of articles that state how HTML5 is revolutionizing mobile app development, because it addresses several of the same concerns we had back in the day. With the promotion of media objects as first class citizens in the markup, and the corresponding events and methods accessible via javascript, you can build some pretty interesting web apps without using platform-specific plugins. Also, HTML5 gives you real local storage. As HTML5 becomes broadly supported in mobile environments, I expect to see more sophisticated mobile apps using these features to implement functionality that was formally implemented using platform-specific compiled code.

I've seen some mobile app frameworks that allow you to build your app UI and business logic in HTML5 and javascript, then wrap that in a platform-specific (i.e. iOS and Android) container so it behaves like a native mobile app. This affords the features associated with native apps, such as presence in the app store, stickiness on the mobile desktop, and offline functionality. It removes the cross-platform burden from the app developer since the UI and logic are implemented in a cross-platform language. In many ways, this combination of a platform-specific container combined with platform-independent UI and logic is very similar to the framework we built prior to the advent of mobile apps.

I think there's still plenty of room for innovation in this area. Many of the concerns we had in 1999 about interactive, distributed applications are even more valid in the world of connected mobile devices. There is still a need for services such as:

an easily accessible, internet scalable, bandwidth-friendly messaging infrastructure,
a robust client-side app framework that provides store-and-forward messaging, app version management, and offline functionality,
a programming model that promotes bi-directional data exchange between applications and client-side control of presentation (vs. page-oriented request/response).

I can't help but think about how the lessons we learned building a desktop-oriented app framework back then could be applied to the eerily similar mobile app environments of today.

Thoughts on bubbles and cycles

2011-08-01T09:25:00.000-07:00

I was reading a post by Om Malik suggesting that our current bubble is about to burst, and it got me thinking about the former bubble and the times we are in today.

The bubble that peaked at the beginning of the millennium was marked by the transition of the web from a technology used to present content to a platform on which applications were built. People began using the web differently--they went from reading and watching to actually doing stuff. Companies emerged that built websites that allowed you to do things like manage your sales prospects and make purchases for digital and physical goods. There was no one single technology breakthrough that enabled this (although you could argue that J2EE and the app server was fundamental), but enough technology existed so a small team of reasonably skilled developers could implement relatively sophisticated web sites and apps. Once the bar was lowered on the true innovation and technical know-how required to launch a web business, the flood gates opened. And boy did it flood! Some of the businesses that emerged were pretty clever, but a lot were just plain stupid. Many had no basis for a sustainable business and relied on the heady buzz around all things web to gain momentum. That buzz fueled (and was fueled by) public and private investors who poured in absurd amounts of money to inflate the bubble. I count as friends a number of people who profited from this, but many more who did not.

During the bubble, I noticed the effect popularization of technology had on the make-up of the industry. People entered the tech arena from the edges, taking advantage of the growing surface area of the expanding sphere that had emerged. Companies where I worked prior to the bubble were made up of people who studied computer science in school and had been technologists their entire careers. Increasingly, I found myself working with people who had moved into technology from other areas, who had no previous tech experience but found themselves managing projects, designing websites, testing software, and promoting the capabilities we implemented.

I don't have any real insight on the web 1.0 bubble burst that you don't already know. Perhaps it was the realization by investors that even in a very optimistic world, many of these businesses were not sustainable. Expectations were beyond unrealistic, and investors made a bee line for the same flood gates through which they came. At the same time, our country was in sudden turmoil and the population in general had doubts about the future and withdrew from speculative investment and spending. When the burst occurred, many of the people that came into the industry from the outside were the first to leave (willfully or not). The icons that represented the era were now the butt of many jokes.

So here we are in a situation that many liken to those days ten years ago. The current bubble, in my estimation, is fueled by a few things. MySpace helped popularize a newish category of website that did a pretty good job of bringing in a population of users that had only used the web previously to shop and do occasional tasks. Social networks became an everyday habit for moms, dads, kids, grandparents and people wanting to hook up tonight. There were technological developments required to sustain this, like the ability to scale data-rich websites to ridiculous numbers of concurrent users, but these were mostly incremental developments rather than true breakthroughs. Many sites discovered their bottlenecks the hard way, and the successful ones quickly figured out how to cope. Cloud services made it easy for minimally-funded startups to build out a presence without any capital investment.

The other development that fueled the current situation is the advent of mobile. Smartphones and high-speed, affordable data plans let everyone interact on social platforms always. This isn't just a convenience, it opens up a whole new modality. Many clever applications of socal+mobile (and location awareness) have emerged, built by small teams of reasonably skilled developers. We are past the point where truly specialized knowledge is required to launch a business capitalizing on these capabilities. There are both clever and stupid ideas out there getting funded, even though experts are quick to point out that the IPO market and valuations pale in comparison to bubble 1.0. So this must be different, right? Investors demand to see revenue and a business model that sustains it, don't they?

The makeup of the industry, while still absorbing people from non-tech backgrounds, is more mature. The first bubble created career opportunities that dried up after the burst, but the underlying infrastructure in education and vocational awareness persists, so the character of the workforce doesn't seem as "green". People now have several years of experience doing jobs that didn't exist prior to bubble 1.0.

I anticipate there will be a peak and a fall of the current bubble. Maybe that time is now. I think that much of the gas of this bubble is the same that inflated the previous one (we are only human), but perhaps it isn't as volatile this time around. The technical underpinnings that helped fuel this round have broad applications, and the effect this technology has had on human behavior is profound. I imagine many businesses will cease when the this bubble deflates, and people I consider friends will be hurt. I trust those with aptitude, skill, and experience will quickly find new avenues for their talents. I hope sufficient real value has been created so even in a trough, new opportunities will arise quickly. I also don't expect this to be the last bubble I see in my career.

What has mobile done to your life?

2011-06-17T17:24:00.000-07:00

There's a lot of material out there about the effects of mobile-always-and-everywhere on your work/life balance, your ability to focus, the standards for table manners, and the development of your kids' brains (the damage you've already done to your brain probably dwarfs what your phone is doing). My professional life revolves to a great extent around mobile things, specifically delivering content to consumers on mobile devices and letting companies profit from doing so. I spend a good amount of time talking about the future-is-now world of mobile computing, continuous connectivity, and ubiquitous media consumption. Until now, I haven't really reflected on the impact this technology and the ecosystem it has spawned has had on me, personally.

First off, I am not really an early adopter of smartphones. Well into the smartphone era, I carried a feature phone useful only for making calls and exchanging texts. I rationalized this by claiming I wanted a phone that was good for talking, an ipod for listening to music, and a laptop that was good for computing. I used my disconnected time to do the things that didn't require an immediate and continuous internet connection, so I batched up outbound emails and produced artifacts that were stored locally and shared later, and cached inbound things for offline consumption. I was not particularly active on facebook and I didn't tweet or follow. It was OK that I didn't read all emails the instant they were received. It was OK that some times during my waking hours I was inaccessible.

At some point, it became clear that I was not as effective at certain things as I could be because I could not always respond to communications in real time. As my job began to involve more interaction with customers and as more customers began to use our service, it became critical to know what was going on all the time. I bought a non-iphone, pre-Android smartphone and suddenly my BART commute to work lacked the quiet time I used to fill with thoughtful email composition and other offline activities. I benefited by being hyper-responsive to customers and internal issues that required quick thinking and a quick response.

It didn't happen all at once, but over a short period of time, I became addicted to being connected. I had the classic symptoms--phantom phone vibrations, checking the phone on the toilet, waking up at night to check for incoming emails, etc. But more subtly, I've noticed that I can't not work anymore. Even when working for early stage startups, where you tend to put in long hours all through the week, it is possible to not work. This is different. It doesn't matter where I am--in the office, taking a walk at lunch, on a hike over the weekend--there's enough work activity to keep a steady stream of communications flying past me all the time, and I can't ignore it. I can pretend to ignore it, and I don't always respond to the incoming emails right away, but I know they are there, and they keep a certain percentage of my brain engaged in the work world.

I know this is a common syndrome. I don't know what effect it will have long term on productivity, innovation, cognitive development, and life expectancy. The impact on my quality of life has been mixed. I am probably more effective at my job because there is less friction in the flow of information (both incoming and outgoing) and I can respond to things as they occur. But I also find myself making more mistakes in my communications (from stupid typos and autocorrect hilarity to misunderstandings and misrepresentations), and the impact of attention sharing during face to face interaction is not positive. Since I think everyone is in the same boat as I am, I'm curious about your perspective. Feel free to share in the comments.

The Stupid Shoe Analogy

2009-11-16T09:31:00.000-08:00

“To really understand your users, you have to walk in their shoes.” Yeah, yeah…

The shoe analogy has got to be the oldest and most tired business cliché of our time. Everyone knows it, but customer service and user experience generally sucks, doesn’t it? Products fail all the time. Honestly, I have nothing to say about walking in your customers’ shoes, or eating your own dog food, or walking in the shoes of your dog, or any variation of the above, that you haven’t already heard. Yes, you should do it. It will open your eyes and possibly depress you, but you should do it. You know that.

Maybe there’s a different way to think about the shoe analogy that is a little more insightful and more specifically germane to agile development. I’ve worked for companies who invest significant time and resources on defining, scoping, designing, building and launching products that aim to serve an eager market. It might be fair to describe these efforts as user-centered or customer-focused, because a great deal of study, market research and customer advisory board interaction goes into the process. Tremendous planning and logistics are required to prepare the organization for the launch of the new product and to tell the market that finally the product they’ve been waiting for is here. Sometimes the organization is prepared and the market rewards them by adopting the service, making it a success. But on as many occasions I’ve seen the organization stumble and the market respond with indifference.

It’s beyond me to know why some of these efforts succeed while so many others fail. Is it luck? Timing? Key contributions by particularly gifted individuals? Perhaps some or all of these factors are causal, or perhaps none of them are. In the last 10 years, I’ve typically been involved in a different sort of effort that involves focusing on a small but very concrete target with a well-understood use case and delivering a product that just barely satisfies the requirements. Obviously the solution has to be complete enough to make it a differentiator for the early adopters, but the first and subsequent releases usually involve some amount of pain and discomfort (for both me and my customers). But without a lot of fanfare, we have a shoe that basically fits.

What happens next can be at times tumultuous and instructive, painful and rewarding. You will either develop the skills that lead to transparency, commitment, agility and trust, or you will suffer and fail. I’ve frequently done the former while thinking I was doing the latter. By being transparent about what your product does and does not do, committing to stay close to your customer to feel where the fit is poor, and being agile enough to deliver improvements quickly and repeatedly, you develop trust. And when your customer comes to trust you, they give you permission to fix what’s broken and deliver to them new solutions to new problems. Your offering grows, and while your competitors are conferring with their customer advisory boards, you are on to the 2.0 release.

So my take on the shoe analogy is to make a shoe that basically fits a particular foot. Feel where the pain is and shape the shoe while you are walking. Become sensitive enough to know where the blisters will form before they actually do, and adjust as necessary. Shaping shoes is not as glamorous as talking about them or deciding what trends will be in fashion next season, but that’s what we do.

Has Over-The-Air Delivery of Audio and Video Changed the Definition of Downloadable Media?

2009-05-04T12:16:00.000-07:00

Posted this on the Association for Downloadable Media's website. Reposting here.

Last year, the advent of the iPhone was heralded as the beginning of a new age for mobile content delivery. Bloggers, analysts, and industry insiders urged publishers to quickly adopt a mobile strategy, deliver their content in iPhone-ized web pages and iPhone apps, and follow consumers as they flocked to this platform. According to recent reports, that was good advice. AdMob reported in February that the iPhone generated a third of the global smartphone traffic, and half the traffic in the US. But consumers also view digital media on their Blackberry Curves, Pearls, Storms and Bolds—not to mention the up-and-coming Android phones. As the number of platforms that support over-the-air delivery of high quality audio and video grows, how does this impact the way publishers think about downloadable media?

For a long time, we’ve struggled to make the distinction between “downloads”, “progressive downloads” and “streams”. In the mind of the consumer, it’s all a bit of a mixed stew. Consumers select media to watch or listen to, and it starts playing sooner or later. They may play that content while connected to the internet (via wi-fi or a cellular network), or perhaps they’ve saved it to play on a non-connected device. More and more, the device they carry with them allows access to live media delivered on demand. Is this still downloadable media?

Rather than characterizing the content you develop based on the method of delivery to the consumer, your focus should (obviously) be on the quality of the content itself, and then delivering it in a way that is compatible with consumer habits. As consumers expect to find more rich content on demand from their smartphone, it behooves publishers to make it available that way. Assumptions made about the delivery method (for example, assuming all content will be delivered to iPods via iTunes) may impact the systems you have in place for monetization. It’s probably time to revisit those assumptions in light of the growing trend for over-the-air streamed delivery.

If the world were made only of iPhones and iPod Touches, accommodating direct delivery of media would be rather straightforward. Despite the success of these devices, the universe of video-capable smartphones is still a rather (and increasingly) fragmented space. The video formats, encoders, resolutions, and even delivery protocols vary across devices and carriers. Reaching these disparate platforms does not necessarily require an on-deck solution with every carrier, but there are dimensions to this problem that don’t exist in delivery and playback on the desktop, the iPod, or iPhone. Emerging solutions exist that simplify this problem for publishers, and depending on your monetization strategy (for example, direct ad sales and trafficking vs. an ad network) and the level of control you wish to have over distribution, there may be a system that works in conjunction with the methods you’ve used for “traditional” downloadable media.

If you haven’t done so already, it’s probably time to start thinking beyond the iTunes/iPod-centric notion of downloadable media distribution. And if you’ve just extended your thinking to the iPhone/Touch, there may be opportunities you’re missing on other video-capable devices. Vendors will endeavor to address the publisher’s need to deliver content to consumers where ever they can, while making this process as simple as delivering content to the desktop browser. Successful publishers will know the constraints and opportunities created by this expanding universe of playback environments, and leverage these solutions to their benefit.

Answering the call, building better engines

2009-01-22T14:18:00.000-08:00

As we enter a time of new leadership in the White House and a renewed sense of service and participatory democracy, and as we face fiscal challenges that most of us have not seen in our lifetimes, I’m sure I am not alone in wondering how best to contribute to the effort of recovery and forward progress. There are many opportunities for social service, and in as much as consumption drives the economy, ways in which we choose to spend and invest our money that will have the potential to trickle up and infuse the market with the cash and resources it has lost over the past twelve months. Like every citizen who feels a certain call to action, I will contribute in these ways as best I can. But personally, I think the most influence I have to make a positive contribution is based on my ability to help build a prosperous business.

To me, creating a successful business is a matter of leveraging the skills and know-how of a small group of people to deliver a service that provides value worth more than the investment to build it. In my current situation, it is a matter of providing a service to customers that allows them to effectively serve their constituents and provide offerings that lead to monetization and profit. Specifically, it’s a matter of letting publishers provide appealing inventory to advertisers, and helping them deliver an engaging experience to consumers so they want to spend their time enjoying that content (which drives the former). If my business allows publishers to do this in a more efficient manner than they could without my service (or that they could with a competing service), or if it allows them to offer a better and more interesting kind of product, then my business will be successful. It’s simple, really—but not easy.

If the law of conservation of energy can be metaphorically applied to the business value chain, somehow value must be preserved in this ecosystem. If you think of a business as an engine that takes in value and generates greater value, you must account for that discrepancy in the system. The ability of the engine to generate value is based on the capabilities of the people who make it up and their ability to innovate and develop technology to make their internal processes efficient. No matter how great the output of this engine, if it costs more to run than the value it produces, it will soon run out of fuel. And in these times, you either need a very large gas tank or a very efficient engine. My experience is that it has become difficult to fill a large tank, particularly if you can’t show that your engine has the potential for excellent mileage.

As someone responsible for building, tuning and running the engine, I have only a few big levers I can operate to make this work.

Build a team that has the right makeup to execute effectively and efficiently. That’s not just a matter of hiring smart people; it’s a matter of finding the right combination of people who will optimally serve the needs of the business. The needs of each business varies, and the needs of a single business will change as the environment changes, so there is no single formula for doing this well.
Make sure the team is working on the right thing. Since the efficient engine will excel, lost cycles are like a leaky gasket. One could argue that this type of thinking leads to safe bets that attempt to minimize risk, and this leads to a lack of creativity and innovation. I suppose this could be the case, but even planning for exploration and risk-taking has to be done efficiently, and you have to be smart about where you place your bets.
Make sure that the processes we use to build and operate our system are as efficient as possible. This sounds like a platitude, and I suppose it is, but the real complexity of this has to do with optimizing for the situation and the resources available. There are certain things I know I can’t do because I don’t have the expertise or resources in-house, and the cost of attaining those things vs. the operational lift they provide does not warrant the investment right now. Again, this influences who is on the team—the combination of their capabilities must be able to implement the processes that deliver overall efficiency for your current situation. As the situation changes, the calculus for obtaining those efficiencies also changes.

Assuming I can build an engine that is tuned for the current situation and successfully delivers more value than it burns, and thinking back to the conservation of energy, where does the extra value come from? Expanding on the metaphor, while energy in a closed system is conserved, it can change form. I would suggest that in our tuned engine exists potential energy which, based on the innovation, knowledge, and abilities of the team, is turned into kinetic energy. That potential energy comes from the investment made by the business and members of the team to acquire, hone, and coordinate their skills.

Our new president has asked us to become involved in implementing the changes necessary for us to prosper as a nation. I am committed to doing so by helping build organizations that deliver value and prosperity to both the businesses they serve, and also to the members of the team who make up the engine. I realize that I might not be successful in all of my attempts at doing this, but it’s perhaps the most impactful thing I can do. My other endeavor will be to raise my children in such a way that lets them build their pool of potential energy so that it can be transformed into a state that directly serves the world in which they live.

The evolution of avian flight and parallels to technology-centric systems

2009-01-02T15:27:00.000-08:00

If you find yourself in a bar with a bunch of paleontologists and want to start a fight (who wouldn’t?), bring up the topic of evolutionary development of flight in birds. You see, there are multiple schools of thought on how avian flight evolved—jumping from trees, wing-assisted running and hopping, pouncing on prey—and no clear winner has emerged. But all schools generally agree on the physiological factors required for flight to occur, and even a layman like me can appreciate that flight is a very expensive proposition. The muscle-to-weight ratio has to be high, so birds lose heavy things like teeth and solid bones, and develop structural characteristics like a large “keel” bone to which the powerful wing muscles attach. If you’re a flying bird, especially a flapper rather than a glider, you spend a good portion of your waking hours eating, to supply the fuel you need to get around in the air. Species that can fly have great advantages over flightless competitors. Flyers can cover a lot of ground, migrate to accommodate seasonal weather, escape from predators, and attack prey from above.

It is an interesting evolutionary phenomenon that occurs when the advantages of flight no longer outweigh the cost—birds stop flying. For example, bird species that live on isolated islands with sufficient food to support the population and lack ground-dwelling predators no longer need to fly, and therefore, they lose that ability. They get skeletally heavier, larger, and lose their strong flying muscles. Of course these adaptations to the local environment make these species particularly vulnerable to the introduction of external species that compete for food or become predators. But I think it’s interesting that evolution is not just survival of the fittest, it is survival of the most efficient. A more efficient species will thrive when the conditions are right.

So why am I writing about avian flight when I usually write about technology and digital media? I think there are some relevant parallels to technology-centric systems and the impact of the environment on how these systems evolve. In a highly competitive environment, particularly when the needs of the consumer challenge the technological state of the art, solution providers must take relatively costly measures to compete. For example, a digital media distribution system might have to control all aspects of the solution—including production, hosting, and presentation—to provide an offering that meets the needs of the market and satisfies the consumer. As the state of technology develops, certain facilities that used to be the core intellectual property of the solution provider become commodities. It is no longer necessary for the provider to own all aspects of the overall solution, and in fact, it is not efficient to do so. The cost of owning and controlling all aspects of the solution is no longer an advantage, and solutions that leverage commoditized technologies without owning them are able to compete more efficiently. And any business environment, like nature, favors a competitor who can meet the needs of the market (i.e. survive effectively in the ecosystem) most efficiently.

Technology limitations shape solution set

2009-01-02T09:16:00.000-08:00

When technological factors such as bandwidth, client device capabilities, and media format compatibility limit the ability of publishers to deliver an acceptable consumer experience, digital media distribution and monetization solutions must be highly optimized to provide a competitive offering. This was the situation in the early days of digital video on the web, and the solutions that provided the best consumer experience were generally vertically integrated and highly proprietary (e.g. Brightcove). Tight vertical integration was necessary to deliver the best performance given the constraints of the technology available. As the underlying layers of the technology stack matured—mass availability of broadband internet, the commoditization of content delivery networks, de facto media format standards, and the ubiquity of Adobe Flash on every browser—fully integrated vertical solutions were no longer necessary to deliver the experience consumers demanded. Publishers were able to choose best of breed solutions at each layer of the stack.

As digital video moves on to wireless mobile devices, the natural effect of these forces is seen once again. Early technological constraints favor tightly integrated solutions that squeeze maximum performance out of the contributing systems. As the infrastructure advances and standards emerge, publishers have options that don’t require a single-vendor solution. Perhaps no recent advancement is more significant than the emergence of the Apple iPhone on the mobile scene. The capabilities of this class of device and underlying services set the stage for a new phase of mobile digital video, one where control moves out of the hands of single-point solution providers and into a more open field.

Next I'll look at how these factors open the door for carrier-independent, over-the-top mobile video and the implications for vendors who play in that space.

Thoughts on the evolution of digital media publishing

2008-12-31T08:31:00.000-08:00

Technological capabilities and constraints have shaped how publishers make their content available to consumers on the Internet, but certain fundamental business and economic forces drive the evolution of technology and the industries involved in the publishing, delivery and monetization of digital media. The business forces that influence publishers as they choose digital media solutions stem from three basic objectives.

Control the distribution, presentation, and monetization of their premium content
Maximize the monetization opportunity
Reduce costs by implementing efficiencies derived from workflow optimization and economies of scale

These objectives directly influence the course of the industry that serves digital video publishers, and favors a market that provides competitive offerings at each layer of the solution stack. Best of breed solutions can be integrated by publishers, allowing them to control delivery of content to consumers in a way that maximizes monetization and offers workflow efficiencies. Vertically integrated solution providers have given way to horizontal layers that compete with one another, allowing the publisher greater leverage on cost and control.

I'm doing some research into how the business forces that drive publishers impacts the nature of the solutions that are available to deliver digital media—specifically digital video—to consumers on the web and via mobile networks. While the interaction of technology with these business drivers has a broad impact on the solution space, I'm paying special attention to systems that provide monetization options. More to come...

Size matters, but experience is what counts

2008-03-17T21:59:00.000-07:00

Two of the three startups I’ve worked at have had large enterprises as customers. SNOCAP, the one that didn’t sell to large enterprises, partnered with them (e.g. the major record labels). Large companies tend to be leery of small startups, especially when they trust them to perform a critical service or rely on them for something that is highly visible. This puts us, the startup vendor, in the position of having to jump through hoops to show our maturity and prove that we are worthy of the business, and that doing business with us does not pose a significant risk to the corporation’s operation or brand. In this familiar situation, we have to make up for limited human resources with maturity and professionalism at every point where we interact with the client. A combination of limited resources and rookie behavior is the kiss of death to a startup trying to compete for a Fortune 500 deal.

An important thing to consider is the difference between experience and size. Early stage startups are small, but not necessarily lacking in experience. As a startup, it’s important to deeply understand all the functions that must be performed to successfully run your business, and then boil them down to their essence and perform them with a very small team. That need tells you something about the makeup of your early stage team. It also helps guide your interaction with your customers, since they are trying to determine whether your maturity is proportional to your size.

One thing I try to keep in mind when dealing with a large prospective customer is that even the biggest corporation is made up of individuals, and these individuals are the same size as we are. In other words, we have to prove ourselves to the people with whom we directly interact, not some faceless corporate entity. You win a corporation’s trust one person at a time.

The truth about CD Baby and SNOCAP

2008-03-06T17:12:00.000-08:00

I had held off on posting this on 10/7/07, but decided to do so now. Most of it is moot, but I figured I'd share my thoughts none the less...

There have been a number of recent comments about the announced "split" between CD Baby and SNOCAP. The tone of some of these comments is rather negative, or at least infer that SNOCAP dropped the ball somehow. Having been close to the situation, I have a perspective on this, although mine is not an official SNOCAP perspective or necessarily endosed by SNOCAP or CD Baby.

CD Baby was a mis-fit for SNOCAP, at least in the way that they engaged. SNOCAP treated CD Baby like an aggregator, similar to The Orchard or IODA. CD Baby is a distributor for indie artists, and not a label aggregator. Aggregators, like major and indie labels, deliver their content to SNOCAP in batch. SNOCAP must then process this content and determine how to map it to SNOCAP MyStores in a meaningful way. This is harder than it may sound, since the concept of a store widget is not part of the metadata language spoken by a record label. For independent artists who sign up directly with SNOCAP and assemble their MyStores by hand, it's an interactive, individual operation performed by the artist. These hand-crafted stores are then placed on MySpace pages and elsewhere. When dealing with labels and aggregators, this operation must be automated, and it's not a perfect process.

CD Baby delivered the content of its members to SNOCAP in batch. SNOCAP created stores based on artist information delivered by CD Baby, but sometimes artist information varied, so the mapping of stores to artists wasn't accurate. When artists wanted to adjust their stores, they had to log in to SNOCAP with a sub-account created on their behalf by SNOCAP with information from CD Baby. The login information was delivered to them via email from CD Baby, but it frequently was not delivered successfully. If artists wanted to add new content to their stores, they would have to submit it to CD Baby and wait for the batch update to be delivered to SNOCAP.

SNOCAP and CD Baby struggled to provide good customer service to these artists. If an artist attempted to upload tracks to SNOCAP using their own account, and the same tracks were delivered to SNOCAP by CD Baby, they would be flagged as "in dispute" by the SNOCAP content identification system. If artists were actively using the SNOCAP MyStore to sell music online, they were advised to ask CD Baby to withold their content from the batch feed, and to create their own account with SNOCAP. This approach has now become the default, per the announcement referenced in the sited links.

CD Baby and SNOCAP share constituents--they both serve indie artists. It is unfortunate that the nature of their partnership didn't yield a service with a value greater than the sum of the parts. I think that a more natural relationship would have been an affiliate relationship, where CD Baby artists could be referred to SNOCAP and vice versa, with a financial benefit for doing so. Hopefully the imperfect nature of the relationship between these two companies doesn't sour artists' impressions of either, since any mishandling was an artifact of the imperfect data being shared between companies. Could they have done a better job? Perhaps, but not without significant investment by both companies to expand the nature of their technical integration.

Startup reflections

2008-02-14T10:33:00.000-08:00

As I watch a former employer of mine wind down its existence as an independent entity, I am struck by the commentary from those who claimed to have been involved with the company, particularly when they cite corporate incompetence as the reason for a lackluster exit. It’s easy to dismiss uninformed claims made by people not directly involved in the process, but more remarkable are claims made by people who had every opportunity to voice their opinion or affect change during the formative stages of the company. And it seems this is a pretty common occurrence—if you read the comments (mostly anonymous) on any techcrunch article describing a bankruptcy or acquisition, they are filled with insiders sniping at the people who somehow, singlehandedly, got in the way of success. It’s pretty rare that an individual has that much control over the situation in a corporate environment.

I’ve been through this a couple of times, and I take time to reflect on the experience to gain as much positive learning from it as I can. Here are some observations I’ve made that are consistent with my experience in multiple startups.

Startups are generally made up of smart people. These people have their strengths and weaknesses, and their past experience shapes their perspective on things, for better or for worse. They are often very good at something, and that’s what got them where they are.

At the early stages, the core team may fluctuate as aggregate competency gaps are filled and an individual’s strengths are matched up to the needs of the company. Someone who is very good in a particular area might struggle because that area of strength is already filled, and another need is left uncovered. Sometimes this process of reaching equilibrium is later interpreted as thrashing or management chaos.

Companies are formed based on a hypothesis. Sometimes this hypothesis is established by seeing a market opportunity and imagining a business that can capitalize on that opportunity. The implementation of the solution is a detail that must be worked out. Other times, the hypothesis is based on a working solution to a small problem, or a perceived problem, and then growing a business around that—expanding the existing solution to new problems and new markets. Both approaches can work, but each has its own risks and issues. The management team makes a series of guesses—experiments—observes the results, and modifies the hypothesis accordingly. Mistakes are made when the results of the experiments are not factored back into the plan, but these are easy mistakes to make.

Even when the hypothesis is modified based on the result of experiments, it is still just a hypothesis until proven valid by the market. I’ve seen smart people make informed, well-considered, decisions about the direction of the company. I’ve participated in those decisions and agreed that they were the best course of action given all the factors in play. Sometimes they lead to success—experiments supported the new hypothesis—but they don’t necessarily result in a sustainable business. There are only so many experiments you can afford.

I feel somewhat qualified to second-guess decisions that were made in the start-ups with which I’ve been involved. Faced with the same conditions in the future, I will use the body of experimental results I’ve observed to inform the current hypothesis, whatever it may be. But I realize that with the sheer number of variables involved, I will likely not see the same conditions as I’ve seen in the past. I know I will find myself in the midst of a team of smart people, each with our strengths and weaknesses, interpreting the experimental evidence and striving to make the adjustments that lead to success.

Job Post: Principal Software Engineer

2008-01-25T15:59:00.000-08:00

If you're interested in this position, contact me at drowley[at]kiptronic[period]com.

Kiptronic is a venture-backed technology start-up that provides dynamic, targeted ad insertion software for major media publishers delivering video and audio to disconnected devices. Based in San Francisco, Kiptronic offers an amazing ground floor opportunity to join an exciting start-up in the rich media advertising space.

We’re building a well-rounded engineering team that uses agile development methods to deliver high value, high quality products to market in short, iterative cycles. Members of our team must be disciplined software engineers with the ability to communicate very effectively in a cross-functional group, and possess a strong testing mentality. We’ll use practices like test driven development, continuous integration, and pair programming. We’ll build systems that are elegant in their simplicity, inherently scalable, and focused on delivering value optimally. We’re a small team that works efficiently to get a lot done.

This is a very senior technical position in our engineering organization. You will elevate the level of the people around you, and you will provide thought leadership on system architecture and design. You have a broad software development background and the experience to make informed decisions about technical direction.

What You’ll Do:

Lead the software design effort on major new system features and components
Write software that leverages your expertise in highly scalable and performant server systems
Coordinate the interaction of and interfaces between components in all layers of the system architecture
Mentor other members of the team on system architecture and design

What You Know:

Required

B.S. or M.S. in Computer Science.
10+ years experience in software development
Expert Java skills and object-oriented design experience
Expert in the design and development of distributed systems and hosted applications
Experience building Java web applications using Servlets/JSP, Struts, and Tomcat
Experience developing software in C/C++
Strong experience with source code control systems like CVS and Subversion
Software development under Linux and Windows
Experience with Spring and Hibernate
Experience with Apache-Jakarta tools and libraries
Experience with agile development processes such as XP or Scrum

Desired

Experience developing Apache modules
Experience with database design and SQL, PostgresSQL is a plus
Experience with video/audio codecs

How You Think:

You are agile, adaptable, and like to be involved in a variety of technologies
You favor simplicity over “elegance”
You like to test as you go
You prefer incremental development over the big bang

Job Post: Director of Technical Operations

2008-01-25T15:38:00.000-08:00

If you're interested in this position, contact me at drowley[at]kiptronic[period]com.

Kiptronic is a venture-backed technology start-up that provides dynamic, targeted ad insertion software for major media publishers delivering video and audio to connected and disconnected devices. Based in San Francisco, Kiptronic offers an amazing ground floor opportunity to join an exciting start-up in the rich media advertising space.

We provide a 24/7 software service used by some of the largest media publishers in the world. Maintaining high availability and best of breed professional services is critical to our success and core to the charter of our Technical Operations organization. We favor the prudent use of open source infrastructure and commodity computing resources over proprietary or single source solutions. At the end of the day, however, it’s the quality of our service that matters to our customers.

This position is responsible for operating our platform and managing the resources used to run it. You will provide technical oversight for the assets in the datacenters we use, as well as our internal computing systems. You will own vendor relationships for the IT services on which we rely to run our business. Additionally, you will manage the people who provide technical integration services to our customers and partners. To be successful, you will have a strong system administration aptitude along with professional customer-facing skills.

What You’ll Do:

Operate our hosted ad serving platform running in external datacenters to meet availability requirements stated in our published SLAs

Maintain the hardware and software systems used by engineering for product development

Maintain the IT systems (email, internet services, phone system) used by all members of the company

Manage a professional services function that provides technical support for customer and partner integrations

What You Know:

Required

B.S. or M.S. in computer science, electrical engineering, business or information technologies, or equivalent related degree

10+ years experience in information technology, system administration, and/or network operations

3+ years experience performing and/or managing a technical professional services function

Experience running a high availability commercial software service

Experience running a distributed Java-based web application using open source infrastructure like JBoss, Tomcat and Apache

Deep understanding of virtualization technology, clustering and security

Expert system-level troubleshooting skills

Expert Linux/Unix system administration skills, with an emphasis on daemons, networking, monitoring, shell scripting, and performance tuning

Familiarity with the role and function of content delivery networks in media-serving environments

Expert Apache configuration experience. Familiarity with common Apache modules.

Experience managing large relational database deployments, PostgreSQL preferred

Experience deploying and running distributed system monitoring software like Nagios or Hyperic

Desired

Experience providing desktop support for Windows and Mac systems

Experience managing outsourced email services or administering a Microsoft Exchange server

Experience debugging network issues at all layers from physical to application

How You Think:

Five nines is achievable

You build Linux kernels in your sleep

You thrive on solving challenging problems.

You want to be part of a growing and enthusiastic startup team.

Outshout!

2007-12-06T21:24:00.001-08:00

Association for Downloadable Media

2007-12-04T21:38:00.000-08:00

I was recently elected as the Association for Downloadable Media committee chair for terminology standardization. If you're interested in joining this committee, become an ADM member and email me at terminologystandardization@downloadablemedia.org.

This should be an interesting experience, and a great opportunity to exchange views with other folks in this broad area of interest. With their collaboration, I hope to deliver a taxonomy that will help describe, promote and distinguish the various aspects of downloadable media.

Vision to plan

2007-08-22T09:39:00.000-07:00

I want to communicate to my new team the type of activity I see as key to a fluid agile development process. I’ll do this by talking about what goes on during the various stages of development. I will introduce some scrum and XP language, but I don’t necessarily want to imply the complete Scrum or XP methodology at this point.

I plan to send some form of the following to the team.

Requirements Formulation

Business stakeholders (sales, marketing, other execs) contribute requirements in the form of capabilities or features for the system. These requirements are described in the language of the business or the user, typically as use cases, and include acceptance criteria (e.g. “this feature is considered complete when you can do the following things….”). Product management helps describe these capabilities as discreet features that are decomposed to the level that makes sense when evaluated individually (i.e. an individual feature adds incremental value to the business), but are not aggregated unnecessarily (i.e. all separable capabilities have been separated). The product manager facilitates the prioritization of this feature backlog, and this backlog is reviewed frequently.

Feature Selection

At the outset of a sprint, the development team (all people who will do work to implement and test the product features) meet with the product manager and business stakeholders to review the feature backlog. Since the backlog is in priority order, the team selects features from the backlog top down. Based on the feature description, they make a rough estimate of the effort required to implement it. Developers sign up for work on features and track the amount of time they have committed. When all developer time is used up (the time allocated by each developer for the sprint), the feature selection is complete for the sprint.

Task Breakdown

During feature selection, a certain level of rough task breakdown is done to know how much time each person can commit. Immediately after feature selection, the team breaks down each feature into the engineering tasks that must be done to implement the feature. This requires some design and coordination, since the tasks should be to the granularity of hours (typically no more than 48 hours per task). The team may bring in product managers or other stakeholders to clarify requirements or propose certain design alternatives. After the task breakdown session, developers should know enough to begin work.

During Development

Developers write code that implements functionality as defined by the sprint feature set. Unit tests (i.e. tests that exercise this code at the object or method level and are minimally dependent on other components of the system) are developed together during the development phase of the sprint cycle. QA engineers may collaborate with development engineers during this process to help write good tests and so that QA understands what sorts of unit tests exist. Developers also provide QA engineers with input on the test plan that will be executed after the sprint development is complete. This collaboration is strongly encouraged.

During the development of new functionality (or fixing bugs in existing functionality, or refactoring existing code to make the implementation simpler), the component(s) being modified are tested locally, or in some shared development environment.

Code that implements the new/changed functionality and the code that implements the unit tests are submitted together. Code isn’t submitted until the best reasonable effort has been taken to show that the submittal doesn’t break the build or break the integration with other components in the system. Ideally, this is accomplished by running a suite of integration tests locally that checks that the contracts between components are still valid.

Continuous Build and Test Process

A build and test process is continuously running on a dedicated build and test server. This process monitors the source code repository and determines when changes have been submitted. It then:

Synchronizes a local filesystem with the target version (e.g. the head of the codeline trunk)

Invokes makefiles/scripts that build each of the components

If the builds succeed, the built and tested system is packaged and deployed into the build and test environment

Runs the automated tests against the system and reports test results

If either the build or tests fail, the users who checked in changes since the last successful build and test are notified by email

To make automated test development as simple as possible, a test framework can be used. Tests implement an interface that is run by the framework. A mechanism exists to add tests to the suite that is automatically executed. It is sometimes desirable to partition the test suite so that some tests are run more frequently than others (e.g. a relatively small “quick check” suite that is run continuously during the day and a “full check” that is run overnight). Test frameworks like JUnit, CPPUnit, NUnit, and HTTPUnit work like this, and can be used in conjunction with automation software like CruiseControl or Anthill.

End of Sprint Process

At the end of a sprint, a build that has passed the automated build and test process is deployed into a QA/Staging environment. A branch is created in the code repository corresponding to the build. The QA team runs through the test plan developed for the sprint (which includes regression testing and new functionality testing). Performance benchmarks may be taken at this point and compared against previous builds.

When bugs are found during the QA process (typically while development on the next sprint is underway), the bugs are fixed in the sprint branch and integrated into the main trunk. Developers involved in the fix sync their local filesystem to the version of the code in the sprint branch and debug and test locally before submitting the change. The build and test process is run against the sprint branch. The resulting package is redeployed in the QA environment.

Production Deployment

When a release candidate build has been qualified, the package representing that build is deployed into the production environment. If necessary, migration scripts are run against the production database.

Communicating my ideas for the process

2007-08-20T21:08:00.000-07:00

I find myself already reviewing resumes and providing input on what software licenses should be approved. I have access to wiki pages containing issues and dev plans. The good news is that progress is being made, and issues are discussed and attacked in a shared forum. The first thing I think I must do is communicate the vision in my head of how I’d like to see software development work. Hopefully that will generate discussion around what’s already being done, and perhaps even what’s been tried before. So while I want to communicate my vision very clearly, I don’t want to undo any progress and learning that the team has already made.

The process I propose will borrow from my experience with agile methods. I’ll use some of the scrum formalisms that I’ve found useful to get both the business and engineering teams working from the same prioritized list of features. I’ll mix that with some XP practices that I feel are critical to efficiently release software in short iterations.

When I refer to an agile development process, I mean one that favors adaptation to changing business and technical conditions over one that is optimized for any one situation. Some basic principals that guide me are:

Use incremental delivery to allow learning—I acknowledge the fact that I don’t know everything about the requirements or design associated with a product release at the outset of its development. Incremental checkpoints allow me to reflect on what’s been built, and learn whether we are achieving the results that provide the business the most value.

Use incremental delivery to reduce risk—I use incremental milestones to evaluate the risk associated with the development trajectory. These checkpoints allow the organization to assess progress against objectives and evaluate technical risks as early as possible. By requiring the quality of each incremental milestone to be at production levels, we never allow the code line to drift into a state of severe instability.

Use incremental delivery to increase flexibility—the team needs to be able to quickly deliver functionality that the market (e.g. a pending deal) demands. To enable this capability, it is important to order feature development according to the business value of the features and revisit those priorities very frequently.

Simplicity over “elegance”—resist the temptation to develop a complex architecture in anticipation of future functionality. I believe it is more cost-effective to pay the incremental costs associated with keeping the implementation as simple as possible, along with the cost of extending that implementation when necessary to accommodate new features, than to pay a high up-front cost to build a complex architecture in advance of requirements combined with the cost of maintaining that architecture over time until the new functionality is required. Also, I recognize the likelihood that the future-looking architecture will not be needed, or at least will need to be significantly revised when the future requirements are eventually implemented.

Proactively refactor to achieve simplicity—keeping the implementation as simple as possible is a process, not an end. Project planning must accommodate time for refactoring, and the organization must be willing to pay these costs.

Use infrastructure to enable safe refactoring—testing infrastructure and process must be continuously in place to provide immediate feedback when a refactoring effort has inadvertently changed the behavior of the system. The organization must maintain this infrastructure to effectively develop product features using these principles.

Promote cross-pollination—allow individuals to work in a variety of areas of the product and to become proficient in a variety of technologies. Encourage collaboration and pairing during design, development, and testing—especially between engineering functions. A cross-pollinated development organization is able to adapt to new constraints and opportunities more quickly than a highly-specialized organization.

Favor existing technologies and implementations over home-grown solutions—resist the temptation to build it yourself when robust, stable, and standard open-source implementations exist.

Next, I’ll talk about the process and practices I’ll propose to the team, and maybe how I go about communicating this vision to them.

New Kid in School

2007-08-17T19:45:00.000-07:00

After two good and satisfying years at SNOCAP, I’ve made the tough but important choice to move on. I'm going to be running engineering and product management at Kiptronic, and I'm very excited. Over the course of time since I last did this, I’ve come to realize some important things about myself.

I can do a lot of different things, but there are some things that I’m better at than others. The things I do particularly well are the things most valuable when a company is in its formative stages—building its teams, establishing process, and creating new products.

I don’t do well when there are too many cooks in the kitchen. When I have strong ideas about product direction, I get frustrated when design by committee prevails. I’m all for collaboration, but a singular vision aggressively executed is how rapid innovation happens.

The people I work with are more important than the industry I’m in, the size of the company, or just about anything else. For whatever reason, our culture seems to discourage the open expression of our personal feelings in a professional setting. That’s bullshit. I want to let my colleagues know how I feel about them. Hopefully, that means I’m letting them know that I like them. Having strong personal connections with the people I work with is more important to me than I had previously thought. Without those connections, I begin to drift.

Now I don't want to suggest that all of these elements were missing at SNOCAP (someone pointed out that these comments could be interpreted to reflect negatively on SNOCAP). SNOCAP was a great experience for me. These are just things that I've learned are very important to me, wherever I go.

Changing companies not only feels like going to a new school, it feels like going to a new school midway through the school year taking classes I’ve never had before. It will force me to use all the social skills I’ve developed since I first started making new friends on the playground, along with my ability to pick up new subjects on the fly. But that’s the rush—and since I’ve done it several times before, I know I’ll be able to do it again. It’s cathartic for me to jot down my thoughts on this experience here. I’ll continue to document my efforts in building the team, putting pragmatic process in place, and driving product direction until it’s no longer satisfying to do so.

Fun with Pandora

2007-08-07T13:04:00.001-07:00

Thanks to some help from the Pandora guys, I was able to create this nifty little mashup. Using a javascript event API from Pandora, I register a javascript callback that is invoked when a new song plays in the embedded Pandora player. I get the artist name and track title from an object passed to the event handler, then construct a URL that passes these as search terms to the SNOCAP Search API. I use a simple roll-your-own AJAX call with the XMLHttp/XMLHttpRequest object to fire off the search, then parse the JSON results in the response callback. Using the results, I populate a table with the matching artist names and track titles, then render the first item on the list as a flash SNOCAP MyStore. The only back-end work being done here is the call to the search engine, and that is all done asynchronously so the user doesn't get interrupted as the Pandora radio is playing.

To prevent the active store from being blown away when a new song starts, I give the user the ability to "freeze" the store, or open it in a new browser window.

Fun!

SNOCAP Live Exclusive: Tea Leaf Green 4/20 Fillmore Show

2007-05-04T06:55:00.000-07:00

On Friday, April 20th Tea Leaf Green took to the stage in front of a sold out crowd at San Francisco's most legendary venue, The Fillmore. Their masterful performance that evening showcased their diverse range and fresh sound which has made them one of the fastest growing bands in the past few years.

Downloads of the entire show or individual tracks can be purchased on their MySpace page or below on their SNOCAP MyStore. TLG is the first artist to sell an entire live show recording exclusively through SNOCAP. The recordings are being sold for a limited time for $9.99, until Monday May 7, so download it now before this special price offer expires.

A portion of the proceeds will be donated to the Bill Graham Foundation. The mission of the Bill Graham Foundation is to give grants primarily in the areas of music, the arts and education, while also supporting social work, environmental protection, and spiritual and compassionate projects in our community.

TLG MySpace

When I write

2007-04-27T07:56:00.000-07:00

One of the things I do most is write. I'm not talking about emails and IMs, I mean documents that go to an audience of people I know and people I don't know. Most of these documents are technical whitepapers, but sometimes they're instructions or editorials that have to do with the industry in which I work, and usually they're done on a deadline. I've learned one thing about myself—being connected to the internet runs at odds with my ability to write effectively. You too? I'm not surprised.

I was reading this blog by Cyrus Farivar (the one about the live octopus tentacles) who apparently writes for a living. My favorite part of his blog is the subtitle: “Being a good writer is 3% talent, 97% not being distracted by the Internet.” I get distracted.

My solution is not so much by design as by necessity. I work tens of miles away from my office in San Francisco, and I ride BART to work every day. I don't attempt to connect to the internet via wifi while I'm riding, so I have about 45 minutes of "dead time" to kill. That's when I write. If you look at my writing velocity, I'm sure you would see it spike during those two periods of the day when I'm on the road. Even when I'm at home, after dinner when the kids go to bed, my writing effeciency lags behind those chunks of commute time during the day.

Sometimes people ask me how I've been able to handle such a long commute for so many years. I think if I had a shorter commute, it might be career limiting.

MyStore spread starting to show

2007-02-27T11:33:00.000-08:00

Pete Cashmore noticed that more and more artists on MySpace are setting up MyStores (MySpace Music Stores), claiming that there has been a 2000% growth in links from MySpace to SNOCAP. He even includes this cool chart (how'd you generate that, Pete?):

Well, I suppose that's probably accurate. Truth is, SNOCAP has been "launched" since December, and we're picking up steam on rolling out MyStores for artists represented by several major aggregators and indie labels with whom we have distribution agreements. You can expect to see this number continue to grow.

SNOCAP Movie!

2007-02-23T16:38:00.000-08:00

A higher-def version lives here (thanks toe.knee!).

Charlie stole the handle

2007-02-05T20:40:00.000-08:00

Wandering aimlessly on myspace and searching for bands selling their tracks, I came across Attic of Love. The first track I bought was Locomotive Breath, because after listening to the clip and being an old Tull fan, I had to have it. Yes, it absolutely rocks. So I checked out the rest of the tracks on their forthcoming release "Born Again", and I was pretty much blown away. Ass-kicking, great vocals, guitar, thoughtful lyrics, and that thing that sets them apart--flute. So I particularly like the tracks Born Again, Makes You, Taste, Green Lantern and Waking up from the American Dream. Imagine if Ian Anderson met up with some hardcore alt/punk rockers. My advice to the band is to keep working the things that make them unique (also...Cross Eyed Mary!!!). My advice to you is to buy the album and see them live (that last part I hope to do some day).

Here's the store. Paste it on your page! Tell your friends to do the same!