Posts
This blog was guest written by Greg Hubbard. Greg is the Director of Application Development for Q Interactive, a Chicago based digital marketing services company.
When the resistance to technology innovation is discussed, the resistance is usually given the face of the mythical pointy haired boss, the management, finance or business person that “just does not understand!” While this can be the case, sometimes the resistance actually comes from within Information Technology and it should not. IT should be the entity thinking “well, let’s take a look…” While I do not advocate running around trying every new thing that comes along and throwing large sums of money at it in the process, I do promote looking at things in ways that are inexpensive in time and capital commitment. To that end, I use a three step process for trying out a new technology:1. Find a way to try it out with minimal time and budget impact.
2. Discuss my experience in a large community.
3. Try it again.
Read the rest at ComputerWorld.com...
Friday, January 15, 2010
Monday, January 4, 2010
Situational Applications - Build for Today be Ready for Tomorrow
Today I want to talk to you about the concept of "situational applications". The term is relatively new, but the concept is not. The concept is KISS (Keep It Simple, Stupid).
First let's define a situational application: "A situational application is 'good enough' software created for a small group of users with specific needs. . . as the requirements of a small team using the application change, the situational application also continues to evolve to accommodate these changes."
Many of the best applications begin as situational. For example, SMTP, which is the standard protocol for sending email, was initially developed as a simple way to send electronic messages, after the introduction of many bloated formats (including Mail Box Protocol and FTP Mail). Many early internet providers found these original protocols, although comprehensive, too complicated to implement. SMTP, which stands for Simple Mail Transfer Protocol, was developed as a simple way to send text-based messages from point A to point B. The simplicity of the framework caught hold, ultimately became the standard, and has since been enhanced with the features you know as an e-mail user.
Web services are another great example. The original vision manifested as Simple Object Access Protocol (SOAP), which was a comprehensive, complex protocol for allowing different systems to talk to one another. Ultimately, SOAP grew in comprehensiveness and complexity. As a result, Representational State Transfer (REST), a simple protocol that does the same thing as SOAP but without all the bells and whistles, was developed. The result is that REST has taken hold as the preferred standard. REST has continued to evolve to meet additional needs as they gain traction, but its evolution is organic, not forced.
I've had the opportunity to build a lot of new software products for great companies. And the more applications I build, the more I realize that most (if not all) of them are in fact, situational, and should be treated as such. Instead of trying to build the end-all-be-all in release 1, I've found we're more successful successful if we build an application that can addresses the core business problem, and getting it out into the user community quickly. Ultimately, the user community will drive the direction of the application. If a core need is met quickly, the app will be used; and if the app is friendly and appealing enough, users will want to give ideas on how it can continue to make their lives/jobs easier. In all of my years building applications, the most time-tested and well received, have inevitably started by simply solving a "situational" problem. Over time, they have become much more than that, but they all started with a laser focus.
If you are a product manager (or if you work for one) remember to Keep It Simple. Get the product out early and request feedback from users often. Use Agile Software Product Development to get that first release out quickly. The methodology lends itself to this approach. Stay focused on business value and work to achieve it as quickly as possible. Do not try to solve every problem for everyone right away, instead solve the BIG problem for everyone first. Everyone will line up behind you and your product after that to take care of the small stuff.
Please use the comments below to share ways that you Keep It Simple in your software product development, or share your experiences of how your 'situational applications' have become THE application because of laser focus on solving real business problems.
As always, thanks for reading.
-J
Whoa. . .this post was picked up by CIO.com.
First let's define a situational application: "A situational application is 'good enough' software created for a small group of users with specific needs. . . as the requirements of a small team using the application change, the situational application also continues to evolve to accommodate these changes."
Many of the best applications begin as situational. For example, SMTP, which is the standard protocol for sending email, was initially developed as a simple way to send electronic messages, after the introduction of many bloated formats (including Mail Box Protocol and FTP Mail). Many early internet providers found these original protocols, although comprehensive, too complicated to implement. SMTP, which stands for Simple Mail Transfer Protocol, was developed as a simple way to send text-based messages from point A to point B. The simplicity of the framework caught hold, ultimately became the standard, and has since been enhanced with the features you know as an e-mail user.
Web services are another great example. The original vision manifested as Simple Object Access Protocol (SOAP), which was a comprehensive, complex protocol for allowing different systems to talk to one another. Ultimately, SOAP grew in comprehensiveness and complexity. As a result, Representational State Transfer (REST), a simple protocol that does the same thing as SOAP but without all the bells and whistles, was developed. The result is that REST has taken hold as the preferred standard. REST has continued to evolve to meet additional needs as they gain traction, but its evolution is organic, not forced.
I've had the opportunity to build a lot of new software products for great companies. And the more applications I build, the more I realize that most (if not all) of them are in fact, situational, and should be treated as such. Instead of trying to build the end-all-be-all in release 1, I've found we're more successful successful if we build an application that can addresses the core business problem, and getting it out into the user community quickly. Ultimately, the user community will drive the direction of the application. If a core need is met quickly, the app will be used; and if the app is friendly and appealing enough, users will want to give ideas on how it can continue to make their lives/jobs easier. In all of my years building applications, the most time-tested and well received, have inevitably started by simply solving a "situational" problem. Over time, they have become much more than that, but they all started with a laser focus.
If you are a product manager (or if you work for one) remember to Keep It Simple. Get the product out early and request feedback from users often. Use Agile Software Product Development to get that first release out quickly. The methodology lends itself to this approach. Stay focused on business value and work to achieve it as quickly as possible. Do not try to solve every problem for everyone right away, instead solve the BIG problem for everyone first. Everyone will line up behind you and your product after that to take care of the small stuff.
Please use the comments below to share ways that you Keep It Simple in your software product development, or share your experiences of how your 'situational applications' have become THE application because of laser focus on solving real business problems.
As always, thanks for reading.
-J
Whoa. . .this post was picked up by CIO.com.
Subscribe to:
Posts (Atom)