I recently acquired a design tool – a set of IDEO method cards, where each card presents a design approach or a method of gaining inspiration. IDEO’s design philosophy is to keep people at the center of the design process, and the four categories they divide the cards into reflect this:
Ask people to help.
Look at […]
In my previous article Architecting for Deployability, I wrote about the importance of deployability - how reliably and easily software can be deployed from development into the production environment. To accomplish this, one approach I recommended was to encapsulate differences between environments to isolate them from the majority of the application, and thus simplify deployment. […]
I have been thinking a lot lately about how to create reliable systems. I previously examined the link between complexity and reliability. Recently, however, I have come to appreciate the impact of error handling on reliability. For the purposes of this discussion, I consider two aspects of reliability: correctness - does the application produce the […]
Unrestrained complexity is a critical limiting factor in producing working software. The more complex a system, the more it will cost to create and operate and the less reliable it will be. Yet the bane of complexity is largely ignored by the IT industry. Software vendors, competing on the basis of feature sets, are constantly […]
I stared at my code on the screen, but inspiration wouldn’t come. I was trying to design a new feature which shared some commonalities with the existing code base. In particular, there were a couple classes that I knew I could reuse. I just wasn’t sure how they would have to be modified because I […]
There are two approaches to handling internal application errors. In the fail fast approach you immediately terminate the operation (or even the application) once an error is detected. In the degrade gracefully approach you try to continue with as much of the operation as you can.
For quite a while I have been a firm proponent […]
