Thursday, December 19, 2013

Building Polyfills by Brandon Satrom; O'Reilly Media

Building Polyfills is a fun book to read. It’s about how to contribute to the Polyfill community and build something that can make life easier for other JavaScript developers. Brandon Satrom the purpose and history of polyfills and then walks the reader through building a polyfill for HTML 5 Forms using Kendo UI. What makes this book interesting is its scope. This book covers the creation of a polyfill from picking a suitable subject to publishing it through Modenizr and Github. It covers how to decipher the W3C documentation, the basics of git, the merits of various popular JavaScript frameworks, and even experimental Polyfills that can enhance a developer’s toolkit. The book contains code that is both clear and relevant. In the process of learning how to build a Polyfill, the reader is introduced to Kendo UI. 

All of this information is great for JavaScript developers whether or not they’re interested in building their own Polyfills. The only drawback to this book may be that it has an expiration date. Eventually browsers will even themselves out and Polyfills will no longer be necessary. In the meantime, this is a good read for JavaScript Developers.

Tuesday, October 15, 2013

Visual Models for Software Requirements By Joy Beatty, Anthony Chen; O'Reilly Media

Visual Models for Software Requirements looks at the process of defining requirements from a creative perspective. The premise of the book is that business requirements are not two dimensional like the typical list of "shall" statements. They're layered and multi-faceted mirroring the complexity of business requirements. This book lays out a series of diagramming techniques to help discover all of the intricacies of system flows, business data, and process flows from the level of abstract business goals to individual UI elements.

For someone who is visually minded, these diagrams can be used to plan a system from "soup to nuts." This kind of model reminded me of design thinking, usability design, and system architecture combined. There was very little that I found new, but the way models combined to present a holistic picture is fantastic. It is also an easy to book to read or reference. Each type of diagram has its own chapter with templates, examples, and pitfalls to watch out for. That makes it easy to pick and choose which models best fit your solution and find all the information you need in a concise manner.

Overall, this is a great book to have on the shelf.

Monday, April 22, 2013

Lean UX by Jeff Gothelf; O'Reilly Media

Lean UX is an attempt to find the holy grail of agile user centered design. Jeff Gothelf applies principles of user centered (a.k.a UX) design to the agile software development lifecycle. The philosophy of constant user feedback are at the core of both UX and agile, but their rhythms don't necessarily harmonize. It is not easy to find time in a fast paced agile lifecycle to apply UX.

Jeff Gothelf manages to dovetail pure agile methodology with UX techniques like prototyping and user testing. Lean UX has a lot of great sections on the concepts of UX and agile. However, there is also plenty of concrete examples taken from the author's own experiences. 

Overall, Lean UX is an easy read and a good guide for meshing rapid development while maintaining focus on the end user. It's a well written book that is actually useful for project managers, systems engineers, and designers. There is nothing particularly new in this book, just old principles integrated with one another in new ways. Sometimes, that's all it takes to be truly innovative.

Wednesday, March 20, 2013

Resilience and Reliability on AWS By Jurg van Vliet, Flavia Paganelli, Jasper Geurtsen from O'Reilly

In an effort to pick up some more cloud knowledge, I recently volunteered to review Resilience and Reliability on AWS as part of the O'Reilly Blogger Review Program.
This book is the sequel to Programming Amazon EC2 by the same authors. It dives a little deeper into the infrastructure decisions that must be made when architecting an Amazon Web Services (AWS) application for maximum performance under all types of loads and catastrophic failures. The first couple of chapters are an introduction to AWS and a list of top ten "survival" tips for building AWS applications for resilience and reliability. Subsequent chapters explore how to integrate specific open source tools such as Postgres and MongoDB with AWS to maximize scalability, redundancy, and load balancing. Principles that drive the Infrastructure as a Service (IaaS) model.
The topic is an interesting and timely one. There are lots of books out now on cloud technologies, but this one has a narrow focus that could be of interest to someone building a large scale application using AWS that has high availability and scalability requirements. However, the authors didn't focus on that audience, but instead addressed a narrow topic at a broad audience. The result is schizophrenic.
The beginning chapters are almost too simplistic for an audience interested in an advanced topic such as this, and the subsequent chapters are too cryptic for those without an extensive prior knowledge of the subject to understand. For example, the chapter on top ten "survival" tips includes such gems as "embrace change" and "everything will break." Those tips aren't unique to AWS at all. Any developer who's been around the block enough to be interested in developing large scale applications using AWS should have plenty of scars from learning those lessons on more traditional development projects. On the other hand, the chapters that are solution specific assume too much knowledge of the subject. There are pages of Python code for a number of neat integration tricks, but very little explanation about how the code works. If a developer is familiar enough with the technology to read and understand a Python script for complex AWS integration tasks without any accompanying documentation, they don't need to be reading this book. The entire book is further confused by an awkward writing style. In some places it's written in first person singular and in others, first person plural. Transition and tone are all over the map making a complex subject even harder to follow.
Despite its flaws, this book does fill a niche. The information it contains could help to make better informed architecture decisions. For that systems architect, I would recommend this book with the caveat that you should skip the first few chapters and be prepared to read each subsequent chapter twice to understand it.

Saturday, February 23, 2013

What Good Are Demos?

I recently had an epiphany  Software demos are rarely worth the effort. There are few instances where the resources spent in preparation outweigh the risk of a spectacular public fail that demos entail.

I've participated in countless demos in my career to stakeholders big and small. I've conducted demos for the CEO of a large health care company. I've demo'd software to military officers and college professors. I even helped demo to the President of the United States. I've also demo'd software to librarians, call center workers, and lots of other front-line workers. All of these demos involved a rush to produce something worthy of demonstrating, rehearsal, and a lot of prayer. Some resulted in "attaboys," some resulted in complacent acceptance, and some resulted in complete system re-designs. No one has ever been so blown away by what I've shown that they immediately increased the project budget or gave me a hefty raise. Maybe that's the quality of my demos, but I doubt it.

So why do development projects subject themselves to extra work and stress to conduct demos? Here are a few reasons I've identified:

Collect Interface Feedback - It's a bad idea to use a demo in order to get user feedback on user interface. First, demos are staged and don't reflect anything in the real world. Often in a demo, the demonstrator is the developer who created the software and knows its every nuance. They know exactly what buttons to push and where to go to find what they need. The result is a polished demo that makes the software look easy to use. The demonstrator first shows the user how to use the software and then asks them if it looks easy to use. Of course it looks easy to use, they were just shown how to use it. That's not at all pertinent to whether or not someone who has never seen the software before will understand how to use it.

Collect Aesthetic Feedback - Demos should not solicit feedback on the look and feel of an application. Often, users will comment on the color scheme, layout, or graphic selection of the application. Those types of issues should be consistent with the brand and marketing of the application, not the personal tastes of users. The best way to test the aesthetics of a design is to conduct a branding test. Decide what color scheme you want to use and then ask a sampling of users to tell you what values those colors evoke in them. For example, if the application is handling sensitive information it should convey trust. Pink and purple would probably not be the best color choice. You can do the same type of test for the logos and graphics.

The other reason not to listen to feedback from users on aesthetics is that they aren't designers. When considering someone's opinion on a graphic design, the first thing I do is take note of what they're wearing. If they're telling me my colors aren't appropriate and they have on a Donald Duck novelty tie, their input doesn't count for much. Design is much more than having an eye for color and taste. A good design is well thought out and follows some basic tenets on the presentation of information such as use of white space, font choice, and layout. These are principles that are gained from experience and should not be subject to review from someone's inner artist.

Demonstrate Progress - This is about the only good reason for do a demo. Stakeholders need to see that there is some progress being made and there is no better way to demonstrate that than by showing off the product in action. This is a perfect scenario for your magic show. A good demo that wows stakeholders buys goodwill for the project and creates a positive buzz for the software. The problem is that you need a finished product to create that wow factor, and if the product is finished, it better be what the stakeholders expect. It's like at the end of a barbershop haircut. The barber always holds up a mirror at the back of your head for you to approve of the job he did. If you act shocked at what you see, that's very bad for the barber. There is no way to put that hair back. The worst comment he would want to hear would be something that might require a little extra trim. Similarly, there should be many touch points with stakeholders during the development process so that demos do not result in any surprises. It's important to have a clear understanding of expectations (requirements) up front with sanity checks along the way. If this is done, demos merely reassure stakeholders that you're making progress.

Overall, demos are not a good way to collect any kind of information from stakeholders. The only things they are good for is demonstrating progress. It's natural for a development team to show off the product of their work, but expectations should be set appropriately.