The Design Review – Only the Strong Survive

snaggle-toothed-dogLike a 10 year old heading to the dentist, the design review stage of a project is one of those areas that will drive a series of heebie-jeebies in even the most iron stomached software engineer or designer.  You’ve spent time with your users and business analysts.  You’ve diagramed all of the ins and outs of your solution.  Now you have to present your design to others and convince them why your design is the best approach to solving the problem within the constraints of your project.  Let the stomach aches begin!

When considering your upcoming design review, there are a few questions that you need to ask yourself.

  1. What is the target audience for this review?
  2. Has the audience spent the needed time reviewing your documentation?
  3. Are you prepared with answers to those reviewers that want to provide alternatives?

What is the target audience for this review?

Archery_TargetFor a successful design review you must understand your audience.  A strong designer will understand the technical level, responsibilities, and motivations in their design audience.  For example, if you are presenting your design to other senior technical leads within your immediate organization, you will want to structure your presentation to a level of technical review that is much deeper than if you are presenting to a group of architects.  Each type of audience will bring its own challenges.

Keep in mind that there is no design that at least one person can’t review and claim the opportunity for improvement.  Suggestions for change to your designs are occasionally motivated by technical philosophy instead of the merits of the design itself.  A well prepared presenter will use their understanding of the audience to work through these conditions.  As a rough example, sometimes a reviewer will believe that object oriented design is the answer to all solutions no matter the complexity of indirection and/or misdirection that object oriented design offers.  That person will likely challenge your designs on your use of data encapsulation, inheritances, and state if they are not all encompassing.  The more you are prepared to justify your design decisions for this review meeting in those low-level technical areas – they better you will be able to respond.  Just remember that a design review is not about finding a “different design” but to find the “best design” that meets the goals of your project.

Has the audience spent the needed time reviewing your documentation?

800px-Booster-LayoutThe single most time draining failure in a design review is if your audience has not reviewed your documentation before the meeting.  No one usually wants to sit in a two hour meeting listening to you read through your design document line-by-line.  Heck, I don’t even like having to read through my designs line-by-line.  To ensure your audience is prepared for your reviews, make the effort to give each participant the time to complete the review.  I also like to elicit a response from each participant before my design meetings where they are asked to confirm that they have read the design and are coming to the meeting to ask questions about the design itself.

At the beginning of the presentation, inform the participants again that the review meeting is an opportunity for them to ask questions about the design’s approach to solving the problem.   Good meeting management by the presenter is critical in preventing the meeting from turning into a document read-along.   If your project schedule and company culture allows, stopping the review for rescheduling if it becomes obvious that the review was not done by the majority of participants is sometimes a good peer-pressure trick to ensure the participants understand their role in the effort.

Are you prepared with answers to those reviewers that want to provide alternatives?

“Defence is our best attack” Jay Weatherill

The most effective tool a designer has in their arsenal is that of alternative solution investigation.  The designer must spend the time needed to explore the alternatives that may come out of a design review before the review occurs.  As quick on their feet as many designers believe that they are in answering a technical challenge with partially correct answers, I’ve seen situations where the reviewers that actually do know the correct answer to the technical challenge begin to doubt the designer’s credibility.  If you don’t know the answer to the feasibility of an alternative solution – just say so and take it off as a follow-up action.

Remember that the design review is not about you.  The review is about the proposed solution – not the person presenting it.  Assume your reviewers are looking for the best solution for the problem – not attacking your ability to design it.  In the end – if your design is well thought out and you’ve considered all of the possible fallacies of the approach – your design will only be improved by the combination of minds reviewing it but will usually enjoy more support from those that accepted the design.


I’ll provide a personal example to this topic.  I had worked on an application for two years of design, development, and maintenance.  The application had been reviewed over and over by at least 15 difference architects, senior developers, and designers over that period of time.  A new person joined the group and in about 45 minutes of reviewing the design suggested a hole in our solution that had been leaking memory for the entire two years.  We had been lucky enough to have loaded maintenance releases often enough to not have seen it – but sure as heck – it was there.  It never ceases to amaze me how just a single person can sometimes find something that the larger group never recognized.

In summary, embrace these design reviews.  Conducting a series of reviews taken in a positive manner and demonstrating solid understandings of risk analysis and thoughtfulness has propelled many developers into high-level roles and responsibilities.  Look at each design review as an opportunity for you to learn something new.  I assert that if you do – not only will you gain personally through your learning – but the designs you produce will be more solid and less prone to failure…and everyone like to support that kind of software.

Review of Enterprise Data Workflows with Cascading

Enterprise Data Workflows with CascadingEnterprise Data Workflows with Cascading by Paco Nathan (O’Reilly Media) is a great summarization of using the Cascading API.  Paco spends a sufficient amount of time providing a solid overview of Cascading along with an explanation of related extensions such as Pattern and Lingual. Test cases provided allow a novice user to quickly understand the basics of Cascading though some of the test cases followed along the same flows as the Cascading online documentation site.

Enterprise Data Workflows with Cascading is a great resource for beginning users that need to quickly come up to speed on using Cascading.  The book works the reader through evolutions of exercises such as setting up and loading files into Hadoop to using different types of joins along with finally reaching the point of integration points with the different languages and a larger case study based on the City of Palo Alto Open Data.

I’d recommend Enterprise Data Workflows with Cascading as a good entry point and base work to build upon as the reader gains more experience.

Review: Placing the Suspect Behind the Keyboard: Using Digital Forensics and Investigative Techniques to Identify Cybercrime Suspects

Placing the Suspect Behind the Keyboard

I wanted to take a look at a computer-based topic not normally in my programming domain and chose Placing the Suspect Behind the Keyboard: Using Digital Forensics and Investigative Techniques to Identify Cybercrime Suspects by Brett Shavers (O’Reilly Media).

As a former police officer, I found some of the discussions around generic evidence preservation to be slightly difficult to stay engaged with.  However, as a whole, Placing the Suspect Behind the Keyboard did not disappoint my desire to see what digital forensics was all about.  After reading this book, the reader should have a solid foundation to start delving into both the investigative and technical areas of a digital forensic investigator.

Placing the Suspect Behind the Keyboard takes the reader though a step-by-step process to ensure that digital investigations and interviews are carried out in a manner that will preserve the integrity of both your evidence and your suspects involvement.  Shavers reminds us throughout the book that it is not just about finding critical evidence on the digital device – but also ensuring that you can place the suspect “behind the keyboard” while those actions were occurring   With excellent references back to sources to keep you on track, Placing the Suspect Behind the Keyboard keeps the reader in line with well-established investigative procedures.  In addition, the Shavers also covers how to appropriately present your evidence to different types of audiences – something that is more challenging than most assume.

I highly recommend this book to a person just getting into digital forensics or that is looking for taking their technical knowledge to the next level.  While not a highly technical book, it is a great introduction into the digital forensics field.

Disclaimer: I received a free electronic copy of this book as part of the O’Reilly Blogger Program

Review: Metasploit – The Penetration Tester’s Guide

Metasploit: The Penetration Tester's GuideMetasploit: The Penetration Tester’s Guide by David Kennedy, Jim O’Gorman, Devon Kearns, and Mati Aharoni (O’Reilly Media) is very detailed and extremely valuable in demonstrating how penetration testing can be done using Metasploit along with having the great side-benefit of being able to learn about general methods and processes a pentester will go through during the testing cycle (PTES methodology).

The initial chapters deal with introducing the reader to the PTES methodology and Metasploit as a testing product.  As the chapters progress the authors pushes the reader deeper and deeper into the Metasploit product’s features along with how to use those features to complete the penetration test processes.  In the appendix, the authors have provided instructions on how to configure test environments that can support your exploits without sending the Feds to your front door.

Overall, this book is an good resource for those people that have good technical skills in Ruby and are comfortable in a Linux environment that want to understand penetration testing and the Metasploit product.

Disclaimer: I received a free electronic copy of this book as part of the O’Reilly Blogger Program

Review: Developing with Couchbase Server

Couchbase ServerIn reviewing Developing with Couchbase Server by MC Brown (O’Reilly Media), I was impressed with how the author was able to turn the complex topic of NoSQL databases into graspable units of learning.  The book is relatively short for a technical title (88 pages).  However, it is clear that the book strives to get the reader started in the Couchbase technology with references to other online resources that provide much more detail.

Brown provides several easy wins in this title that helped me understand Couchbase in a quick-and-dirty manner that deserve special mention.  The “Getting Data In and Out” chapter provides examples on how to use the Couchbase Client Library in a very concise manner.  The chapters dealing with modeling were also very well written and provided another set of quick wins for my learning.  Finally, the views sections were helpful in understand the aggregation side of the technology.

I would suggest that a reader should look at this book as a “fundamentals and quick-win” work that will get you into the NoSQL paradigm using Couchbase Server.  With that in mind, I recommend it as a good read.

Disclaimer: I received a free electronic copy of this book as part of the O’Reilly Blogger Program

Review: MapReduce Design Patterns: Building Effective Algorithms and Analytics for Hadoop and Other Systems

MapReduce Design PatternsI picked up MapReduce Design Patterns: Building Effective Algorithms and Analytics for Hadoop and Other Systems by Donald Miner and Adam Shook (O’Reilly) to explore the deeper analytics that were possible in using Hadoop and MapReduce.   This book definitely did not disappoint in covering many of the more advanced challenges that engineers working with Hadoop datasets will encounter once they move from the simple into the advanced.  MapReduce Design Patterns is not for the faint of heart nor the true novice in Hadoop and/or MapReduce frameworks.  A solid understanding of the fundamentals of analytics is also a valuable prerequisite to this title.

Having explored the use of Pig and Hive as a way to abstract the underlying implementations of MapReduce, MapReduce Design Patterns helped me understand what was going on “under the hood.”  This was important to me as I have learned the hard lesson that sometimes the easy way is not always the most efficient and/or effective way.  By reading through this title, I now better understand how I can use Pig and Hive for the straight forward analytics and MapReduce native for my more specialized needs – or in other words – use the right tool for the job.

To the bold adventurer new to Hadoop and MapReduce – I’d suggest that you look at this book as your follow-on study guide to be used after learning the basics and working with those frameworks for a little while.  In that view, I have no hesitations in recommending MapReduce Design Patterns to those engineers that are looking for something to help them move from entry level into advance levels of understanding in these technologies.

Disclaimer: I received a free electronic copy of this book as part of the O’Reilly Blogger Program

Review: Hadoop Operations by Eric Sammer

Hadoop Operations by Eric Sammer (O’Reilly Media) is a thoughtfully organized book that guides the operational and architectural reader into a viable Hadoop-centric solution.  In his book, Sammer spends a reasonable amount of time providing the reader with enough Hadoop background to be able to move onto the more complex considerations and actions needed to implement high quality Hadoop clusters in an operations environment.  Sammer provides some very specific information in his books that puts it into my “must have” collection for Hadoop.

First, instead of trying to cover what Hadoop can do in all flavors and colors, Sammer describes configurations that will meet the needs of a general operational implementation.  This allows the reader to focus on the key concepts of installing, configuring, and operating a Hadoop cluster instead of learning the many Hadoop features that most shops will never use.  Secondly, Sammer spends an appropriate amount of time discussing ways that an operational team can monitor and troubleshoot Hadoop clusters.  Very few authors cover the areas needed so that a solution can move from “proof of concept” into a “production-level” implementation.  Third, Sammer looks at products that work around Hadoop to either add features or allow for better maintainability/management of the system.  This gives the reader the ability to see how Hadoop fits into the larger operational model.  Finally, Sammer approaches the chapters in the book from the view of someone that has actually implemented Hadoop clusters by providing suggestion, tips, and tricks that allow the reader to bypass many of the more common challenges that Hadoop adopters can face.

I highly recommend Hadoop Operations by Eric Sammer for the operational and architectural readers that want to get a highly viable solution as soon as possible.

Disclaimer: I received a free electronic copy of this book as part of the O’Reilly Blogger Program

Review: Introducing Regular Expressions

Regular Expressions Reviewed by Jason ArmstrongI read Introducing Regular Expressions by Michael Fitzgerald (O’Reilly Media) to gather deeper insights into the details behind regular expressions.  Fitzgerald does not disappoint.  The reader should sit back and prepare to drink from the fire hose as Fitzgerald drives through regular expressions in many of their entry level flavors and styles.  Introducing Regular Expressions is not for the faint of heart as the reader must navigate lots of regex simulator tools and platforms in order to practice the examples that Fitzgerald fires at the reader without mercy.

If the reader is prepared for a no fluff introduction into regular expressions, then this book is for them.  The reader must be prepared for the technical hurdles needed to execute the samples provided in the book.  Fitzgerald has the reader execute regex in toolsets such as sed, grep, perl, Cygwin, vi, ack, vim, and even more regex simulation tools.  The tool setups can quickly become a distraction to the reader as they spend more time bouncing between tools than actually understanding at depth the reasons behind the samples themselves.  However, as long as the reader takes the time to work through the tools and samples, they will not only gain knowledge in regular expressions, but also many common toolsets.  At its heart, this toolset requirement demonstrates to the astute reader an understanding that unlike many IT “languages” there is no single regular expression structure or behavior.  Demonstrating that you may have to customize your use based on the tools you choose.

Overall, I’d recommend this book for two main reader types.  The first is for the reader that is looking to understand the overall behaviors and traits of regular expressions without a 500 page manual with lots of fluff.  The second is for the reader that has a basic understanding of regular expressions but would like a quick reference on why the expressions work the way they do in many cookbook and internet examples.

Disclaimer: I received a free electronic copy of this book as part of the O’Reilly Blogger Program