Designed for Humans

Yaacov Apelbaum-Designed for Humans

In my previous life, I was a civil engineer. I worked for a large power marine construction company doing structural design and field engineering. The work assignments were pretty interesting. I got to blow up a bridge, salvage a sunken vessels, and build a lot of interesting marine structures.  On one of my projects, I was given the responsibility to design a set of beds for pre-stressed concrete piles.  The design challenges in this project were significant. We had limited real-estate and the loads involved were higher than any previously attempted.

Yaacov Apelbaum-Prestressed Concrete Piles Beds for pre-stressed concrete have massive anchors on each end. Between them steel forms are placed and steel cables are strung.  The cables are first tensioned, then the concrete is poured into the form.  When the concrete hardens, you cap the cables and cut them.  The result is a pile or a girder that is significantly resistant to various loads.

Following best engineering practices, I completed a structural load analysis document, a set of production blueprints with full dimensional drawings, welding, coating and assembly instructions, a bill of materials, and even a balsa scale model to help the manufacturing facility to visualize my design. Yaacov Apelbaum-Prestress Bed Scale Model

I was proud of my hard work and I felt that it was a great achievement.  The day before the presentation, I went over all the calculations again and rehearsed my slides.  After one last sleepless night, I arrived to the conference room to find several structural engineers, the yard superintendent, a number of field engineers from several divisions, and the chief engineer from corporate, an elderly white haired gentleman in his mid-sixties.  I remember feeling confident in my ability to sell my design to them.

The entire presentation went off without a glitch.  There were some stylistic comments but the overall feedback was good.  After the presentation, the chief engineer stopped by, shook my hand, and said that he liked my design very much.  Then with a straight face, he told me that he expected to see two additional alternative designs before we finalize our decision.

I was speechless.  “I’m not sure I understand, sir” I said. “Didn’t you just say that you liked the design?” I pointed out that none of the participants had found any flaws in my proposal.  “Why", I asked, “did you think we need to develop two additional designs?”

He paused for a moment, and then said, "You never know what the best idea is unless you compare several good ones side by side." I nodded politely, but I was disappointed. I felt like this was probably some form of engineering hazing. Was it truly the case that it’s impossible to achieve reasonable quality on a first try? I didn’t really understand how valuable his advice was until years later.

Yaacov Apelbaum-Pre-Stressed Concrete Bed

Completed pre-stressed concrete beds

Fast forward several years. I switched from civil engineering to software development.  At the time I was working as a lead front-end designer.  One of our key customers hired us to migrate a large VC++ client to a browser application.  In the mid-nineties, rich browser based clients were relatively unheard of.  We were stumped. Problems like session security, persistence, and lack of basic GUI controls seemed Insurmountable.

During meetings, I would regularly sketch various GUI solutions.  But I often found that as soon as I came up with a solution, a new set of problems would be exposed and a redesign would be necessary. In retrospect, most of the ideas I came up with at the time were sub-par. But with each design, no matter how bad, another potential solution was discovered.  Each new design I sketched out was closer to the solution than its predecessor. Even the poor designs peeled away some layers that obstructed the problem that I didn’t initially see.

After dozens of attempts, I had an epiphany and came up with one design that it was possible to implement in several ways. Sketching and contemplating the various designs helped me tremendously, but when the time came to present my solution, I made a tactical mistake. I deliberately neglected to show all of the other working ideas for fear that they would think that I was a mediocre designer; why else did I need to work so hard on so many designs just to yield one single decent one.

I realized in retrospect that there would have been any number of acceptable designs and by not presenting some other ideas I considered before arriving at the one I chose, I short changed myself. If anybody had suggested one of the other options I had discarded but not mentioned, I would have had to explain that I had already discarded that idea. But at that point , it would jeopardize my credibility because it would look as if I was only trying to brush them off.


 Yaacov Apelbaum-Poor Design   Yaacov Apelbaum-Quality Design M1917

Multiple product designs

After participating in and leading many painful design meetings, I have come to the realization that the best way to sell the top design idea is to first share some of the alternative and inferior designs.

If you are responsible for usability or user interface design, you have to develop at least several alternative options for credibility purposes. By that I don’t mean that you should become a cynic and create duds just for the sake of generating volume. The alternate ideas have to represent meaningful and functional choices.

Once you have your alternates worked out, walk through the various options during your design meeting and call out what the pros and cons are for each and what the overall solution trade-offs would be. When discussing designs, place emphasis on both the positive and negative qualities of each alternative.  This will help your peers view you as an unbiased and professional presenter.  Also, you may find that when you present your top candidates, your team will come up with some hybrid solutions that otherwise would have been impossible to generate if you had only presented a single one.

Nowadays, I am often tasked with working on problems that are exceptionally difficult to overcome (with respect to both technology and schedule) and the typical, off the shelf solution is just not sufficient. But there is hope. Usually after a few days of intense interterm deliberations complete with often heated exchanges of alternate designs, magic happens.

My secret sauce for breaking down the most difficult design problems consists of the following steps:

1. Get your entire team into a conference room, order plenty of pizza and write down all possible solutions on the whiteboard. Make sure that everyone offers an opinion. Don’t make any go-no-go decisions during your first meeting; rather leave the information on the board for several days (don’t forget to mark it as ‘do not delete’)  and schedule a follow-up meeting. Tell everyone to document the pros an cons list for each option and provide specific use cases.

2. Get your team into a conference room a second time, order plenty of pizza and write down the pros and cons list for each choice.  Boil down your choices to the top three candidates.

3. Work out the feasibility of each of the top three candidates and cast a vote for the best one.  This is the time to establish consensus and a team buy-in.

    Way back when the chief engineer asked me to come up with two additional alternate designs, he was in fact telling me that no matter how talented a person is, there is tremendous value in variety.  He was also saying, that in order to come up with a ‘good’ design there must first be several inferior ones. If you are responsible for the design of any product futures, you will want to encourage your team to flesh out the bad designs on the whiteboard or as POC, not in your final product.  Unfortunately, the only way to achieve this is by expending resources and time exploring several possible solutions, up to and including some unattractive ones.

    A common development folly (see It’s Good Enough for me) is the notion that there is in fact a ‘best’ solution or one right answer to a given problem.  Actually, the opposite is true. Considering time and resources, in most cases, the ‘best’ possible solution isn’t worth the effort and a ‘good’ solution would more than suffice.

    If you are curious abut which design I ended up using for the prestress pile beds, it was the third one.  It turns out that unexpectedly, after I reconsidered the problem again, I realized that due to the yard’s location at sea level, the water table was too high to accommodate my initial proposal. As a result, my updated design required various modifications in order to solve this problem.

Live, design and prosper.


© Copyright 2010 Yaacov Apelbaum All Rights Reserved.


Political Science 101

Yaacov Apelbaum-Political Science 101
The Arrest of Science

Having kids in elementary school comes with several important parental commitments. Ranking high among these is the participation in the yearly science project. The main objective is to expose kids to the fundamentals of the scientific method. Following the principal of "learning by doing," children, with the assistance of their parents, are required to conduct and showcase a yearly science experiment.

In our school district, exhibition day is a long-awaited, festive event with hundreds of projects being showcased at the school’s gymnasium. It is a great opportunity for families to mingle and view each other’s work. To spice things up a bit, at the end of the event, a panel of teachers selects the top three projects for each grade. The 1st place winners are then entitled to enter their project into the yearly regional competition that takes place at Brookhaven National Laboratory, a much coveted honor.

Although it is a great concept in theory, for some, the yearly science project can become a dreaded event, often testing a family’s procrastination capacity to the limits. On the weekend prior to the project’s due date, it is not unusual to find many agitated parents with kids in tow still scouring craft stores for project display boards and other supplies. In our family, however, we’ve come to view this assignment as an important pedagogical opportunity worthy of careful planning and execution.

I am fan of Richard Feynman, and have enjoyed reading “Surely You’re Joking, Mr. Feynman!”.  This book in addition to being an excellent primer for the budding technology hacker, inspired me to instill in my kids the importance of not falling victim to the “Cargo Cult” syndrome, and being honest and original in one’s approach to scientific discovery.

As it turns out, this has been a winning strategy for us. Since we started conducting science projects 4 years ago, we’ve been fortunate to have won several first place awards. Some of our past projects included experiments on bottleneck formation, sound propagation through  vacuum, and algorithms and mathematics used by a spider to construct a web.

This year, during a routine morning school drop off, our 4th grader, Sheva, noticed that a traffic bottleneck formed regularly at one of the entrances to her school. After discussing her observations during dinner  she proposed to dedicate her project  to deciphering it.

Over a period of several days, we examined the traffic patterns, (volume, arrival and departure times, vehicle speed, etc.), but it seemed that there was no single significant cause to which we could attribute the formation of the bottleneck. We were stumped and unsure as to how to proceed. It was during one of the site visits that my daughter noticed a hawk hovering over the area. She commented that it would have been great if we could observe the traffic from above. Well, I thought, we may not be able to fly over the site like a hawk, (it is a residential area so a fly-over in an Ultralight would be out of the question), but we could certainly build an airborne observatory to do it for us.

After considering options, we decided that a fixed winged propeller driven aircraft wouldn’t work because the wind gusts at the area can reach up to 40 mph. Another constraint was that we would need a sustained, 30-minute flight to capture the entire bottleneck sequence which would be prohibitive.

In the end, we decided to build a lighter than air aircraft (Image 1) and after an intense weekend of design and fabrication we had a functional observatory. It took several test runs to get the flight characteristics and image quality right, but by Monday we were ready to conduct our operational flight.

Yaacov Apelbaum-Aerial Traffic Observation System (ATOS)

Image 1: ATOS (Airborne Traffic Observation System)

Flight Navigation and Imaging Specifications
  • 4′ Chloroprene weather balloon with 1.7 lbs of lifting capacity
  • Riveted aluminum base cradle
  • Flight control and stabilization via 2 tethers
  • Canon FS100 Flash Memory (16 GB) camcorder with image stabilization
  • Wireless broadcast via an Amimon’s wireless modem, streaming HD 1080P/24 video at 120 Hz over an encrypted connection to a base station laptop

The first flight of ATOS was smooth, producing an excellent video feed.  Back home after evaluating the images, Sheva almost instantly identified the source of the bottleneck.

It was apparent that the two-way traffic at the entrance to school was restricted to only smaller vehicles. As soon as the school buses arrived for their daily drop-off and pick-up, they forced all vehicles into a single file, which resulted in the immediate formation of a bottleneck.

Yaacov Apelbaum-Aerial Observation-1 Yaacov Apelbaum-Aerial Observation-2 Yaacov Apelbaum-Aerial Observation-3

This discovery was somewhat puzzling because, from the ground, the road (which is nearly 31′) seemed wide enough to comfortably support the passage of two side by side buses. So, on our next field trip we decided to measure the gate (Illustration 1) that blocks the entrance in question.  Armed with the gate’s measurements, we then consulted the traffic calming section in the NY highway design manual and quickly concluded that indeed the gate was at fault.

Yaacov Apelbaum-Gate 
Illustration 1: Gate Dimensions

So science aside, installing a gate that blocked over 30% of a high traffic thoroughfare was clearly a bad idea, not to mention that it violated numerous design codes. The gate and the fences that are attached to each of its sides also posed a series safety hazard because drivers who were unaware of the obstruction might plow directly into the fence, while still others who miscalculated the gate’s clearance could potentially scrape the posts supporting the gate.

On the day of the science fair, I approached the school principal and inquired about the origin of the gate. I explained that it appears that someone had either made a design or installation error because the gate’s posts should have been placed on the sidewalk curbs, off the driveway. The rationale for this being that when the gate was completely open it would allow for unrestricted traffic. The principal told me that the decision to construct the gate preceded her time in office and it had been influenced by the homeowners just down the street who complained that the traffic had become a nuisance. To reduce the traffic in order to appease the homeowners, the school agreed to install the gate as built.

Not satisfied with this explanation, I proceeded to point out the hazards posed by the gate as it stands and began to enumerate various doomsday scenarios. The principal’s otherwise cheerful demeanor suddenly darkened and after a quick and nervous glance at her watch she said that it was unfortunate that our meeting had to end so abruptly, but that she had to run to an important conference.

On the way home, my daughter who had been standing by me during the entire conversation with the principal asked me if, now that we’ve provided a scientific explanation for the formation of the bottle neck, the school would fix the problem. I thought about it for few minutes and said, "Probably not."  She asked “why?”, I said that unfortunately, sometimes in the short term, politics can trump scientific discovery. She was visibly disappointed and said that she worked so hard on this experiment and it all turned out to be a complete waste of our time. I told her that even though we didn’t win, we still conducted a great experiment and independently discovered and solved an interesting puzzle. And by way of analogy, I told her about the Galileo affair and how despite his mistreatment by the inquisition, in the end, his theories eventually won acceptance.

A few days after the science experiment, my wife, while waiting to pickup our daughter from school, struck up conversation with another parent who seemed to be somewhat annoyed. "Why the long face?" she asked. "Well," said our neighbor , "Just a few minutes ago while driving into the school parking lot, I was being polite and making extra room for the car approaching me, but I miscalculated the width of the opening and scraped the side of my van against the gate post." She had carved a deep gauge in right hand side of her van from wheel rim to wheel rim.

That evening during dinner, my wife recounted the story of the accident. My daughter at first thought that my wife was making the whole thing up, but after hearing that it was the mother of one of her classmates, she asked for permission to call her friend to verify the facts. When she got back to the dinner table, she had a look of disbelief on her face. “That’s exactly what we told the principle could happen!” she said. “We sure did,” I said.

She remained silent for few seconds and then I noticed a twinkle in her eyes.

© Copyright 2009 Yaacov Apelbaum All Rights Reserved.

The Überteam

Yaacov Apelbaum-The Team

A High Performance Team in Action

It’s tempting to view all development teams as homogeneous masses that operate with equivalent efficiency. When looking for ways to improve our team productivity, we tend to overlook the human factor in the equation and either embrace new management methodologies or focus on incrementally improving some existing processes (i.e. requirements management, bug tracking, etc.).

Certainly, there is always room for process optimization and by doing so, we can probably realize some additional efficiencies. But ultimately, these actions will translate to a relatively small enhancements to the team’s overall performance.

In order to realize an order of magnitude improvement, we need to focus on the cornerstone of the technology and development process, the “individual”. It has been shown in numerous studies (e.g. Steve McConnell’s Rapid Development) that different teams within the same organization can have significantly varying delivery efficiencies.

So how do we explain the formation of islands of excellence within the same organization? After all, don’t all teams within the company share the same HR resources, training, tools and culture?

The short answer is that operational excellence has a lot to do with management style, team structure, and makeup. Let me explain.

Building and managing strong development teams goes beyond the simple managing of developers to quarterly objectives and delivering functional products. What sets apart a high performance team from the garden variety team is that in addition to delivering acceptable products, the high performance team tends to exhibit more loyalty and less splintering. It works smarter, is more creative, is more cohesive and its members are more independent. A high performance team has certain qualities and a distinct spirit which emanates from the individuals in the team.

A high performance team’s esprit de corps is derived from a strong sense of individual belonging, common culture and shared vision. Building and managing this type of a team requires a clear definition of the team’s identity, documented history of success (and failure!), the cultivation of elitism (i.e. an aggressive selection process which makes team membership a coveted privilege), stoking the competitive fire (identifying the competition and targeting it), striving for being different than others and having a reputation for taking on and delivering difficult assignments. Above all, it should be a fun and intellectually rewarding environment.

Even though high performance teams are independent of project type and technology (they are certainly not limited to early stage startups), they all share certain characteristics. I call these the Seven Golden Habits, they are:

  1. Preach and Practice Honesty and Integrity – Always insist that all team dealings and communications (internal and external) be honest and open. The primary building block of all human relationships and the cornerstone of good leadership is integrity (both professional and personal), so you must show personal integrity (in moral decisions always follow the "Et si omnes ego non" principal) and instill its importance in your directs and their team members. You can always explain incompetence and overcome it. Not so with dishonesty and poor integrity.
  2. Promote Proficiency and High Technical, Operational and Personal Standards – Place strong emphasis on recruiting bright and talented individuals who are passionate about their work and are domain experts. Demand that each team member provides leadership in one or more areas. Work with each team member to develop customized training and professional growth plans and make sure that each has a clearly defined career path that goes beyond basic corporate training (plans for an advanced degree, leadership opportunities, professional certifications, etc.). Inspire them to continually learn so as to further excel. Organize training in emerging technologies, standards and best practices. Promote industry visibility for team members by encouraging them to present papers at conferences and to publish. Public visibility for individual members = visibility for you and the entire team.
  3. Emphasize Accountability and Responsibility – Carefully delegate responsibility and provide your directs and team members with ample opportunities for exposure and high visibility success. Never micro manage! At the same time, expect all assignments to be completed promptly and with a high level of quality. Do not tolerate procrastination and repeated failure to deliver projects on time, over budget or with inferior quality. Provide talented team members with frequent leadership opportunities. Generously give credit where it is due and swiftly sanction habitual underperformers.
  4. Promote Cultural Diversity, Sociability and Friendliness – Recruit heterogeneous individuals (promote cultural, racial and gender diversity). Consider the stimulating exchange of ideas between team members critical for team success as well as for your own personal growth as a manager. As such, encourage the establishment of forums and strategies to build strong collaborative teamwork, some of which may include: inner team mentoring and tutoring, brown bag technical luncheons and sponsorship of after work activities. Do not tolerate any abusive behavior within your team. Get to know each team member personally. Learn about their hobbies, their family and their personal concerns.
  5. Stop the Buck and Delegate – Serve as a single executive focal-point for your management and directs (handling both inbound and outbound escalations). Build, motivate and promote inner team leadership and a successful culture that is based on mutual benefits. Empower direct reports to contribute to the development strategy, while insuring that their action plans and implementations are based on the official strategic goals and well defined market opportunities.
  6. Develop a Competitive and Rewarding Workplace – Institute spot cash bonus programs and prizes (gift cards are a favorite), permit a certain amount of telecommuting when possible, subsidize technical books, on-line education, and hardware and software for personal use, place strong emphasis on social bonding (including after work hours activities and membership in online social networks).
  7. Deal with Ambiguity Effectively – Due to their intangible nature, ambiguity and uncertainty can have devastating effects on any development team. Ambiguity tends to increase with project size and complexity and can stem from many sources that may not be under your team’s control (i.e. budget, schedule, requirements, technology, strategy, etc,). You should expect ambiguity as a given and develop approaches to elevate and counter its effect on your team’s ability to shift gears quickly without having all the facts.

    Some of the coping techniques I have used to deal with ambiguity include:

  • Avoid "analysis paralysis" and “deadlocks” – Even though most of us subscribe to a structured, orderly and predictable management methodology, in the absence of more information, you should feel comfortable relying on your team’s advice as well as your personal experience and intuition to reach a decision without endlessly pondering all of the options.
  • Keep clear from the tried-and-true trap – Under conditions where the work threatened by various conditions of uncertainty, traditional solutions may not be feasible, you should push the team to innovate, think out the box, and take prudent risks to insure that business objectives are met.
  • Manage the effects of ambiguity on the team – Understanding the relationship between anxiety, impatience and uncertainty, you should work to develop an effective communication plan and control the effects of uncertainty on the team by: providing daily communication (meetings, e-mails, briefings, etc.), fighting rumors, requiring every team member to provide constructive suggestions, eliminating team splintering and factioning, speaking externally with a single voice, and avoiding finger pointing and blame.

These rules work well whether you are first forming a new team or transitioning forward a mature (and perhaps stubborn) one. Whatever the constellation of your corporate environment and culture is, these are tried and true methods that will yield significant improvements in operational efficiency and product quality.

Contrary to the old adage, you certainly can (and should!) teach an old pooch new tricks.

Good luck!

© Copyright 2008 Yaacov Apelbaum All Rights Reserved.