Software reliability is a major problem. In an effort to improve the integrity of a software application, the software industry has struggled to find a reliable way to approach software development and design. There is a strong trend in the industry to mimic engineering when designing and building software. In principle, this is a good idea because there is a lot of experience in that area, and the process of having one expert build the plans from a high level all the way down to the smallest detail has seemed to work well in producing buildings and bridges that don’t fall down. In this case, a Civil Engineer is responsible for the integrity of a bridge-building project and will develop the plans for the bridge, down to the placement and size of each bolt and rivet. The construction worker, who is considered not to have been trained as an engineer, is expected to follow these plans to the letter without exhibiting any creative thought in the process. If an error in the plans is found, it is brought to the attention of the engineer, who is responsible for finding a workable solution.
The problem with applying this model to Software Engineering is that software developers are creative people trained in many of the same disciplines as the software architects; in fact, in most cases only experience distinguishes a software developer from a software architect. When presented with a problem, each software developer will have a unique way to approach it, and is very capable of managing the details of how to implement that approach. To ignore this fact and to have an individual build software designs down to the last detail comes at the expense of allowing a team of highly intelligent, creative problem-solvers to contribute to and improve the design. And, when there are competing, workable solutions to the same problem, and developers are given the freedom to decide which is best, the integrity of each piece will improve, and thus the integrity and reliability of the application on a macro level continues to improve.
The following is a piece I wrote for a response to a Request for Proposal on identifying customer needs in a Web 2.0 environment. No portion of this article may be reproduced in any form, or by any means, without prior written permission.
Overview
In the internet era, in which users think in terms of services rather than packaged software, services are expected to be available on-demand and improve over time. Web-based services typically have no versions, no installations, and no upgrades that the user interacts with. The traditional software development lifecycle of design-develop-test-ship-install is becoming less common as software has increasingly become a service which is always on, always improving.
For development of these services, this shift impacts the entire software development model and delivery process. Success now relies on the adoption of an iterative development model in which software is continuously improved and the users become key contributors to the development process and ongoing support of the online service becomes a core competency
This greatly improves the time to market of an application, reduces the risk of all parties involved, builds a closer relationship between the users and developers and ultimately produces a product that is not only more stable but more closely matches what the users require from the service.
We went skiing in Whislter, BC with Pat and Val and had a total blast. For those of you who haven’t been to Whistler, Whistler isawesome, it will blow your mind. Before Michelle and I moved to Seattle, we always wanted to plan a ski trip here, and it never worked out. We were really excited to finally go last January and got to start exploring it then, and we were even more excited to share what we’d learned with Pat and Val.Whistler-Blackcomb is insanely big. Not only does it have the most vertical of any ski area in North America (remember, Whistler is in BC, Canada), but it also has more terrian on one mountain than any other resort. And what really gets your noodle in a mess is that there isn’t only one mountain, there are two: Whistler and Blackcomb, and they are building a gondola that connects the two peaks. To our suprise, both mountains are awesome and definitely need to be explored.
And, to top it all off, the base of the mountain is only at 1000 feet because it’s so close to the coast, which means that you’re not at altitude, which is mercy on your endurance. The only downside is that t’s in the Northwest so you never know what the weather will be like, and since it’s so low, if it’s warm, it could be raining on the mountain. Which, believe it or not, is what happened to our trip with Pat and Val. Not to worry, though, it’s still skiing, and the skiing was great!
has struggled to find a reliable way to approach software development and design. There is a strong trend in the industry to mimic engineering when designing and building software. In principle, this is a good idea because there is a lot of experience in that area, and the process of having one expert build the plans from a high level all the way down to the smallest detail has seemed to work well in producing buildings and bridges that don’t fall down. In this case, a Civil Engineer is responsible for the integrity of a bridge-building project and will develop the plans for the bridge, down to the placement and size of each bolt and rivet. The construction worker, who is considered not to have been trained as an engineer, is expected to follow these plans to the letter without exhibiting any creative thought in the process. If an error in the plans is found, it is brought to the attention of the engineer, who is responsible for finding a workable solution.
it will blow your mind. Before Michelle and I moved to Seattle, we always wanted to plan a ski trip here, and it never worked out. We were really excited to finally go last 
