When Oracle bought Sun earlier this year it brought a new overlord to the Java universe. And it is already apparent that Oracle is going to manage Java in a much different manner. The fact that Oracle has an agenda that is so different from Sun is sending ripples throughout the Java community. What does it mean? What changes are coming? What value does Oracle place on Java relative to their other product lines? Is Java going to maintain the same open-source spirit that has served Java so well for 15+ years? No one knows right now.

Change is always tough, especially to programmers. We are all waiting to see what Oracle will do next.

–Marty

The #1 thing I see is the feedback loop. The most successful apps, the ones that are downloaded the most, constantly have reviews that say “the developer listened to me and got back to me.” Even for the apps that have growing pains (adapting to new hardware, adapting to OS updates or adding new features) the customers are forgiving if they feel part of the process, part of the loop. Otherwise excellent apps are downgraded if the developer, for whatever reason, chooses not to respond to customers.

I am a prime example. I have worked with a small development shop with an app that worked on my original Droid, but died on my Droid X. I am pretty sure the developers couldn’t afford to get a Droid X, so they used me as their test lab. They were very responsive, very involved and I never felt abandoned. This feedback loop kept me from dumping their app and looking for an alternative.

The #2 thing that I see in the most successful apps is a continuous stream of releases. Bug fixes, corrections for different hardware, new features, even small tweaks are part of a steady stream of updates. And the best developers go out of their way to acknowledge that the changes are driven by their customers.

There are a number of other interesting attributes of successful apps that I could add, but these are the main factors that strike me as revolutionary in terms of software developed for the consumer market.

Whether by choice or by the desires of the market, the Android marketplace has adopted many of the practices found in the Agile movement. I would venture that with the proliferation of these devices, the way customers interact with, and the expectations they have from, software developers in markets of all sizes and shapes are going to fundamentally change. A new relationship is being forged between the customer and the developer. I think this new relationship will be a primary factor in deciding who wins and who loses going forward.

Here at RadBlue, we live Agile, breath, Agile and see its benefits daily.

Welcome to the new world.

But getting there is a serious challenge. We have five kids, one van and at least 17 hours on the road. So there is a great deal of planning that is done up-front. We plot out where to get gas, what rest stops to hit, what snacks to bring and where to find the first Chick-Fil-A once we cross into Tennessee. The goal is to have no surprises; to know exactly what we are doing.

And that is how we used to build software as well.

Not too long ago, we would sit down at the start of a project and write down everything we were going to do. We would plot out the bugs we were going to fix, the features we were going to add and how much time each step would take. We would spend weeks or months creating documents and charts filled with details. The final schedule would be meticulous in detail and brimming with confidence.

And then the van would crash into a ditch just outside of Indianapolis.

I’ll get into the hows and whys of that particular phenomenon in another blog, but first, I wanted to touch on how we do scheduling at RadBlue.

At the start of each development cycle, we have a short list of issues that we want to tackle. All of these issues relate to our goal of making our products better for our customers.

Then, we get in the car and start driving.

Going into a development cycle, we know that the journey is never going to be a straight shot. In fact, we know we aren’t going to get to the original destination. Our customers are great at voicing their opinions – on both the current products and on sneak previews of the work in-progress. And all of that input helps steer the car.

Our development process is a fluid one. We are constantly revising the schedule and feature set based on the latest information. Sometimes the input changes our direction by a few degrees. And sometimes the input completely changes our direction. Sometimes we head toward Disneyland, but end up at Disney World.

For a small, agile company like us, this is the best possible way to respond to the needs of our customers. It allows us to focus on what is needed and deliver it in a timely manner.

It’s probably the worst possible way to pilot a family to the ocean. But it’s a great way to build software.

To continue . . .

I quit programming and pretty much did nothing for twelve months – until our company flamed out and I was out on the street. Part of me was sad that six years of work had gone up in smoke with the rest of the dot-com bubble. Even more of me was glad to see that the beast had been slain. But now what? What was I going to do? I only had one marketable skill.

Luckily, a friend and fellow programmer named Paul brought me into the fold of a cool start-up named Cambia Networks. Cambia Networks was kind enough to hire me, ostensibly as a programmer, but mostly as a senior engineer working on design and as an ex-foot soldier of the 90′s start-up wars.

My friend Paul had a pretty good idea that I was burned out on writing code the old way. I was willing to do it, but my heart wasn’t in it. One day Paul said “read this” and handed me a book. That book was Kent Beck’s Extreme Programming Explained. I’d never heard of Kent Beck or his publisher. In fact, I had never really read a book about coding in Java.

From the first page, the book was a hurricane of fresh air. It spoke directly to me and to my years of frustration. Kent and his team had worked on projects, like I had, that had no real customer and no real delivery date. These projects are known as Death Marches. They end in only misery and pain for all involved.

But Kent had done something about it. Through trial and error, he found a new way of developing software.

Extreme Programming (XP) (the original Agile methodology) puts the focus of software development where it belongs: delivering quality to the end user. Anything that does not contribute to that goal is a waste of time. Through a very small set of simple practices, this approach focuses on working with the customer to build for them what they need, when they need it. This was what we had done at Frontline all those years before the venture capitalists opened their checkbooks.

I read the book straight through that first night, and I think I read it twice more that week. I was hooked. Reading that book (along with a few others I’ll cover in future blogs), energized me. I had found my way back. I could see a meaningful and fulfilling way of writing software.

And I haven’t stopped since.

I hope that through this blog you will see how the Extreme Programming/Agile approach is at the core of what we do at RadBlue.

But I am getting ahead of myself.

In 1990 I had a startup software company that I loved. It was called Frontline Software Technology. Now, Frontline was, by just about every conceivable business measure, a sad little enterprise. We were very small, we had a very small venue stream and we mostly got taken advantage of by everybody we dealt with. But that’s not what we were about.

Everyday, when we got up, we thought about our customers. We actually cared what they did with our software, what they thought about our software and what they thought about us. We realized pretty quickly that if even one of them walked away from us, we were doomed. So we bent over backwards, everyday, to keep them.

We added features on a daily basis, we shipped out new versions each day if need be (this was before the Internet), we dialed into their systems to debug problems. We worked with our customers to understand what they were doing when our software let them down. We knew our customers by name, memorized most of their telephone numbers, we knew what they did in their jobs because we talked so often. Each day was exciting because we were in the trenches delivering value to our customers.

And we were happy.

Fast forward nine years. Our little four person startup had morphed into a 150-person behemoth. We had a whole floor in a Chicago high-rise, we had outposts in London and Paris, we had sales reps spanning the globe. We had 40+ programmers, we had 24×7 support, we had three levels of management, we had HR and lawyers and all of that. And, oh yeah, our customers. Our customer base comprised the biggest telecom players in the world, both old and new.

And I was unhappy.

We no longer cared about the customer. They didn’t figure into the equation. Once you had spent your whole day dealing with the beast that was the organization, you had no time or incentive to even think about the customer. We existed because we existed, a perpetual motion machine, a mobius strip of human motivations.

I had started out as a programmer, moved to VP of engineering, went back to programming and then got out to do R&D. But just watching those last two years, as the customer faded further and further away from the daily conversation, became too much. We had gotten so far away from the Frontline days that I couldn’t take it anymore.

So on Thanksgiving, 1999, I exchanged my C++ compiler for an exercise bike and waited for the inevitable hammer that was the end of the dot-com era.

I’ve gone over all of this old ground for a reason. In my next post, I’ll tell you what it took for me to pick up my compiler again, and why I won’t be putting it down anytime soon.

–Marty

At the All Things Digital conference, sponsored by the Wall Street Journal, Microsoft had to glumly sit by while the whole world told them that they were dinosaurs. Steve Jobs and his revolution are going to destroy the desktop hegemony enjoyed by Redmond, and the world will never be the same.

This may or may not be true, and part of me even wants it to be true. But there is one thing that my 30+ years in the technology space has taught me: innovation cannot be denied.

Microsoft may be looking at a bleak future; we shall see before too long.  But one of their employees sitting at their desk, either in Washington or California or China or India, is inventing a new future for Microsoft. Innovation has a way of doing that. Just when the future looks one way, a spark of an idea jumps up, the clouds part, the seas calm and a new race is begun (pardon my mixed metaphors).

Microsoft, for all of its warts, has transformed the word in more ways than Mr. Jobs has or probably ever will.  And I would bet Redmond will do it again.

Now, if they could just keep my Vista box from crashing every other day…

–Marty

That is how these things always start out – at least when you are a programmer.  Or maybe:

System.out.println(“Hello world”);

This is my first entry, so I thought I would introduce myself.  My name is Marty and I work here at RadBlue.  I do lots of different things, but my main job to write code.  When you are a small company, like us, you have to wear lots of different hats. But, at the end of the day, that is what I do.  I write code.  Lots and lots of code.

And that is what I want to share with you.  What it is that we do here at RadBlue, why we do it, how we do it and why we enjoy it so much.   So come along for the ride.

–Marty