(Click on the links below to see the associated Garmin data if you’re interested in that type of thing.)

• Elephant Rock (06/05/2011): This was the first big event of the year. I said last year that I wasn’t planning on doing it two years in a row, but it’s a great training goal and a nice “big ride” experience for the girls.
  

  The group at Elephant Rock

  The girls rode the metric century version of the ride, and we took a nice even pace with them until the course split. After that, we raced to try and catch them at the last aid station. We didn’t quite make it there in time (they had been waiting for about an hour when we showed up), but we had a great, albeit hot, ride in to the finish together.
  

  Posing at E-Rock

• Denver Century Ride (06/12/2011): This ride began at Invesco Field (now Sports Authority Stadium) right by my house in downtown Denver. We again rode a century taking it easy until the course split away from the metric option. It was a nice ride, but we had some criticisms.
  

  Kevin and Leslie climbing Lookout Mountain

  The route was a bit rough with traffic and the jersey and T-shirt weren’t very attractive (I joked that I was even embarrassed to wear it to bed!) However, they took our feedback seriously and showed up this year with a brand new jersey (one that looks pretty darn good) and a completely re-designed route. I’m already registered for the 2012 version and I can’t wait!
• Mount Evans (07/10/2011): This wasn’t an organized ride, but it was likely the most difficult ride I’ve ever done. The final ride was almost 130 miles and well over 12,000ft. of elevation gain. Mt. Evans is the highest paved road in the US; so high, in fact, that my Garmin stopped being accurate up above around 12,000ft. (it shows our max elevation as around 13,000ft. when it was easily a thousand feet more).
  

  The climb to Mt. Evans beings

  We were hailed on and blown all over the place on the climb up, and one of the guys in our group even snapped his rear derailleur right off his bike! (Luckily, we found a car driving down from the mountain with a bike rack that was gracious enough to drive him back into Denver) When we finally finished the ride, I wasn’t sure exactly what to think or say. It was simultaneously the most physically painful and wonderful thing I’ve tried and I can’t wait to do it again!
• Copper Triangle (08/06/2011): This was year two of the outstanding Copper Triangle Ride.
  

  Finishing at Copper

  This time around, both the fellas I typically ride with got to participate (last year it was just two of us) and we all had a great time! Our three families got a cabin right in the middle of the Copper Mountain Village and we all had a blast just enjoying each other’s company and relaxing before and after the ride. I don’t think we’ll do it again next year (three years in a row is pushing it just a bit), but we’ll definitely be back soon.
  

  The Crew

• Dear Creek Century (08/21/2011): This event labels itself as the “hardest century ride in the US” Considering how difficult Evans was, I went into this ride thinking I’d be able to skate through it. I was very wrong. My first mistake was riding a fair amount during the week leading up to the event. I put in around 60 miles before even starting the ride. Beyond that, I didn’t hydrate properly and ate very poorly during the week. In short, I didn’t take it seriously at all and it definitely cost me. After about 50 miles, I started feeling sluggish. After the finish, I got pretty sick and got home to see I had dropped about 10 pounds of water weight during the ride. Not good.
  

  Feeling bad at Deer Creek finish

  I’m not sure if I’m going to do this ride again, but if I do I will definitely take it seriously.
• Tour de Fat (09/10/2011): This year, I rode a B-Cycle while Amber pulled Ryker in the Chariot.
  

  Killing it at the Tour de Fat

  It was just the three of us this year, but we had a great time and enjoyed ourselves (as usual).
  

  Ryker and I at the Tour de Fat

  The tradition of cycling with at least 1000 other folks in a giant parade topped off with a beer or two after the ride is something I look forward to every year.
  

  Amber and Ryker at Tour de Fat

• Other Rides: Alongside the rides here, the girls did the Venus de Miles ride while the boys volunteered.
  

  The girls at Venus de Miles

  Beyond that, there were numerous rides in Golden, Boulder (Jamestown, Sugarloaf, Flagstaff, Nederland), Colorado Springs, Castle Rock, Monument, Lyons (Oscar Blues is a fantastic destination), and the list goes on. I also had a great time riding with my beautiful wife multiple times during the year including climbing Lookout Mountain, riding to Golden and just getting coffee in the early spring. Often, riding is about enjoying the scenery and talking with interesting people and she’s definitely the most interesting person I know.
  

  Getting coffee on a ride

I’m not sure we can seriously top 2011 and I’m not looking to try, really. So, here’s to 2011 and having fun, doing hard stuff, drinking good beer and making worthwhile relationships even more so. 2012, you have some big shoes to fill!

On the surface, this game seems super simple. “It’s basically Scrabble but online.” The concept sounds so easy and obvious that the implementation is taken for granted. People don’t understand how complex it is because it just works.

I don’t have any first hand knowledge of the game, but as simple and obvious as it seems, the implementation is likely a lot more difficult than that. Aside from the actual app that you download from the App Store, there is a whole infrastructure running to make sure games and players are kept in sync. Again, I don’t know the folks who built it but I’ll bet they spent a lot of time and effort making it work as well as it does. And I’ll bet they are constantly working on it, making it better and keeping it running smoothly.

Another example is an application I did work on: The TWCableTV application for the iPad. This application also seems simple. The first version just streams live video. That’s it. Since the first release, we’ve added Remote DVR and other features, but the vast majority of the time it’s used to simply watch TV.

What might be surprising is only a small handful (3-4) of people actually worked on the app that gets installed on the iPad. At least 7-10 people worked on the services that talk directly to the iPad, a bunch more to test the app, yet another 2-3 on making sure the television streams were setup and continue to function properly, a whole host of people working in our data centers to keep the lights on, and lots and lots of previous work by other teams across the company creating ways to programmatically retrieve things like a billing data and validate usernames / passwords. Add a few lawyers in the mix to keep us from violating our contractual agreements and the number of folks who had a hand in the application, directly or indirectly, is at least 50 and likely more in the realm of a hundred.

That’s a lot of people for an application that just plays TV.

My point is that ideas for software are comparatively easy to come up with. The implementation of ideas is the hard part. We definitely weren’t the first to think “it would be cool to let people watch live TV on an iPad”. However, we were the first to implement it. And it was hard.

Software is usually like that.

Often, when a person I just met learns I worked on an iPad application, they’ll say something like “I have a great idea for an iPad application that [insert great idea here]” That’s similar to saying “I have a great idea for a skateboard that hovers or a device that converts matter to energy, transports it, and then converts it back to matter”.

The amazing thing about the titans of the computer industry is not that they had great ideas but that they actually implemented the ideas. Steve Jobs didn’t just think of the iPhone. He built it. He hired the talented team of engineers, designers, testers, and even lawyers to make it all work.

It takes work. It takes tenacity. It’s, well … just like everything else great in life I suppose.

It’s hard.

While I personally didn’t feel great about Google’s actions, I decided to reserve my public judgement for the time when Google actually released the language. Two days ago, that finally happened. So, let’s take a look:

main() {
  print('Hello, Dart!');
}

Ummm … ok. This chunk of code looks similar to JavaScript, so that’s not all bad. However, I was really expecting something more groundbreaking in terms of syntax. While I don’t loath semi-colons as line endings (you have to have something, right?) the new trend these days is to exclude them. Specifically coming from a JVM perspective Scala, Groovy and Clojure, three of the most popular Java alternatives, are happily semi-colonless. Also, as Google has deep Python roots, I expected they’d create something with a more “modern” syntax. But that’s ok … I can live with semi-colons. Let’s dig a bit through the Dart sample source code (can currently be found on Dart’s Google code page).

Check out https://code.google.com/p/dart/source/browse/branches/bleeding_edge/dart/client/samples/swarm/BiIterator.dart (I’ve removed the comments for brevity):

class BiIterator<E> {
  ObservableValue<int> currentIndex;

  List<E> list;

  BiIterator(this.list, [List<ChangeListener> oldListeners = null]): currentIndex = new ObservableValue<int>(0) {
    if (oldListeners != null) {
      currentIndex.listeners = oldListeners;
    }
  }
  E next() {
    if (currentIndex.value < list.length - 1) {
      currentIndex.value += 1;
    }
    return list[currentIndex.value];
  }

  E get current() {
    return list[currentIndex.value];
  }

  E previous() {
    if (currentIndex.value > 0) {
      currentIndex.value -= 1;
    }
    return list[currentIndex.value];
  }

  void jumpToValue(E val) {
    for (int i = 0; i < list.length; i++) {
      if (list[i] === val) {
        currentIndex.value = i;
        break;
      }
    }
  }
}

When I first saw this code, I instantly recognized a very similar syntax to Java 5 generics. Eerily similar, in fact. As powerful as Java generics are, not too many people like the syntax. To port what many consider to be kruft to a brand new language is an odd choice.

Another interesting thing about this code is the inclusion of strict comparison operators (i.e. ‘===’ and ‘!==’, see line 31 for an example). While the use of these operators is instantly recognizable to those of us who regularly use JavaScript, I think it a very odd decision to include these operators in a brand new language. They are, essentially, a JavaScript oddity that often confuses people when they first learn the language.

So far, things aren’t looking great for Dart.

There is hope, however: Dart has great support for concurrency. It implements a version of the Actor model (see http://www.replicator.org/content/a-first-look-at-dart-the-programming-language for details) placing code into Web Workers behind the abstraction. Concurrency is rarely easy and the Actor model is a great way to abstract that kind of complexity away from the developer.

So, let’s take a look at a basic Actor (Dart’s interface is called an Isolate):

class Printer extends Isolate {
  main() {
    port.receive((message, replyTo) {
      if (message == null) port.close();
      else print(message);
    });
  }
}

main() {
  new Printer().spawn().then((port) {
    for (var message in ['Hello', 'from', 'other', 'isolate']) {
      port.send(message);  
    }
    port.send(null);
  });

Huh. It doesn’t look terrible, but I’ve been doing a lot of Scala development recently and Scala also happens to have actors. Let’s take a quick look at how Scala might implement the above code:

import scala.actors.Actor._ 
val portActor = actor {
    while (true) {
        receive {
            case msg => println(msg)
        }
    }
}
List("Hello", "from", "other", "actor").foreach( word => portActor ! word)

Granted: these are both contrived examples. However, look at the Scala version. It’s doing some tricks like importing a static Actor but it is still, at least to my eyes, much more readable and elegant than the Dart version. While it’s nice to have an actor-based model for client development, I feel like Dart’s falls short in comparison to Scala’s state of the art implementation. Again, considering this is a brand new language, this is puzzling.

Finally, Dart itself can either be executed in a virtual machine or transpiled to JavaScript for execution in a browser. Since most browsers outside of Chrome won’t have much support for a native Dart VM in the near future, let’s take a look at Dart’s transpiling overhead. This is probably all you need: https://gist.github.com/1277224. Dart’s ‘Hello World’ application transpiled to over 17,000 lines of JavaScript. Wow. To be fair, this overhead has to do with setting up Dart’s optional typing system and other niceties of the language which is more akin to including a library. As such, this isn’t an apples-to-apples comparison with JavaScript itself or something like CoffeeScript which transpiles in a more one-to-one fashion.

But still. Wow.

So, at least for now, it seems like Dart is a bit of a snooze. As much as I was disappointed in Google with not being more open about the development of Dart, I was also excited in seeing something that would simply blow away JavaScript and set the stage for something ground-breaking (maybe something like “ScalaScript”). Dart is not that. Core Java developers will likely feel right at home with Dart, but I can’t see the huge community of client-side JavaScript engineers being very excited about this.

Dart, I am disappoint.

As part of this endeavor we were given the freedom to choose just about whatever tools and technologies we wanted to build the most scalable, maintainable and bullet-proof system we could. After about a week spikes on different languages, frameworks and tooling we came to the initial conclusion that we would adopt:

• Git for version control
• Spring for DI and other stuff (which we since removed, see below)
• Scala as our primary development language
• Gradle for our builds
• MongoDB for persistance

This blog is one of many to report on my impressions of these choices and the tradeoffs they are (or aren’t) causing us to make versus a standard J2EE/Spring Java project that just about everyone on my team has done in the past successfully.

First, Git.

Git. Is. Awesome. Seriously, it is amazing. I’ve been using Git for about two years but, before now, only in very small projects. I thought it was good before, but I’ve really grown to love just how much flexibility and speed it buys me personally not counting how much it buys our team in terms of ease of branching and an easy (now) to understand code history. If you haven’t yet adopted Git as your SCM system, you absolutely should.

Secondly, Spring.
We’ve all used Spring pretty heavily in the past and have a good track record of success with it. However, as we began coding our DI, we came to a very startling conclusion: we probably don’t need it anymore.

Relying on our experience with DI in general and our understanding of what Spring does “under the covers” as it wires objects together, we were able to create a native Scala DI solution that is statically typed, easy to understand (read: no XML or annotations) and, given that it’s simply part of the language, extremely quick to bootstrap. There is no ApplicationContext to wait for or mock for testing. It does its work when the classes are executed (and slightly later if we’re using the lazy modifier which we usually do) and that’s that. While I’m sure we’ll be refining this solution over time, the fact that we own it and it works as well as it does for us makes me suspect that we, as a team, have grown “beyond” the need for Spring. Spring helped us (and me in particular) understand the need for things like DI and AOP and caused me to think of my code in a very decoupled manner. Thanks Spring, but we’ve grown up!

Next, Scala.
I’m not sure what I think of Scala yet. It’s a daily thing. Coming from a lot of Groovy and JavaScript work, I have grown to like the free love devil-may-care type system. Some of the recent code I’ve written in those two languages is the best work I think I’ve ever done. However, I do see the value in a stricter type system and there are many things about Scala I love.

The biggest concern I have is how ridiculously complex Scala can be if you let it. The community has yet to (as far as I can tell) establish a concise set of patterns (something like Effective Java) and many teams (including ours) spend a lot of time trying to figure out what esoteric features to take advantage of and which to ignore. The exciting thing about this is that we are building our own Scala “way” of doing things internally in our team. That’s also the scary part. However, so far, it’s been relatively smooth aside from those times when I think “my god this was so much better in [Groovy|Java]” which are becoming less frequent as I continue to learn the language.

Gradle.
I had high hopes for Gradle when we started the project. We moved from a combination of Gant and Maven and, at first, we were loving the combination of convention and extendability. It really allowed us to customize our build and do some pretty neat stuff with very little effort.

My biggest complaint, which is starting to sour my whole opinion of the tool, is how slow it is. Running gradle tasks in our project on a quad-core Xeon takes 17 seconds! Running a build from scratch takes almost 30 minutes. And, since there isn’t yet great IntelliJ support for it, running a gradle idea (which I do several times a day to refresh the .iml dependencies) takes 4 minutes.

These are all unacceptable timeframes in my opinion. Granted: much of the 30 minutes I mentioned above is spent downloading dependencies (perhaps the majority of it), but the other tasks download nothing and still take far too long.

As gross as it sounds, I’m actually missing Maven. Not necessarily for configuration and dependency management (which were and still are a pain in many cases) or its contrived complexity and “xml hell” but more because it was faster and had first-class IDE support. These things are all missing right now with Gradle and I feel like it might be causing us to lose velocity rather than gain it as the time saved setting up the project does not match the time we all spend waiting for tasks to complete on a daily basis.

We may be doing something wrong and I’m open to doing what it takes to modify our setup, but I feel like what we’ve done is extremely reasonable and a relatively “common” case in terms of project structure and dependencies. To verify that assumption, I ran the same types of commands using another complex project: Gradle itself. I had similar results to those I see in our project. I’m hoping things improve in this regard after a smart colleague of mine attends Gradle training next week.

Finally, MongoDB.
I don’t have much of an opinion on this one as we haven’t integrated to it just yet. I’m interested to see how it compares to CouchDB as that’s where my previous NoSQL experience lies.

Again, I’ll be writing more as we get farther into the project. I feel (mostly) pretty good about the decisions we’ve made and the team I’m on. It’s been, and will continue to be, an awesome ride!

I remember that announcement very clearly and how excited I was. I even went around buying up domain names of web applications I thought ChromeOS would need and I would famously build in my spare time (anyone interested in a barely used www.chrometunes.com?) I felt ChromeOS would be the perfect solution for casual users like my parents performing relatively lightweight tasks like viewing and storing photos, music, and documents. The ultimate “thin client” had finally arrived.

On January 27, 2010, Apple announced the iPad and things began to change. Many people, including myself, grew to think that a tablet could fill the casual computer user space better than a small notebook. The iPad is cheap, light, easy to use, and gets stellar battery life. And, not only does it have a very healthy app ecosystem, it also runs modern web applications extremely well. It’s the best of both worlds. Android also stands to perhaps fill that need in the near future with the same split of a native app ecosystem and an advanced web browser.

A few days ago, Google finally released reference hardware of ChromeOS to a fair amount of fanfare. While I’m still intrigued on the concept, the overall idea is much less exciting to me. Before the iPad, I could easily picture an ecosystem that didn’t bother with native applications.

Now, I’m not so sure.

The Platform
There’s a reason the “thin client” model never really materialized and I don’t see that changing any time soon. For the end user, and especially the casual end user, the fact that the “OS is a browser!!1!!1!” doesn’t matter nearly as much as the actual experience. Browsers have come a long way, but curated and tailored experiences are still very valuable and users have demonstrated they are willing to pay a premium for them.

In short, the application platform is really irrelevant to most people. What matters is a great experience. Both the iPad and MacBook Air turn on almost as quickly as you can press a button or open a lid … just like ChromeOS. Does it matter that one is a “thin client” and the other two aren’t?

The “Cloud”
I agree that remote data storage is a valuable thing for casual users. Issues of privacy aside, it’s extremely convenient to have access to documents, photos, and media regardless of location.

But we already have that. We can view and edit documents stored on the Internet from your phone, laptop, and desktop today. We can access Facebook and Netflix from a Samsung TV or an iPhone. What exactly is ChromeOS providing that adds something unique and new? Will it do it dramatically better? So far, I’m not seeing it.

Price
Before the iPad, the cheapest way to get into casual computing was the relatively poor experience of an entry level “netbook”. Today, you can easily get a great casual computing experience for under $500. ChromeOS may have promised a much lower price point and better quality in 2009, but the bar has moved a lot since then.

I don’t know what’s going to happen with ChromeOS, but I honestly don’t see it gaining a lot of momentum. I see a future in which casual users will connect to their data with tablets, TVs, and phones and the more advanced users will continue to use powerful laptops and desktops.

At the beginning of 2010, I got together with a couple of my best friends and we mapped out the organized event rides we wanted to do for the season. There are a lot of these types of events all over the place, and it was a challenge to narrow it all down. Here are the ones we chose and my thoughts:

• Elephant Rock (06/06/2010): This ride is commonly known as the kickoff of the summer riding season. It has been around for a long time and has a lot of distance options for various skill levels. I rode the century option which includes close to 6,000 feet of climbing.
  
  
  

  Elephant Rock

  
  
  

  Taking a turn on the Elephant Rock ride

  
  The course started and ended in Castle Rock traveling in a loop including a dip into Monument. There were ample rest stops along with the way and, despite some wind, was a reasonably great kickoff to the season. On the downside, the food wasn’t so great and, because of the sheer volume of riders on the course, there were times when congestion was a real issue. I’ve decided to ride it again next year as it helps set an early season fitness goal, but there were better rides this year no question.
• Bike MS 150 (06/26/2010-06/27/210): This was a two day event. We rode from Westminster to Fort Collins, stayed the night, and then rode back the second day. Both days were roughly 75 miles leading to a grand total of 150 combined miles over the weekend. There is also a century option on the second day for people who want to ride a little farther.
  
  
  

  Finishing up the MS-150

  
  The ride itself was beautiful and relatively easy, with only about 1,500 feet of climbing over Horse-tooth Reservoir. We averaged close to 20mph on the way up. The food was outstanding and the volunteers were extremely fun and helpful. I’d definitely do this ride again except that the price of admission has gotten relatively high. Each participant is expected to raise $400 minimum to ride, and I ended paying the majority of that out of pocket. If you’re one of those people who love asking for money, then this ride is definitely for you.
• Sunrise Century (07/24/2010): This ride was a 100 mile (with 7,000 foot elevation gain) loop from Boulder into Lyons, over to Nederland on the Peak to Peak, and back down into Boulder via Left Hand Canyon. This loop and its variants are extremely popular due to some challenging climbing and incredible scenery. It was likely the hardest ride of the year for us.
  
  
  

  Happy to be finishing the Sunrise Century

  
  The ride, however, isn’t something I’ll likely do again. I spent a lot of time on the Peak to Peak this year before and after the event, and didn’t really feel as though it was worth paying for the organized version. The food wasn’t great and the ride felt disjointed. If you feel like riding this course (and you really should; it’s a great course) I recommend doing it on your own.
• Copper Triangle (08/07/2010): This was, hands down, the best ride of the year. The organization was outstanding, the food excellent, and the course incredible. There were the perfect number of people on the road and just about everyone was nice and courteous. We stayed the night before and woke up to one of the best days I’ve ever had on a bicycle. I’m most definitely going to be doing this ride again next year!
  

  Copper Triangle finish line

• Tour de Fat (09/11/2010): This was a great family ride from our house to City Park and back. The total distance was about 35 miles. We took the family and kids along and had a great time listening to music and drinking some outstanding beer. The crowd there is always lively, and everyone is expected to be in costume (we dressed up as Mormons :)
  
  

  Amber and Leslie at the TdF

  
  
  

  Waving Hello at the Tour de Fat

  
  
  

  The baby at the Tour de Fat

Next year, I plan on doing Elephant Rock, the Denver Century, Deer Creek, the Copper Triangle, the Crooked Roubaix, and the Tour de Fat (of course). Also, probably the most exciting thing for me in 2011 is the inclusion of my wife on at least a few of those rides along with the weekly group rides.

2011 is going to be quite epic … I can’t wait!

Yesterday, I wrote about having the right motivations for a rewrite. Today, I’m going to detail the things I believe are required for actual success. It’s important to note that this list doesn’t guarantee success and that these types of projects often fail regardless. However, if you’re going to go down you might as well go down swinging!

1. Do you have the right people? The importance of having the right engineers cannot be stated enough and if only one thing can be taken away from this post I hope that’s it. You’ve got to spend the money and hit the network(s) to get the best you can possibly find and recruit them to the project. I’ll leave the definition of a “good” engineer to a later post (although a Google search provides a plethora of information on this topic). I will say that it’s important that the people you find are outstanding both socially and technically as software development is a social activity. The intersection of those two qualities on a venn diagram is rather small and these people are in high demand. Expect to work for it.

   If you’ve already hired the head counts you need, is your existing team motivated to do the work? Are they the type of people that energetically solve problems and are excited to take on such a big challenge? If not, reconsider your team. Seriously.

   If you’re using a vendor to do the work rather than an internal development team, the same rules apply. Make sure you get to know the personalities behind the actual development work. If the vendor is offshoring the work, it’s likely you’ll experience some of the pain associated with that despite how abstracted the project manager might claim it to be. A past record of success is important in selecting a vendor, but it’s even more important to be comfortable with the current development team and imagine yourself working with them for a long period of time.

   More than anything, your engineers will decide if this project succeeds or fails.

2. Do you have the right process? As the Agile Manifesto states, people are more important than process. While processes known as Agile are the current trend de jour for sure, adopting some or all of them doesn’t guarantee success. For many reasons, however, Agile does help create a framework that encourages success more than most previous methods. It also helps create a system of expectations to interface with other groups and management in the company (see more below). Adopting an Agile process and doing it well will help you succeed.
3. Do you have the right expectations? One of the difficulties of rewriting software versus creating something brand new is that there are explicit and implicit expectations right from the start. “It should do everything [the legacy version] can do.” You have to understand that there are likely a lot of people already used to getting things done in the old system. The UI might be atrocious, but it’s familiar.

   So don’t kid yourself or the company: the new version is going to bring some pain. It will require new training and perhaps a bunch of CSRs or even customers to relearn and retool their understanding and workflow. This is the social cost, and it’s important not to underestimate it.

   There are also technical hurdles such as how to stage the rollout. Do you expect to simply flip a switch one night or gradually migrate over? How will the migrating from the old database to the new database work? Beware of creating “legacy bridges” to help stage a migration as too many of these will kill your velocity.

   If possible, try and freeze feature additions in the legacy platform so you have a static target of functionality to chase rather than attempting to keep up with another development effort.

   Finally, give as much insight into your development process as possible. Be transparent. If you’re behind where you think you’d be, admit it. This is where adopting an Agile process can really help as it automatically sets these process and velocity expectations with the constituents and product owners.

4. Do you have the right product direction? You can have a great team of engineers and a wonderful process, but still fail without a good product owner. You need someone who can understand the requirements of the legacy platform and translate them into stories. You need someone who can decide what features are necessary to get a version 1 release into the field so real iteration can start. You need a person who can shield the engineering team from any political issues that might arise. These types of people are just as important as good engineers and should be sought after with the same sense of urgency.
5. Do you have the right support? Does the company fully support your effort to perform the rewrite. Attempting to do something this big without the support of (almost) everyone in the enterprise will be very difficult. You need cooperation and a certain level of forgiveness from your internal constituents. You might need help from other groups for integration efforts. You’ll likely need lots of testing help.

   These types of projects in large organizations can get bogged down in political mire. Having the support of key people, especially on the C level, will help shield that from happening.

   Finally, don’t be a jerk to other groups. What you’re doing may be important, but acting as if it’s more important than anything else will blow any positive capital you have. Remember that development like this is largely a social exercise. Just like in “real” life, treating people with respect will buy you a lot more in terms of help than talking down to them.

Good luck!

How many times have you heard the following about an application in your organization: “this sucks, we should just rewrite it”?

I’m sure I’ve said it at least a few times. For a while, the smart money was on generally avoiding rewrites and for good reasons. However, as new tools make it easier to maintain velocity in a software project, a rewrite shouldn’t just be thrown out on principle.

There are some great questions to ask yourself if you’ve ever thought about rewriting a deployed legacy system. Today’s post centers around the question “Do you have the right motivation?”

In other words, are you considering a rewrite for the right reasons. Some good reasons include:

• The application can no longer make company and/or performance business requirements. This one is obvious, but, especially in cases of performance, make sure this is the case (more on this below).
• The application technology stack is becoming too costly or difficult to support. Maybe the application requires expensive proprietary servers or people who are skilled in the technology powering the application are becoming harder to find and more expensive to hire. Another example of this might be that the framework or platform the application was written in is deprecated to the point that it is hampering interoperability needs or upgrades to strategic and important new technologies.
• It is too difficult to add new features due to extremely excessive code bloat and smell. This one is tough to quantify (see below), but can be a good reason to start anew if it is to the point that it is hurting the company’s competitive edge.
• The application development is outsourced and the working relationship with the primary vendor has soured. This may not justify a full rewrite, but there are circumstances (don’t have a license to modify the source code, can’t legally add new hardware, etc.) where this makes sense.
• The application development is internally maintained and the platform makes it difficult to acquire and keep good talent. If you see engineers roll their eyes or shrug their shoulders when you try and make Struts 1 development sound exciting, it might be time to move to something good engineers are excited to work on. Obviously, you can’t let the latest technical fad decide everything, but there is a pretty obvious line when all the good engineers in your group start jumping ship to work on cooler stuff.

Some bad reasons to perform a rewrite include:

• Someone in the company just got wined and dined by a vendor. Enough said.
• Political motivation such as a new president trying to show off their chops by beating up on legacy technology or making a play for control of another group.
• The application development is internally maintained and you hear casual complaining over code quality by engineers. As I stated above, code quality should be considered for sure but this could also signal that a couple of iterations are required to clean up and refactor the code. If the engineers are complaining about the lack of testing, take a couple iterations to add tests. Before making a decision to drop everything and start from scratch, see if engaging the right engineers to take ownership of the problems they complain about helps to fix them.
• Offhand determinations that the application doesn’t perform well or doesn’t meet business requirements. These sorts of decisions should be decided using real measurements and with a good understanding of the entire process. If a transaction seems to take a long time, understand what it’s doing and if it’s really the application’s fault. Maybe the application is interfacing with another internal process that needs to be optimized. Maybe the UI has poor speed metaphors and just adding a throbber will make it feel faster. Make sure there is hard data to support this.

Next time, I’ll talk about basic things you’ll need to help decrease the likelihood of failure during the process.

Except it’s not. The iPad doesn’t support this feature, likely the most common UI metaphor on the device, in an easy way for Mobile Safari applications. There are some solutions (including Pastry Kit and Sencha Touch), but they all solve the problem a very similar and kludgey way: overwrite the default scrolling behavior with one that uses CSS transformations and JavaScript to move the elements down the window pane. Even Google’s iPad GMail interface, one of the best implementations of this in Mobile Safari, is using this strategy. Implementing this requires a large amount of effort in most cases even with the support of a JavaScript framework behind the scenes.

A simple solution, however, would be to simply change the iPad’s overflow support. In most modern browsers, setting a static height / width for a div element and adding the overflow: scroll; property in CSS will result in an independently scrollable portion of the page should content exceed the height / width boundaries. The iPad does support scrolling in these circumstances, but it requires using two fingers and is often slow and unresponsive. Most Android browsers (including, as of the time of this writing, the Galaxy Tab) don’t support this type of scrolling at all.

Changing the device’s behavior to automatically add the native style tweening, momentum, and scrollbars to these elements would allow UI developers to very easily add intuitive independently scrolling sections to their iPad web applications. Even better, this solution graceful degrades as desktop browsers would automatically add scrollbars to the content making it easy to understand that additional data is available.

UPDATE: Looks like this feature is making its way into iOS 5! http://functionsource.com/post/scrollability-can-hopefully-become-a-shim

I started watching Fringe a bit into the second season and it occurred to me today that I haven’t seen the first season at all. I went on iTunes to check out how much the first season download costs and immediately decided against it. I simply balked at the $39.99 and $59.99 price points for standard and high definition downloads.

It’s not that I believe those are horrible prices per se, but that I’ve been used to getting content for a much lower price. We pay for Netflix and Hulu Plus; we don’t have cable or broadcast TV. Our bill for both services is under $25 per month. While we could afford it, I have a hard time justifying $60.00 for something I’ll only watch a couple of times.

This is a very bad thing for content providers. The market price of their content is getting closer and closer to zero and, perhaps even worse, people who could pay more are getting conditioned to paying less for consuming content. Pricing is all about setting expectations, and it’s very hard to change them once they are set.

You could argue that Hulu, even Hulu Plus, is partially add supported and that allows networks to continue to get paid, but adds are becoming a less and less effective way to pay the bills. Most networks rely on syndication and sales of physical media to help make ends meet. However, physical media like DVD and Bluray are rapidly being replaced with streaming services and syndication’s sole purpose, offering more options for watching a back catalog, becomes unnecessary if an entire back catalog is available for streaming online.

We’re not far off from being able to access just about anything we want to online for little to no cost. It’s where the momentum is. However, this is likely bad for the industry as a whole. If the streaming services had been structured more like a cable offering (perhaps ala carte) and opened their content up for distribution on every platform from the get-go, things might have been different. As of now, I see content providers demanding more and more from their high paying customers (those subscribing to cable or satellite television) increasing the likelihood that people will simply cut the cord as their cable bills, and the number of viable low-cost alternatives, climb.