The Truth as I See It: Part 3
Continuing in a series. Here
is Part 1. Here
is Part 2.
Last time, we talked about the technical causes of code decay: underlying platform & technology changes that make formerly good approaches obsolete. But this decay phenomenon can also be accelerated by users. As the expectations of your audience shifts, your code has to keep up -- whether with UI standards, integration, performance, or portability of platform. We constantly see this pressure coming on all fronts, but especially from executive level users.
(Click the permalink for more...)
Last time, we talked about the technical causes of code decay: underlying platform & technology changes that make formerly good approaches obsolete. But this decay phenomenon can also be accelerated by users. As the expectations of your audience shifts, your code has to keep up -- whether with UI standards, integration, performance, or portability of platform. We constantly see this pressure coming on all fronts, but especially from executive level users.
(Click the permalink for more...)
In the late 90's, we heard a lot of talk
about "web years." New ideas were accelerated so much that
taking a year to come to market was a strategy doomed to failure. At
the time, this was a term that defined venture capital and crash dev teams
(anyone remember PointCast or Marimba? I thought not.) But
in the last few years, it's come to define patterns of user expectations,
instead of investor expectations. Throw enough companies out into
the sea of the internet, and eventually some of them will be able to swim
in web time.
Consider the recent noise over the iPhone: without any changes in Lotus software or strategy whatsoever, the lack of integration concurrent to other platforms was regarded as an indicator of obsolescence. The idea is pretty ridiculous on the face of it, since no one knew whether any of the announcements had any substance to them (as it turned out, the reality of what was delivered was less than thrilling) but the expectations of what everyone SHOULD be doing changed virtually overnight.
Consumer software-as-service offerings trigger this effect as well. The "perpetual beta" status of apps like Gmail or Twitter or MySpace changes user expectations of how quickly software should evolve, and what it means to deploy a "fix." When a service like Twitter can release a new version every day, shipping a new version every few years makes a publisher look like a dinosaur.
Ironically, the first time I heard about this rapid release concept was in a 1995 interview with Bill Gates, when Microsoft was making the transition from the ever-so-brief CD-ROM era to focusing on the web. In an interview about the fledgling MSN, he remarked (and I'm paraphrasing... it's been a lot of years) "with software on the internet, there is no manufacturing cycle and no distribution channel. You can ship a new version every day." It's stunning that 13 years later, Microsoft is still struggling to deliver on that vision, while sites like Google and Facebook make it their fundamental strategy.
User-driven decay rates are also impacted by the age of your audience. The expectations of college-age workers are substantially different from senior level executives. But even among older workers, many expectations are shaped by what their children do. (Ray Ozzie used to take a lot of inspiration from how his kids interacted with games.)
And it's not just the initial expectations that are different, but expectations about the rate of change. It's not enough to develop a well-integrated application with a modern, flexible interface -- you have to be able to adapt it to changing business and technology needs in a matter of days and weeks instead of months and years.
These changing expectations have created an entirely new set of challenges for software engineers. The internet has changed the definitions of terms like "release", "bug" and "application." Adaptability has become the foremost consideration for coders.
On the plus side for developers, the meaning of "bug" has changed a great deal to. An unexpected change in behavior really isn't a "bug" to the web 2.0 user. It's a glitch -- a blip that it typically corrected within 48 hours of occurring. Because when you can deploy a new version every day, your dev/test/release cycle is measured in hours, not months. A "bug" is when an application fails to make a fundamental use consideration -- like functioning on a Blackberry, or over a 3G link, or working on Konqueror in an Ubuntu client, or being simultaneously edited by users on 4 continents.
It turns out Notes/Domino is a great technology for this kind of rapid release approach. The technologies of replication and design inheritance make it a breeze to globally deploy incremental updates in a fraction of the time and complexity that would be required on other platforms. The flexibility of the NSF data store makes it trivial to add a field to a form, or a column to a view. As long as you don't make fundamental design flaws, the platform allows enormous fluidity in behavior from one day to the next. I've used this approach for nearly a decade on every project I've been a part of.
But it's critical to design applications with this evolution in mind. If you focus on quickly delivering to a minimal spec, it's virtually guaranteed that you will lock yourself into an approach that cannot be readily adapted to new requirements. And because your users live in a world where salesforce.com can add a new feature every day, they're going to view your semi-annual release schedule as a failure, and look for a solution that responds at a speed they've grown accustomed to. And that's when you hear the Siren's call to platform migration.
So how do we protect our applications from this kind of failure? Let's hear your strategies for maximizing the adaptability of your solutions. And I'll let you know my own thoughts in part 4.
Thanks for tuning in.
Consider the recent noise over the iPhone: without any changes in Lotus software or strategy whatsoever, the lack of integration concurrent to other platforms was regarded as an indicator of obsolescence. The idea is pretty ridiculous on the face of it, since no one knew whether any of the announcements had any substance to them (as it turned out, the reality of what was delivered was less than thrilling) but the expectations of what everyone SHOULD be doing changed virtually overnight.
Consumer software-as-service offerings trigger this effect as well. The "perpetual beta" status of apps like Gmail or Twitter or MySpace changes user expectations of how quickly software should evolve, and what it means to deploy a "fix." When a service like Twitter can release a new version every day, shipping a new version every few years makes a publisher look like a dinosaur.
Ironically, the first time I heard about this rapid release concept was in a 1995 interview with Bill Gates, when Microsoft was making the transition from the ever-so-brief CD-ROM era to focusing on the web. In an interview about the fledgling MSN, he remarked (and I'm paraphrasing... it's been a lot of years) "with software on the internet, there is no manufacturing cycle and no distribution channel. You can ship a new version every day." It's stunning that 13 years later, Microsoft is still struggling to deliver on that vision, while sites like Google and Facebook make it their fundamental strategy.
User-driven decay rates are also impacted by the age of your audience. The expectations of college-age workers are substantially different from senior level executives. But even among older workers, many expectations are shaped by what their children do. (Ray Ozzie used to take a lot of inspiration from how his kids interacted with games.)
And it's not just the initial expectations that are different, but expectations about the rate of change. It's not enough to develop a well-integrated application with a modern, flexible interface -- you have to be able to adapt it to changing business and technology needs in a matter of days and weeks instead of months and years.
These changing expectations have created an entirely new set of challenges for software engineers. The internet has changed the definitions of terms like "release", "bug" and "application." Adaptability has become the foremost consideration for coders.
On the plus side for developers, the meaning of "bug" has changed a great deal to. An unexpected change in behavior really isn't a "bug" to the web 2.0 user. It's a glitch -- a blip that it typically corrected within 48 hours of occurring. Because when you can deploy a new version every day, your dev/test/release cycle is measured in hours, not months. A "bug" is when an application fails to make a fundamental use consideration -- like functioning on a Blackberry, or over a 3G link, or working on Konqueror in an Ubuntu client, or being simultaneously edited by users on 4 continents.
It turns out Notes/Domino is a great technology for this kind of rapid release approach. The technologies of replication and design inheritance make it a breeze to globally deploy incremental updates in a fraction of the time and complexity that would be required on other platforms. The flexibility of the NSF data store makes it trivial to add a field to a form, or a column to a view. As long as you don't make fundamental design flaws, the platform allows enormous fluidity in behavior from one day to the next. I've used this approach for nearly a decade on every project I've been a part of.
But it's critical to design applications with this evolution in mind. If you focus on quickly delivering to a minimal spec, it's virtually guaranteed that you will lock yourself into an approach that cannot be readily adapted to new requirements. And because your users live in a world where salesforce.com can add a new feature every day, they're going to view your semi-annual release schedule as a failure, and look for a solution that responds at a speed they've grown accustomed to. And that's when you hear the Siren's call to platform migration.
So how do we protect our applications from this kind of failure? Let's hear your strategies for maximizing the adaptability of your solutions. And I'll let you know my own thoughts in part 4.
Thanks for tuning in.
Comments
- separate data from presentation - and never, EVER use UI views for lookup
- use profile docs to store commonly-needed data
- know when to build OO code and do it, and try to avoid code duplication
But also don't be afraid to leverage your hardware. NotesDatabase.Search() can be a big performance and scalability barrier under some circumstances. But the flexibility it gives you (and the always "up to date" state) can often make up for that.
Have you checked out Solid State Disk prices lately? The NSF data model is about to shine.
Posted by Erik Brooks At 04:31:32 AM On 09/03/2008 | - Website - |
As you know, it's often very difficult to get companies to pony up cash to update an application when it's not "broken". However, this is not such a big effort once firms start thinking about application updates the way you do. The rapid release approach gels perfectly with the quick, iterative development concepts that Notes enables us to do so well. The hardest part of getting developers to adopt these ideas will be overcoming the inertia of the corporate IT mindset. I believe a great boon to us here will be Gen Y. As you mentioned, their expectations are far different from their older counterparts (and I'm sad to say I'm now in the "older" demographic
Nice post as always, Nathan!
Posted by Chris Blatnick At 08:13:23 AM On 09/03/2008 | - Website - |
Posted by Tony Palmer At 09:08:23 AM On 09/03/2008 | - Website - |
Funny: I read that line and thought "Chris Blatnick would be the person who could pull that off", and then I got to the bottom of the comment, and it was Chris saying it!
Posted by Maria Helm At 09:17:27 AM On 09/03/2008 | - Website - |
With consumer built expectations of instant gratification vs regulator slow and sure, how do you manage the expectation process of the younger generation?
Posted by Andy Broyles At 09:28:36 AM On 09/03/2008 | - Website - |
You'd have to sell the regulators on accepting that they're validation requirements only apply to one part of that line, but I don't think that would be impossible. My pitch for those regulators would be something along the lines of "do you have to validate the system every time a user changes their default Windows font? Runs in windowed- vs. full-screen mode? Changes their border colors? Puts desktop icons on the right side instead of the left?"
Cynics will say they'll answer "yes," of course. There's always a worst case. But there's usually a better-than-worst case as well, so I'd certainly take a shot at it.
Posted by Nathan T. Freeman At 09:44:43 AM On 09/03/2008 | - Website - |
Now, how to get that adaptability thing?
Truly simple question
Well, its just lots of decisions on very different levels in very different areas. And you will go wrong in a lot of ways like I do each day.
This morning I started to write a comment, but don't wanted to bug you with the gibberish I was writing.
Shorter.
On a very abstract level, its a question of dependencies. To have the fewest possible dependencies and no circular dependencies. The problem is, that it can be really mind boggling to accomplish.
Posted by Axel Janssen At 02:45:28 PM On 09/03/2008 | - Website - |
Posted by Bernard At 08:12:28 PM On 09/04/2008 | - Website - |