Plush red curtains withdraw to the sides of the wide stage, only the dark of midnight can be seen beyond them. A tall figure with a top hat strides into the spotlight at the center of the stage. The weight of anticipation presses us into our seats like breathless astronauts at take-off as we wait for something “never before seen by any audience.”
The magician raises both hands into the air as though preparing to pull himself up on an invisible bar. After a pause just long enough to hear your heart beat loudly twice, the magician pulls down hard on nothing until his knuckles rap the floor. Lightning flashes and thunder cracks. The stage is filled with a pyramid of elephants, maidens juggling bowling pins, and a flock of doves darting over our heads and towards the back of the theater.
Software is indistinguishable from magic. It gives us the power to conjure new capabilities at the click of a mouse. Magic springs from our fingertips. We move electronic mountains of information, we uncover patterns that were previously invisible. New revenue streams well up out of the internet. Users eagerly try new software, hoping for a magical experience. Developers demonstrate new software reveling in the reaction of the users, journalists, and bloggers.
Timing is everything. The only magic of poor timing is a disappearing audience. When the search engine Cuil was launched, users of Google everywhere wondered what sort of new trick Cuil had up their sleeves. 120 billion indexed pages seemed unfathomable. Unfortunately, Cuil’s timing was off and the effect fell flat. Just as it would be if you saw a wire during a levitation act, Cuil was revealed to be ordinary software with bugs and scalability problems.
When the timing is right, as it was with the introduction of the first iPhone and its amazing user interface, software can send a tingle up and down your spine. I still remember my first experience with software. It was a simple Tic-Tac-Toe program at the Boston Museum of Science in the early 70’s. There were just a few stations and you had to wait your turn in line. It was amazing to me that a computer could play Tic-Tac-Toe against a person and win.
I kept going back for more until Dad asked me if maybe I’d like to visit some of the other exhibits. I suggested we go to the gift shop because I knew they had a plastic mechanical computer kit for sale. It was called a DigiComp and it could be programmed to do simple computation including playing the game of Nim. It was pure magic.
What was your most magical software experience? Post your comment below!
Part 2: The Magic of Demos
Wednesday, July 30, 2008
The Magic of Demos
When I started writing software, I enjoyed the thrill of showing people something they hadn’t seen before. Even today, one of the main reasons I enjoy working in the software industry is the thrill of demoing new software. When you demonstrate new software, you become a magician, conjuring feats of computation that dazzle the imagination. The audience starts out skeptical, wondering if you are just a two-bit side-show act. You slowly build up to the main event and then, when you’re lucky, they gasp in amazement as you show them something that they’ll no longer be able to live without.
One of my favorite demos was many years ago when I was showing an early version of a product to some folks for feedback. As part of the demonstration I interrupted the power to the laptop (with the battery already removed), and showed them that the software continued as though nothing had happened when the power was restored.
Even though we had told them that the software wouldn't ship for at least six more months, they called us the next day to place an order anyway. For them, the value outweighed the risk. We decided to accept the order. That early exposure to a real customer changed the way we thought about things. Even though we considered the product to be pre-release, we made sure that every new feature worked as it was developed instead of waiting until the end game of the official release. As a result, the end game was much smoother than we had expected.
The Magic of Agile Development
From a business perspective, the main reasons I appreciate Agile development are an increase in quality and ROI, more options, and higher visibility into progress and status compared to traditional development. But from a purely personal perspective, the reason I enjoy Agile development is because it made my job more fun.
Today, thanks to Agile development, I interact with customers more than ever before. As a product owner, I do more demos and am able to provide new features that hit closer to the mark faster and more frequently than ever before. This in turn means more oohs and ahs from customers which is more fun for me and more profitable for the business.
Related:
One of my favorite demos was many years ago when I was showing an early version of a product to some folks for feedback. As part of the demonstration I interrupted the power to the laptop (with the battery already removed), and showed them that the software continued as though nothing had happened when the power was restored.
Even though we had told them that the software wouldn't ship for at least six more months, they called us the next day to place an order anyway. For them, the value outweighed the risk. We decided to accept the order. That early exposure to a real customer changed the way we thought about things. Even though we considered the product to be pre-release, we made sure that every new feature worked as it was developed instead of waiting until the end game of the official release. As a result, the end game was much smoother than we had expected.
The Magic of Agile Development
From a business perspective, the main reasons I appreciate Agile development are an increase in quality and ROI, more options, and higher visibility into progress and status compared to traditional development. But from a purely personal perspective, the reason I enjoy Agile development is because it made my job more fun.
Today, thanks to Agile development, I interact with customers more than ever before. As a product owner, I do more demos and am able to provide new features that hit closer to the mark faster and more frequently than ever before. This in turn means more oohs and ahs from customers which is more fun for me and more profitable for the business.
Related:
Wednesday, July 02, 2008
The Simplest Thing That Could Possibly Work
One of the principles of Agile, mostly related to design and architecture, is “The Simplest Thing That Could Possibly Work.” This is sometimes taken as a license for cowboy coding. But that is not the intention. A better way to express it would probably be something like “The Simplest Solution That Could Possibly Satisfy Your Requirements.” For instance, if you have a requirement to create the back end for a web site like amazon.com, then while a perl/cgi solution on a single core machine could possibly “work,” it doesn’t work from the point of view of high availability, fast response time, or reliability.
From Oversimplification To Rube Goldberg
On the one hand, there is a wide spectrum of complexity of construction ranging from doing nothing to Rube Goldberg level complexity. On the other hand, there is the set of solutions that work, meaning that they meet all of the requirements. TSTTCPW refers to the solution which works and which is lowest in complexity.
Part of being simple means simple to read, maintain, use, design, understand, and implement balanced against the time it takes to get the job done. Spending too much time to create the ultimate in simplicity starts to get you into a different kind of trouble.
As somebody that struggles to apply this principle on a regular basis, I was happy to stumble upon an example of this principle which can be captured in a picture and kept in mind as I am working on a new design. Perhaps you will find it to be useful food for thought as well.
A Bridge Too Far
There’s a construction project that you’ve probably heard of which is affectionately called the “Big Dig.” Part of this project was the construction of the “Leonard P. Zakim Bunker Hill Bridge” aka the “Zakim bridge.” This part suspension bridge, part cantilever bridge is an enormous one of a kind architectural marvel. It supports five lanes of traffic in either direction for a total of ten lanes. It was built at a cost of approximately $11M per lane.
Running parallel to the Zakim (to the left in the photo) is the Leverett Circle Connector Bridge. It serves a total of four lanes of traffic. It was built at a cost of approximately $5M per lane.
Part of the requirements for the Zakim bridge were clearly “create a stunning new Boston landmark.” On the other hand, the Leverett Bridge is a very simple but also very strong bridge. It could have been made even more simply, but not without a safety risk and/or a shorter lifespan. In other words, it is “The Simplest Thing That Could Possibly Work.”
Next: The Faberge Egg
TOC: Zero to Hyper Agile in 90 Days or Less
[Note: revised 7/3/08 to reflect comments on reddit. Clearly the original post didn't work. :) ]
From Oversimplification To Rube Goldberg
On the one hand, there is a wide spectrum of complexity of construction ranging from doing nothing to Rube Goldberg level complexity. On the other hand, there is the set of solutions that work, meaning that they meet all of the requirements. TSTTCPW refers to the solution which works and which is lowest in complexity.
Part of being simple means simple to read, maintain, use, design, understand, and implement balanced against the time it takes to get the job done. Spending too much time to create the ultimate in simplicity starts to get you into a different kind of trouble.
As somebody that struggles to apply this principle on a regular basis, I was happy to stumble upon an example of this principle which can be captured in a picture and kept in mind as I am working on a new design. Perhaps you will find it to be useful food for thought as well.
A Bridge Too Far
There’s a construction project that you’ve probably heard of which is affectionately called the “Big Dig.” Part of this project was the construction of the “Leonard P. Zakim Bunker Hill Bridge” aka the “Zakim bridge.” This part suspension bridge, part cantilever bridge is an enormous one of a kind architectural marvel. It supports five lanes of traffic in either direction for a total of ten lanes. It was built at a cost of approximately $11M per lane.
Running parallel to the Zakim (to the left in the photo) is the Leverett Circle Connector Bridge. It serves a total of four lanes of traffic. It was built at a cost of approximately $5M per lane.
Part of the requirements for the Zakim bridge were clearly “create a stunning new Boston landmark.” On the other hand, the Leverett Bridge is a very simple but also very strong bridge. It could have been made even more simply, but not without a safety risk and/or a shorter lifespan. In other words, it is “The Simplest Thing That Could Possibly Work.”
Next: The Faberge Egg
TOC: Zero to Hyper Agile in 90 Days or Less
[Note: revised 7/3/08 to reflect comments on reddit. Clearly the original post didn't work. :) ]
Subscribe to:
Posts (Atom)