Design to last
Planning for the unexpected Print E-mail
Written by Daniel Leiderman-Gueller   
Saturday, 06 December 2008 00:00

During the design phase of a system or subsystem, one of the frequent issues is the discussion surrounding error handling and abnormal situations. Many programmers see error handling as a never ending tedious work that can never catch all error / abnormal scenarios.

Jeff Atwood in Coding horrors provides an interesting insight for understanding a way of looking at error handling. In short it provides reasoning for understanding the priority of bugs, as related to the frequency users experience the bugs, and some other technical aspects of bug handling. But most importantly he looks at bugs and unexpected events as in two respects:

  • Events handled by the application gracefully, and thus prevent information loss or inconsistency but provide enough stability to continue working.
  • Events so serious that the application fails ungracefully.
Last Updated on Sunday, 11 January 2009 12:57
Read more... [Planning for the unexpected]
 
Convincing and looking for project partners Print E-mail
Written by Daniel Leiderman-Gueller   
Sunday, 30 November 2008 00:00
I have a new project, to help us become a more software guided company and understand the different methods required for software development. The first step I'm taking is convincing the management that programmers need much more desktop space and thus more and larger screens are needed.
Last Updated on Sunday, 11 January 2009 12:55
Read more... [Convincing and looking for project partners]
 
Is virtualization the silver bullet? Print E-mail
Written by Daniel Leiderman-Gueller   
Thursday, 27 November 2008 00:00

Yesterday EMC and VMware held a conference for presenting new developments and upcoming products for 2009. EMC presented information for future directions and upcoming products, for maintaining and improving the datacenter. VMware presented also new directions but also the rationale for using cloud computing.

This got me thinking of virtualization for improving unexpected application uptime and how virtualization actually affects the resiliency of services.

The main idea behind virtualization of servers for resiliency is the possibility of disconnecting the actual hardware installed from the hardware presented to the application, thus providing a facility for facilitating moving applications from one physical server to a different one. The most mentioned reason for changing the physical server is hardware failure and improving application uptime.

Unfortunately, hardware failure is not the major reason for application downtime and this can be easily seen in the following diagram

reasons_for_application_downtime


Original article


This article is from 1999, where only 20 percent of the problems were due to the technology, and things only got worse because the following happened:

  1. hardware became a commodity
  2. software became more complex
  3. we have more abstraction layers
  4. managed programming languages


From the diagram one can see where things are heading; Virtualization helps with the flexibility of managing and fixing some of the problems, but regarding application downtime, virtualization can't change the human related problems.

This proves one of the most important principles in design; the human is the weakest link because all other problems can be solved with additional technology. Thus most emergency systems have only one human interaction - starting the process and get out of the way. From that point everything is done automatically.

We can see here how basic design principles help analyze even new technologies and directions.

Last Updated on Sunday, 11 January 2009 12:45
 
Design, Architecture and system engineering Print E-mail
Written by Daniel Leiderman-Gueller   
Monday, 24 November 2008 00:00
System engineering is all about requirements: managing requirements, translating them to development requirements, understanding if the design / architecture suit the requirements etc. Unfortunately one finds out soon enough that the requirements constantly change and they don't really represent the major hurdles in system design, instead making a design that is flexible enough to be able to adjust with little effort as possible. This site is exactly about understanding the flow of requirements, design, architecture and flexibility.
Read more... [Design, Architecture and system engineering]
 
<< Start < Prev 11 12 13 14 15 16 17 18 19 Next > End >>

Page 13 of 19