Having spent most of my time reading purely technical books to solve specific problems, it was refreshing to read a higher-level book that talks about good programming design. Release It! is by far one of the best books I have read and really opened my mind to areas of program design that I had only started to touch the surface on.
As it is one of the best forms of persuasion, I really enjoyed the story-telling in the book. I felt that it gave the main content of this book depth and realism. It is good to know that everyone makes these types of mistakes.
The main contents of this book are broken up into four distinct areas. The first two areas describe stability and capacity patterns and anti-patterns. It was interesting to read the unique challenges that large scale applications with millions of users face. Things that we take for granted in smaller websites just wouldn't do in larger ones. For example, say you want to stop a bot from scanning your site. An easy way to do this is to force all the bots to establish a session before granting them access to content. Most (read all) bots cannot hold a session since they are there purely for scrapping purposes. The problem with this is that each session that is created because of a hit from a bot is stored somewhere in memory on a server. Combine that with thousands of users trying to use your website at the same time, and we have a problem. On small sites, you could probably get away with the memory being tied up for a specified timeout period, but on larger sites, you will not be so lucky.
The stability patterns described in the book are as follows:
1) Use timeouts
2) Circuit Breaker
3) Bulkheads
4) Steady State
5) Fail Fast
6) Handshaking
7) Test Harness
8) Decoupling Middleware
The capacity patterns:
1) Pool connections
2) Use Caching carefully
3) Precompute Content
4) Tune the garbage collector
He then goes on to describe some general design issues that has come up in his vast experience. He talks a lot about developing SLA's with the business (or client) and then using those to help define the level of redundancy that a particular application needs. He also talks a lot about administrating interfaces. If you don't build applications that can be maintained, guess what, they won't be. In the last section he talks about some coding designs that should be incorporated into any development process. Those things include concepts like transparency.
It is interesting to be in this industry. You see many projects directed towards delivering results with very little design up front. The fact of the matter is, companies would probably save a lot of money if they spent more on the design time. You have to understand that designs can be reused. Chances are you are building applications a certain way because they fit your business style. With that in mind, other applications that you develop will also meet that same style. A bit of planning and design a head of time will have huge rewards in the long run and benefit projects down the line. Another problem that I see is that consulting firms are hired based on price, but not on quality. I sometimes feel that business have a hard time separating the good from the bad. Did the project meet the requirements? maybe.... Did the project meet the budget? yes.... CHECK! Little do they know that the application was not built in an extensible way. It was not built with any future considerations. It will need to be replaced in 3 years rather than 5.
In any event, I recommend that all developers read this book, and, most importantly, keep the concepts that he talks about in this book in the back of your mind when developing any application. You will probably find that your application handles failure better, and delivers a better overall customer experience.
No comments:
Post a Comment