dvrom.eu

Tools, Specialists and Faith

Quote from Michael Nygard - The Future of Software Development”:

"Speaking of languages, many of the problems we face today cannot be solved inside a single language or application.
The behavior of a web site today cannot be adequately explained or reasoned about just by examining the application
code. Instead, a site picks up attributes of behavior from a multitude of sources: application code, web server configuration,
 edge caching servers, data grid servers, offline or asynchronous processing, machine learning elements, active network
devices (such as application firewalls), and data stores. "Programming" as we would describe it today--coding application
behavior in a request handler--defines a diminishing portion of the behavior. We lack tools or languages to express and
reason about these distributed, extended, fragmented systems. Consequently, it is difficult to predict the functionality,
performance, capacity, scalability, and availability of these systems."

I couldn’t agree more with this…

If you like good, easy-reading and free knowledge like me, you will surely find taking a look at 97 Things Every Software Architect Should Know worthwhile.

Every software project is different, and has it’s own and unique needs, and as Edward Garson points out in Context is King:

“I feel there is a certain irony in trying to impart something about architectural ideals, when the very premise I wish to begin with is that effectively there are no ideals. If this is indeed the case, then surely there is nothing to write, I am a contradiction and by doing this I run the risk of the universe imploding or something like that.”

However:

“But alas, ceci n’est pas une pipe.”

I also believe that software engineering projects do share some common issues (or at least I hope for this, any morale booster is welcomed: software engineering is such a challenging discipline that despair is frequent !).

“97 Things” points out some topics and solutions that should probably be applicable for any software engineering endeavor.

There are some big names and many years of experience behind these tidbits of wisdom, and in my short career so far, I have found many of the described issues in “97 Things” in past and present projects.

Because 97 things are too much for my short term memory, these are the top 3 things to know that I strive to remember:

Michael Nygard is a professional programmer and architect with over 15 years experience, and also the author of “Release It! Design and Deploy Production-Ready Software”.

Having encountered this book on many “Top Books a Software Engineer Must Read” lists, I thought i’d give it a try.

This will not be a in-depth review, as there are already many out there, but rather a summary of ideas that will stay with me after this first read.

Michael’s book is all about the problematics related to successfully executing software systems in production, and although it is centered on high availability and large scale distributed systems, many of the discussed topics can be applied to any software system.

The book covers all the possible elements and layers of software engineering I can think of: management, delivery, testing, design, coding…, front-end, back-end, deployment, etc., and rather than trying to answer all the questions, it tries to point out the good direction in which to go.

This is certainly a book that I expect to come back to in the future, as the ideas and scenarios that will stay with me after this first read are only the ones which I can relate to, because I have encountered them in current and past projects.

One of the first projects I worked on has finally been replaced and gone to wherever dead code goes…

Looking back now, this extremely simple CMS was one of the most successful projects I have ever worked on so far, in terms of longevity (it was in production for the past 5 years) and user feedback.

It is also probably the simplest solution I ever worked on (no complicated development processes, no clever code, no pattern abuse…) and it reminds me of a quote I remember reading once that was somewhere on the lines of:

I would probably rephrase this statement to:

In the same sense, I would also state:

My quick exposure to the vast world of J2EE, ORM Frameworks, Enterprise Patterns, the Java API, Web Frameworks and other candidates for abuse in the projects that followed this simple CMS, combined with my “bring it on!” rookie prepotency, led to some ugly code and some terrible over-engineering…

Not only wisdom, but also ignorance, can sometimes produce the best results…

Stress testing, Load testing, Performance testing, Capacity testing…they all are based on the same idea:

• Software systems are usually built to be used, and chances are that, at one point or another, you will want to know how your system reacts on heavy loads, and, in case the results are not satisfactory, you will want to improve the systems performance.

A first question arises:

Should it be done at some particular phase or should it be triggered by some specific requirement?