Your First 90 Days on the Job

Yaacov Apelbaum-First 90 Days

You just landed the technology executive job of your dreams, so what do you do next?  Do you concentrate on the dysfunctional engineering/architectural environment? Do you accelerate the delivery schedule on the flagship revenue platform? Do you tackle that daunting platform upgrade that everybody has been steering clear of for the past several years? Well, you should do none of those, and I’ll tell you why.

Your first ninety days on the job are critical to your long term success. This transition period is characterized by great uncertainty and the risk of deadlocks.  As many eventually discover, the inability to make significant headway during this initial period has little to do with technical intelligence or leadership skill. The common cause for the ninety day blues has to do with communication breakdowns, misaligned expectations, and the onset of a psychiatric condition known as the “Hero Syndrome”.

If you have just given notice and are about to take over new technical management responsibility, you may want to consider the following tips and tricks:

1) Committing to unrealistic deliverables and timelines
The number one trap on my list is to promise too much and commit to specific deliverables too early. Creating unrealistic expectations is one of the most common pitfalls for a new manager. It is all too human to endeavor to dazzle your boss and peers by establishing the reputation of a mover and shaker. Fight this urge until you get a good understanding of what it is exactly that you are about to move and shake.

One great example to illustrate this is the story taken from the Mahabharata  about king Santanu, who commits to a deadly relationship with Ganga without first understanding the repercussions of his decision. It cost him 7 of his 8 children.

2) Pretending you know it all
The second pitfall is believing that you have been there and done that. Regardless of your pedigree and illustrious career, no two projects are ever the same.  You must come to terms with the fact that you can’t possibly have all the answers. My favorite tactic for addressing this is to schedule a day long summit that is dedicated to one core problem.  During the summit, the stake holders present and openly discuss their concerns and views. Spend the time listening to all the domain experts. Don’t be shy, if you don’t understand the issues discussed, ask for a simplified explanation.  In all likelihood, when the fog eventually lifts, you will find that the problem is more complex than you had initially thought.

Another variation on the knowing-it-all syndrome is jumping to conclusions. Quickly embracing a substandard solution as a simple fix to a complex problem can alienate your organization. Team members who believe their leaders’ minds are made up about a problem are usually reluctant to share information or ideas, and this can further impede your ability to learn the true nature of the issue.

3) The good ol’ days and clinging to your old persona
Sometimes without even realizing it, you may discuss your former company or your past success too frequently. The psychology behind this behavior is to use past achievements (real or imaginary) to shore up an argument. This may work some of the time, but it is a double edged sword because doing it habitually can disenfranchise your new team and create the impression that your former company was so much better than your current one, at least in your mind. People may also wonder why—if you loved your old company so much—you didn’t marry it and stay there.

4) Suppressing bad news and dissent
Managers who quash disagreements, bad news, and dissent remove themselves from the real feedback loop and lose the ability to identify and correct problems. It’s easy to create a top to bottom environment that is based on fear. This, however, is guaranteed to drive your brightest team members out the door. The highways are full of smart employees who were given draconian decrees in the style of “it’s my way or the highway.” The only ones left in your company parking lot will likely be the mediocre talent who have difficulty driving to their next gig.

5) Chronic Hero Syndrome
Trying to go at it solo is romantic but foolish. If you operate as a lone wolf who insists on forging his/her own way and doing all the work yourself (design, coding, architecture, etc.), you will cut yourself off from valuable sources of domain expertise. Even if you are on the right track, you will eventually burn out or alienate your team.

6) Failing to identify the true sources of corporate power
One important quality you should work on is reading the unwritten laws of your organization.  Depending on the structure of your new company, (startup v. Fortune 500), you may find that real power and ability to effect change is held by the likes of senior architects, product managers, etc. and not your C-class peers.

7) Fighting the wrong battles
As a new leader, you instinctively want to focus on high visibility problem areas and figure out how to solve them. Nothing is more rewarding than to take a leading role in a gunfight at the O.K. Corral. That’s commendable, but not if it comes at the expense of sustaining small gains at GTB (growing the business) while suffering significant losses at RTB (running the business). There is a tendency in the beginning to think that it’s more important to be visible. Fighting too many of these battles can quickly become a huge  black hole that will suck every free moment of your day.

8) “Trashing” your predecessor
My golden rule is to always be respectful and sensitive about my predecessors on the job.  Consider the fact that most of the people you will work with knew the old manager and many are still in touch with him/her and are probably still on friendly terms. Learn as much as you can about your predecessor and the reason for his/her actions. Try to figure out what was done well and what went wrong. If at all possible, insist on getting access to old e-mails and work files. As I have discovered many times, this data can contain pure gold and is probably a good indication of the type of bus that is heading your way.

9) Attempting too much
Whether you like it or not, you are going to be judged on specific deliverables. If you concentrate your focus on too many activities, you may miss the opportunity to allocate a critical mass resources and time to complete high priority projects. To avoid this pitfall, work to prioritize your assignments. My rule is no more than three vital priorities for the first 90 days.

10) Hanging around with the wrong crowd
In life, hanging around with the wrong crowd can get you into trouble. The same thing applies to your new team. If you get inadequate or skewed information, or make all your decisions based on poor advice that comes only from a handful of individuals on your team, you may end up inadvertently politicizing trivial issues. Keep the lines of communication open outside of your organization in order to make sure that you balance inter-team influences.

11) Failing to build a cross-organizational coalition
It’s impossible to get anything done effectively in any size organization without critical mass of support. This is even more important for large corporate initiatives. For you, this means that you very quickly need to identify who the key decision makers are and what they care about, map the organization’s political networks to figure out who influences the influencers, and craft a plan to reach out to build strategic relationships.

Your Recipe for Success
Avoiding the above mentioned traps depends on how well you manage your first ninety days on the job. This means taking the time to evaluate situations, identifying team member strengths/weakness, accelerating learning, negotiating success, building coalitions, and achieving early victories.

Coming into a senior management position from the outside of the organization is tough. You don’t have a reputation to fall back on yet nor an internal Goombah to speak up for you. You must quickly learn about new products, market opportunities, and the mechanics of day-to-day operations – and all this in the context of an unfamiliar political culture.

Yaacov Apelbaum - Werewolf Killing KitTo execute your vision successfully, avoid using political clout and authority. Instead,  leverage your team members to get the job done. I use the “clip with 3 silver bullets” metaphor. You can use management directives 3 times, but each time you do, you spend one of your silver bullets. After your last management directive, you are effectively out of ammunition and it’s only a question of time before the werewolves will get you.

This means building a good relationship with team members from other business units who have their own agendas. It means creating supportive relationships with your manager and peers who have different styles and objectives. It means motivating a wide range of employees who probably feel threatened by you. So how do you put this hundred ton flywheel in motion and secure support? You do it by following these battle proven directives:

1) Manage your management team
What makes companies like Intel, Google, and Apple successful is their talented and high-performing employees. Creativity, product innovation, and development efficiency are largely based on good technology management practices.  Whether you are coming in as CTO to resuscitate a fallen giant, or as a VP of engineering in a startup to get their product to market, the primary lesson is that you can’t do it alone.  You need to build a dependable management team that should be able to survive the loss of any of its key members (including you) and still continue to function.  For you, that means working out individual secession plans and career paths.

Neff and Citrin, in their book, You’re in Charge-Now What? argue that the difference between short term success and great enduring success is how you practice leadership and shape your management team in the early days, and then motivate and develop them over a longer period of time.

2) Develop and articulate your strategic plan
In the fog of battle, it may seem as if there is no time to think, but that’s not the case. Take your time and work out your plans. As a new executive, you are not expected to produce a fully functional strategic plan in the first ninety days. You should instead try to strike a balance between developing a comprehensive map of where you want to take the organization without immediately becoming prematurely bound to it.

The first ninety days are your honeymoon period and as a new manager, you are allowed to walk a fine line. You must develop credibility through action but at the same time,  if you act too quickly before gaining a complete understanding of the situation, you may risk making the wrong choices.

3) Communicate
Communication is probably the most important aspect of good leadership. Effective communication has a disproportionate effect on your success during the early period.

Don’t miss the opportunity to communicate daily and to communicate well.  Listen carefully during meetings, take careful notes (write down and learn every acronym), follow-up on conversations to get in-depth explanations for issues that you didn’t grasp initially, be punctual showing up to meetings and returning e-mails and phone calls, and provide constructive non-polemic feedback.

4) Transform the culture, but do it slowly…
Every organization has a different ecosystem and operational nuances. Before you start transforming the organization, learn about the culture of the company and identify its bureaucratic and operational bottlenecks. It is critical to first learn “how they do things around here” and to identify the knowledge network, secret handshakes, chief influencers, decision-protocols, and unwritten conventions that form the nervous system of your new organization.

A few good areas for investigation are procurement, recruitment, release management, and quality tracking. My two personal favorites are to go through the actual steps of composing and submitting a request for a piece of software or hardware and a new headcount justification request. You will be amazed how much you can learn about the company by completing these two tasks. Once you get your finger on the pulse, you can begin to intelligently effect change and take the right transformational steps. This would include: instituting new operating procedures, choosing a new management team, setting up governance boards, identifying change leaders, and leading by example.

Finally, change is unavoidable, but it is important to remember that rapid and excessive change can destroy the work culture and the change agent (i.e., you). So, instead of adapting a deeply disruptive strategy such as reinventing everything or replacing key people, try the following long terms initiatives:

  • Set up pilot and POC projects
  • Change the way performance is measured and tracked (digital dashboards)
  • Educate and train your team (gain expertise in your entire technology stack)
  • Build up islands of excellence (tiger team, high performance SCRUM teams, etc.)
  • Document how the technology organization operates (process and roadmaps)
  • Collectively envision new ways to operate (what to sunset, upgrade, etc.)

5) Get to know your boss, your greatest ally
A key success factor in your new job is to establish a productive working relationship with your new boss. It is important that you spend some time together on daily basis. This includes keeping him/her informed of your thoughts and actions, discussing proposed changes, and updating him/her on your deliverables.

It is also imperative that you quickly size up your boss, including high priority goals, pain points, strengths, weaknesses, blind spots, and preferred work style.

Remember, your boss is your greatest ally, because he/she can link you to all the right individuals in the rest of the organization, help you set priorities, and secure the resources you need to get your job done.  All of this is free and comes without you having to spend any political capital at all.

For a more detailed treatment on how to max the first 90 days on the job, check out: The First 90 Days: Critical Success Strategies for New Leaders at All Levels by Michael Watkins


© Copyright 2011 Yaacov Apelbaum All Rights Reserved.

Ode to The Code Monkey

 Yaacov Apelbaum-Code Monkey  
The Code Monkey (inspired by A Dream Within A Dream by Edgar Allan Poe)

Take another slap upon the cheek,
While slaving on this project, week by week. 
You have been wrong to work so hard,
Expecting riches and managerial regard.
Grinding out functions awake and in a dream,
Will not fetch rewards or professional esteem.

What you lack are not more lines of code, 
Rather it’s architecture and a road.
To substitute quality with speed,
Is the motto of the code monkey creed. 
You who seek salvation in RAD extreme
Will find, alas, a dream within a dream.

If you examine your latest stable build,
You will notice many bugs that haven’t been killed.
Strangely, they seem to grow in relation,
To your oversized code base inflation.
So many new features! How did they creep? 
Through scope expansion, they trickle deep.

Building good software is hard to manifest,
If you fail the requirements to first digest.
The lesson to learn from this development ditty,
Is that no matter how clever you are or witty,
If you fudge the schedule and estimation phase,
There is but one reward for you. The death march malaise!

© Copyright 2010 Yaacov Apelbaum All Rights Reserved.

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:

  • 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.
  • 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.
  • 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.

Crafting Great Software Features Part-1

Yaacov Apelbaum-Useless Technology  
Driver’s Entertainment System and Password Protected Gear Shifter

Trying to do anything well is difficult. Developing useful features is no different. It takes more effort to create useful functionality than to produce eye candy.

Good feature design comes from a reliable and repeatable process (not dissimilar from CMM). Unfortunately, many organizations still have not figured this out and instead of investing in usability engineering, they slug it out in isolation and tragically, like Sisyphus, doom themselves to getting the wrong functionality and spend eternity (or until the project is canceled or runs out of money) patching their mistakes, version after version.

If your goal is to build a useful product, you should schedule your project so you can develop the needed functionality. Habitually excusing yourself by claiming that you “just don’t have the time” to develop quality is a cop-out. If you find that your team is spending a significant amount of time on feature seesaws (taking them out-putting them back), it means that you’re not planning well, and that the technical goals are not aligned with the product objectives.

Feature Framework
In a functional development organization, everyone should fully understands how their individual contributions will impact the end user. To help achieve this, there should be a feature framework in place.  The feature framework  must cross organizational lines and bridge development, PM, product planning, sales, and marketing.  The chief purpose of the framework is to determine what challenges end-users have and how a proposed feature, functionality, or technology will solve those problems. Without utilizing some degree of Feature Driven Development, you stand the risk of creating features that may look great (like password protected gear shifter) but solve no real problems.

Management Knows Best, Well, not Always…
In order for you to master the product usability question, you have to conduct real life tests with real would-be users. Talk to your customers about their pain points and ask them what they love (and hate) about your product.  The earlier you get the bad news, the better you’ll be in the long run.

Keep in mind that most failures in software usability can be attributed to poor decisions at the executive level, which are promulgated due to a culture of silence. Developers and designers should be encouraged to think critically about their work and be provided with official channels for expressing their opinions (in a non polemic manner).

Make sure they talk to the the other members of your team to broaden their horizons.  Invite their participation in every feature conversation. When considering new or revolutionary UI changes, solicit input from your customers and your organization.  Without sufficient end-user, business justification, and sales input, its easy to develop functionality that universally disliked (like the notorious Microsoft Clippy feature).

One of the most common development failures (after underestimating feature complexity and the cost and time to develop it) is the inability to correctly define the problem space and instead to develop solutions that are looking for a problem.  If the project objective is vague and not granular enough, it’s impossible to know whether it has been solved or not. Furthermore, even if the objective is well defined, you may still be working with the wrong assumptions about what the customer really needs.

A video screen built into a steering wheel that plays looped safety movies won’t help your user drive any safer. These two types of problems—vague objectives and the wrong assumptions—have nothing to do with your team’s technical ability. If you can’t side step these kinds of issues, even the best software engineers and designers are bound to fail. You may write great functionality and create whooping UI, but if you can’t solve the right user problem, all of your hard work will be wasted.

Do you have a Problem with That?
The first step towards critical feature analysis is to take an objective view on the nature of the problem. As a developer, you are inherently biased towards the value of your features and suffer from a certain degree myopathy. You’re inside the tech bubble looking out and so you cannot possibly see your creations the way your users do.

Yaacov Apelbaum-Team Structure To improve visibility, you need to supplement your view with external sources. These should include: UI team, technical developers, product business champion, actual customers, sales, training, and marketing.  Get as many alternative views as you can. Again, make sure to talk directly with the users effected by the design, Don’t take single  camp’s word for what the problems are. Think of yourself as a newly elected congressman trying to keep your constituents happy. Don’t only consider the opinions of the power lobbyists.

Another challenge is that the way approach your customers for feedback will impact the type of information you get from them. If you unintentionally bias your questions, you’ll get skewed data. The art of observing and understanding customers needs is an acquired skill and it may take several trial runs before it’s honed.

When researching the problem, keep the following key questions in mind:

  1. Who are your user’s, what are their skills and job functions?
  2. What is your user’s workflow and how does your product enhance it?
  3. Do your users use other products to supplement your app?
  4. What business assumptions are you making about your users and their environment?
  5. What are your user’s specific deliverables (spreadsheets, reports, presentations, etc.)?
  6. How do your competitors solve the same problems you are working on?
  7. What is your user’s strategic information roadmap and how does your app fit into it?

If you don’t have complete responses to these questions, you cannot start to design or develop any features or functionality. a solid understanding of your customers and the answers to these questions form the foundation of your application.

You Only Get One Chance, So Chose Wisely
As you are preparing to work on your next version, you will discover that there is an infinite number of issues that need solutions and a mile long list of most have features. But just having a raw list of bugs and features isn’t enough to build a product.  As it goes in life, some problems are not worth solving once you consider their poor return on investment and time.

Often, a solution to one problem spawns multiple new problems (and bugs). You need to exercise good judgment, which means having the ability to distinguish what should be done from what can be done. After collecting the business requirements, the next step is the development roadmap. You have to synthesize the requirements and create a specific action plan for where to invest your time and resources.

With the data collected from customers and internal sources, distill the information into short one-sentence lists. These sentences should be written from the point of view of your end-user. For example, “Enable password field to accept 11 characters” is not a problem statement. But “Password field must support strong passwords” is. The difference is significant. You rarely want to define the solution and the problem in the same statement: If you do, you’ll miss the real problem.

In this example, there may be many other ways to solve the problem of password strength, including hard coding the logic to accept 11 characters. But if you are too focused, you’ll never see the alternatives (make the password length database driven, integrate it with LDAP, biometrics, etc.). Good feature development is all about understanding your alternatives.

Yaacov Apelbaum-problem to a solution

A solution looking for a problem

For each problem statement, provide supporting information. Include details about which users have the problem, how it was discovered, and what the potential workarounds are. Determine whether the problem only occurs in certain configurations. Following Feynman’s rule of scientific integrity, provide as much details as you can to allow others to confirm or challenge your assumptions.

If you’re the owner of the usability study or market research data make it available to everyone.  Don’t ask anyone to “trust you”. The more open you are about your feature sources, the less likely it is that people will suspect you.

Hold your Fire
Only start coding when you see “the whites of their eyes”.  When the goals are set and the problems to be solved have been well defined and understood, you can begin to build the features. Instead of adopting a top to bottom approach (where the development team is told what to do), engineers and UI designers should have free rein to generate the ideas that will solve the problems. Time should be allocated to investigate different alternatives that might provide the necessary functionality, and to run usability studies on prototypes to see if they actually improve the end-user experience. Only once you evaluate all your potential solutions and pick the best one can you engage in full speed development. The rest of your solutions do not have to be disregarded; you can shelve them for future releases.

As long as you are working within a feature framework, you are guaranteed to be marching in the right product direction. There should be a lot of innovative and creative juices flowing in your team, and even if you can’t completely solve all of your feature functionality challenges, a partial solution to the most important problem will still be superior to a perfect solution to the wrong problem.


© Copyright 2010 Yaacov Apelbaum All Rights Reserved.

Developers Just Wanna Have Fun

 Yaacov Apelbaum-The Cinawaffle
The Cinawaffle DX250 Waffle Maker\DVD\MP3 Player is Remote Controlled and Bluetooth Enabled.  It Comes Standard with an SDK and a Built-in Web Server.

One of the greatest fallacies in software development circles is that great products must be made with cutting edge technologies.

This belief is not coincidental, as most of the people who work in high tech maintain a passionate love affair with technology. If you ask most of us about our willingness to work long hours on risky and challenging projects, the answer is likely to sound something like: “I love technology, it’s fun,” or “I enjoy playing with technology; I can’t believe that someone is actually willing to pay me to do this job.”

Hardcore techies aren’t the only ones who are enamored, It seems that since the ushering in of the industrial revolution, we all have come to embrace the utopian belief that technology will one day solve all of humanity’s problems.

Believing this, many seasoned business and development managers fall into a trap and tend to package unnecessary technology into their applications. Unfortunately, this is most often done to the detriment of the product and its users who fail to leverage or appreciate the complexity it brings.

I have witnessed numerous product launches where the entire company stood in awe at the sight of their own technical achievements.  Managers and developers alike were congratulating each other on overcoming what early on seemed to be impossible development roadblocks. All without any regards for the sketchy implementation and clear sight of the purpose that such functionality might serve.

Yaacov Apelbaum-Neo LudditeYaacov Apelbaum-Luddite Reward At the risk of sounding like a Neo luddite, I would argue that our infatuation with technology doesn’t always lead us to develop the products our customers need.

When you were interviewing for your last gig, you likely stated that the ability to work with new technology and learn new tricks was a significant factor in your decision to apply for the position. You may have also been told by your interviewer that his company prides itself on maintaining a fun work environment and that you would get the opportunity to work on some very cool and cutting edge projects.

I believe that personal and company success hinges on establishing a creative, unpretentious, and challenging work environment.  But that’s not the whole recipe for success.  Any organization that hires expensive technical staff cannot afford to do it for fun’s sake only.  A company can only sustain a playful atmosphere if an increasing number of paying customers embrace and consider its product useful.

The reason for this is simple. Contrary to the common misconception, it’s not angel funding, seed money, or bridge loans that pay for your operation. Rather, your end users end up picking up the tab for all of your company’s salaries as well as for the espresso machine, the new Wii\Xbox station, and the billiards table. In light of this, every activity you engage in (e.g. design, coding, or testing) must directly benefit your costumers and end user.

How granular are the effects of product usability on your daily work?  Each line of code you write, every bug you find, every new feature you consider must help the user improve his productivity in some quantifiable way. No matter how obscure or indirect your current project is, streamlining the user interface, improving application stability, or optimizing performance, all must directly benefit your customer. If you can’t clearly see how your work improves the user experience, consider investing your time on some other activity. The more frequently you think about your work in terms of end-user productivity, the more impact you will have on creating a profitable product.

The Beauty of Simplicity
The greatest engineering feats are the ones we don’t notice. The hallmark of a great designer is his ability to translate complexity into simplicity. The automatic transmission in a car represents significantly more engineering effort than a manual transmission, but it dramatically transforms the average user experience. The best engineering, architectural, and consumer products always focus on improving user experience and hiding complexity, not showcasing it.

The most effective approach to adding value to products is to add power and ease of use while reducing the learning curve. When you are developing a new feature, ask yourself, is there some way to add it without changing the user interface? (users hate learning new interfaces)  Can we solve a problem by re-designing workflow or consolidating instead of adding more screens and menus?  Or is there some other feature we can modify to include new and improved functionality? Think of car manufactures and how they add major new features with minimal user impact. The dashboard almost never changes, rear anti-collision video monitoring is integrated into the GPS display, anti-lock brakes are added to the standard brake pedal UI, and power steering is added to the steering wheel UI. Minimal training is required on the part of the user to reap the benefits of these new features. This kind of design approach—where complex functionality appears simple to the user—helps create great products.

There are countless opportunities throughout your application to provide a great user experience. Watch your customers usage of your top features and ask yourself how they compares to the level of service you’d get in a 5 star establishment. Is the product fast, intuitive and easy to use? Is efficient help always available promptly? Is it easy to get information out of it? And most importantly, does your product enhance the user’s productivity and business process flow?

Regardless of the technology you adopt, the closer your application’s usability matches the levels of service people get in their daily physical experiences, the closer you’ll be to having a great and useful product.


© Copyright 2010 Yaacov Apelbaum All Rights Reserved.

Drinking on the Job and Other Vices

Yaacov Apelbaum-Drinking on the job

Working in an early stage startup can be a blast. For me, it is a most rewarding personal and professional experience. There is minimal bureaucracy to get in the way and you have the opportunity to build the product of your dreams.

True, at times a few dark clouds (like the possibility of not making payroll) may gather on the horizon, but with some ingenuity you can handle it. If you are preparing to ship version 1 of your product, the pre-launch phase or the final sprint can be an ultimate adrenaline\caffeine rush, and the chronic lack of sleep will just enhance the experience.

Working in this environment may not be for everyone. The rapid pace of change, the seemingly never ending To-Do list, and the constant improvisational nature of the work often frustrate individuals who are used to more structured development. Financial stability can be another turn-off. Most early stage startups operate on a shoe string budget using seed\angel money that has to be stretched to the limit in order to build a viable proof of concept. Once in place, the funding and development cycles are repeated in the hopes of surviving long enough to attain commercial viability. These repeating cycles, if not executed properly, can become a tiresome soap opera.

To use an equestrian metaphor to illustrate the development effort in a large organization is somewhat similar to English-style show jumping competitions. A smartly dressed rider moves elegantly between the stations (projects), always maintaining aristocratic poise and composure (an eye on features, schedule, and budget). The same event in a startup looks more like a rodeo, where the inexperienced rider jumps on the back of a wild mustang with neither saddle nor reins and spends the duration of the ride screaming, swearing, and holding on for dear life (dwindling budget and product immaturity) while the horse (the competition) simultaneously kicks, bites and tries to throw him off. Net-net, a tour of duty in a startup can resemble the life of a Caribbean buccaneer. The risks are plentiful but the rewards of a buyout or an IPO can be glorious.

In addition to operational differences, startups also tend to have a more casual and festive corporate culture. To help recruit and retain talent it is not uncommon to offer employees various soft perks like no dress code, the freedom to play interior decorator, and access to amenities such as the latest video games, quality coffee, soft drinks, snacks, and other tech toys.  Some companies, in an attempt to even further sweeten the sub-par monetary compensation will go as far as to abstain from creating work policies regarding vacation, work hours, and employee conduct.

If you are on the management team of a startup, it is tempting to convince yourself that you can make up for low base pay and a high stress work environment with theme park playfulness (a approach not dissimilar from paying for prime real estate with firewater and glass beads). But in reality, trying to convince highly intelligent people that the privilege of working in a glorified techno-utopian commune is an adequate substitute for decent wages amounts to little more than Svengali’s operatic hypnotism, it may work for a while, but sooner than later the effects wear off, leaving you with consequences like high attrition rates and chronically missed deadlines.

Firewater and Glass Beads

In one of my engagements, I had the opportunity to work with a late stage startup. The company desperately needed to mature and commercialize its product and swing to profitability. This had to be done rapidly in order to secure bridge funding.  When I first took over the technology and engineering organization, I discovered that the team had an almost 50% turnover rate and that my two predecessors had left on very disagreeable terms. Initially, I was surprised that the subject of almost every staff meeting revolved around compensation, but that matter quickly came into focus. The developers were disgruntled because, in addition to being significantly underpaid, they hadn’t received their promised bonuses (which accounted for almost 40% of their salary) yet they were still being asked to work 70 hour weeks. It was evident that all the soft perks they were getting didn’t succeed in dulling their memory of the promise.

In another engagements, the CEO refused to budge on the question of base salary and missed bonuses and argued instead that work conditions (flex hours, free sporting event passes, telecommuting, and free alcohol) were more than sufficient  compensation. On the eve of the “Mother-of-all-Sprints,” (a hellish 320 hour coding month), some team members started exhibiting disturbing behavior that included sending inflammatory emails to the entire company (see excerpt below), rowdy conduct in staff meetings, and calling in sick.


As part of the “Mother of all Sprints”, we have been asked to go above and beyond our normal dedication. We have been asked to make major sacrifices in our personal schedules. We have been asked to work harder with longer hours. We have been asked to cancel existing plans we may have put in place with our families. We have effectively been asked to put our lives on hold until the end of the sprint. And we have been asked to do this without any advance warning. Furthermore, many of us disagree with the exact product direction.

  • We disagree on the functionality necessary for the company to go forward.
  • We disagree on what the bottlenecks and limits with the current process are.
  • We disagree on the feature focus of current efforts.
  • We disagree with the release date.
  • No one asked the development team what they felt was important to accomplish.
  • No one asked the development team what features they felt were necessary.
  • No one asked the development team what they they could realistically accomplish.
  • No one asked the development team when the release should occur.
  • We have no real equity in the company. We have no guarantee we will ever receive bonus payments. We have no guarantee that bonuses will be distributed fairly, if they are ever paid out.

So I have to ask myself, what is my personal motivation for doing this? What do I get out of it?

Of course, it didn’t help that the company offered its employees a steady supply of beer and hard liquor, and even had gone as far as openly encouraging everyone to drink on the job (at the ever so popular “Tequila Fridays”). HR wouldn’t implement any conduct policies because they feared that doing so would dilute the startup experience. Not surprisingly, some employees in turn responded by drinking just a bit to much and staying home sick.

Workspace structure and policies are as mandatory as social contracts and are designed to protect us from abuse and anarchy. Hobbes observed that life under the rule of the mob is “nasty, brutish, and short.” Similarly, life in a startup modeling its governance to resemble the “Lord of the Flies” is wretched and hardly short enough.

Unfortunately, no one has the exact formula for balancing discipline with productivity. But I have found the following rules of thumb to be an affective guide:

It may be contrary to your anti-establishment philosophy, but it is in your best interest to create and maintain an orderly work place. Unfortunately, the only way to achieve this is by formalizing rules for all employees and enforcing policies like performance reviews, bonus payments, vacation and sick time without favoritism or exceptions. 

Here are my six golden rules for keeping anarchy at bay:

  1. Provide formal policies regarding company usage of licensed software. It may be true that software yearns to be free, but unless it is properly licensed it should be kept off of company computers. This may sound picayune, but using counterfeit or cracked software is a huge legal issue.
  2. Regardless of how hip and progressive it may seem, do not encourage consumption of alcoholic beverages or drugs on company premises. Every garden has its snake and this one will bite you big time. It’s only a question of time before one of your employees under the influence of something he consumed at work will become a legal liability.
  3. Do not tolerate violent or abusive behavior (such as regular use of foul language or extensive absenteeism) from any employee, including leads and management.
  4. Offer your team competitive financial compensation. If you can’t afford to pay market wages, be honest and upfront about your limitations. Don’t try to renegotiate salaries down by arguing that industry wages are inflated.
  5. Be creative about company spirit and culture. Offer your team as many soft perks as you can, but remember, perks are not a substitute for wages.
  6. Don’t exaggerate or misrepresent bonus target amounts, stock option availability, or plans for employee profit sharing. Be forthcoming about the financial state of the company and its stability. My rule is “promise only what you can deliver” and in a timely manner “deliver what you’ve promised.”

Maintaining transparency and a fair work environment are two of the most important pre-requisites for a smoothly operating startup. Once these are in place, you will discover that you are well underway towards achieving your most ambitious development goals as well.

Good luck.

© Copyright 2010 Yaacov Apelbaum All Rights Reserved.

It’s Good Enough for Me

Yaacov Apelbaum-Giacamo the Good

I commute frequently, so I tend to have some down time at the airport while sitting at the gate and waiting for my ship to come in. I usually use this window to catch up on my technical reading, but recently I decided to take a break and venture in to one of the book stores in the concourse. After skimming the offerings, I discovered a bookshelf filled with titles of the “How I Became the Best In ___, and How You Too Can By Simply Following My Easy Three-Step Program” genre. These books, mind you, are not cheep paper backs. I was looking at thick hardbacks, generously illustrated and accordingly priced. Apparently, the “How to Become the Best” series industry is booming.

This got me thinking: statistically speaking, the best of any kind takes up only a tiny outlier of the bell curve. So why the hype? Clearly, if this industry is thriving there are enough literate people out there who were willing to buy into the idea that being the “best” is worth their time and money.

Then a few weeks ago, I found myself confronted with this concept again. I was having lunch with a colleague and he raised the argument that the only way to win in today’s lean software economy is to develop the “best” features and functionality. He expressed his strong conviction by recounting his recent experience at a trendy “how to become the best” seminar. “I am a new man,” he said, “This event has changed my entire outlook on product development”. “How’s that?” I asked, curious. He leaned forward, squinted, and in a lower and somewhat more mysterious voice, he summarized his newly acquired philosophy. He said that according to the presenters, Trump, Robbins, and Kiyosaki, success hinges on one’s ability to tap into one’s inner best. Either you’re Napoleon or you’re out of the game.

At this point, I was done with my burrito and so I seized the opportunity to respond in kind with a rival French maxim. I quoted Voltaire: “Le mieux est l’ennemi du bien” (The Best is the Enemy of the Good). Wellington, I pointed out, was by no means the best, but he certainly outlasted Napoleon in the game.

My companion was startled and said he didn’t understand what I meant. I offered an explanation: “It’s not that I am a proponent of mediocrity; to the contrary,” I said, “I pride myself on my attention to quality. I have absolutely no problem with the concept of pursuing excellence. What prevents me from realizing perfection are mundane details such as looming deadlines, shrinking budgets, and a chronic shortage of resources.”

Of course it’s easy to invoke demagoguery and claim that it’s either “best” or “bust”. Many development managers adapt this mistaken philosophy, assuming that it has a positive motivational value. The average corporate culture doesn’t help dispel this myth either, by creating unattainable criteria for personal performance and compensation plans. Regardless of how fond of the cliché’ you may be, unfortunately preaching the best when it comes to delivering software under time, quality, and budgetary constraints is one thing, actually being able to deliver on such promises is quite another. If we learn anything from human endeavors, it is that “good enough” is more than acceptable. As far as I know, most of us don’t drive the best car on the market, live in the best built house, or exclusively buy the best clothes or appliances. Compromise is the order of the day.

My favorite story that illustrates this concept is the World War II race to develop the radar. Both British and German teams were aware of the tremendous operational and strategic advantage this new technology could offer. The German development team had the more advanced science and superior technology. Their radar was more accurate, had a longer range, and provided fewer false-positives. The German team—true to their cultural heritage—was striving to develop the best apparatus possible. The British team was smaller, less experienced, and had inferior technology. But from the outset, it adopted the motto: “Second Best Tomorrow”. This philosophy eventually allowed them to release an inferior but working radar earlier than the Germans thus winning the race and ultimately tipping the balance of power.

Cheap (often free) and simple software free of stringent SLAs is popping up everywhere. Most of us now get our breaking news from Google and personal blogs, case in point. We make free, long-distance calls on Skype (and don’t mind the low QoS), watch video on tiny iPods screens rather than high definition TVs, and more and more of us are using low-power cell phones that are just good enough to meet our surfing and emailing needs. For many leading companies, the distinction between good enough “beta” versions and commercially “best” products has blurred beyond recognition. (Gmail has finally come out of beta after more than 5 years.)

To be successful in commercial software development, one must fight the urge to gold plate by adding late stage functionality. One must also learn how to be firm regarding ad nauseum pressure for application re-writes, all in the name of making it the best.

Contrary to what the motivational posters profess, when it comes to shipping on-time, the pursuit of perfection can become your worst enemy. The same also applies to excessive QA and testing. In the end, even the most comprehensive white, gray or black box tests can only provide a projection of how your application will perform. The ultimate usefulness gauge are the real users. The earlier you release your product into the wild, the faster you’ll discover if it adequately fills a need.

As I have discovered on many occasions, building a good enough product and releasing it early enough is good enough for most customers—which is good enough for me.

© Copyright 2009 Yaacov Apelbaum All Rights Reserved.

Political Science 101

Traffic Bottleneck Poster

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, 60-minute flight to capture the entire bottleneck sequence which would be prohibitive.

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

Aerial Traffic Observation System (ATOS)
Image 1: ATOS (Airborne Traffic Observation System)

Flight and Imaging Specifications

  1. 4′ Chloroprene weather balloon with 1.7 lbs. of lifting capacity
  2. Riveted aluminum base cradle
  3. Flight control and stabilization via 2 tethers
  4. Canon FS100 Flash Memory (16 GB) camcorder with image stabilization
  5. 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.

Gate Traffic Set

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 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 an 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, our 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 science. She was visibly disappointed and said that she worked so hard on this project 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 visibly upset. “Why the long face?” she asked. “Well,” said our neighbor, “while driving into the school parking lot, I was being polite and made 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 Vatican Loves Me, it Loves Me Not

Yaacov Apelbaum-GalileoVsVatican

A few years ago, I read a series of articles about the Vatican’s plan to reconcile the Galileo affair.  The decision to reach this important milestone was by no means a hasty one; it was concluded after the Pontifical Academy of Sciences (the church’s leading scientific minds) deliberated every aspect of the case for almost 13 years.  To the average person, pondering a question for 13 years may seem a bit excessive, but when dealing with a 400 year old grudge, you can’t hurry love, you just have to wait. Net-net, I was delighted to witness the curtain descending on this, the final act of one of the saddest episodes in the history of science.

In a follow-up article I read that the Vatican was even prepared to go one step further. In a gesture that could only be described as brotherly love, they were planning to immortalize the father of modern science by erecting his statue near the apartment where, in 1633, he was incarcerated while awaiting his inquisition trial. This was getting better and better.

Yaacov Apelbaum-Swiss Gaurd

So, on a recent trip to Rome I decided to seize the opportunity and drop by the Vatican to pay my homage to Mr. Galilei. Not being familiar with the neighborhood, I consulted one of the Swiss Guards for guidance. The soldier, in a somewhat disinterested voice, informed me that there was no statue of Galileo in the Vatican.  Here, I thought to myself, was an opportunity to one-up the Swiss mercenary guard. “Haven’t you heard about the Pontifical Academy of Sciences and the decision to erect the statue?” “Oohh, that?” he replied, “that project was canceled“. 

I have to admit that at first I suspected my guard friend was out of the loop, but after performing a quick internet search on my phone I confirmed that indeed, the Holy See had decided that the funds originally allocated to the project were re-appropriated instead to an African educational program aimed at teaching about the interdependency of science and religion. Clearly the hand that gives can easily take away; but why? Why would the Vatican go through all the trouble of 13 years of meetings, making news announcements, and publicly committing to erect a statue no less just to renege at the last moment? 

Last week, as I was rummaging through some magazines I fell upon an article written by Father Jose Funes, the Jesuit director of the Vatican Observatory. In the article, Father Funes theorized that if aliens existed, they were absolved from redemption because, contrary to us sinful humans, they were already in “full friendship with the creator”.  After rubbing my eyes and rereading the article a few more times, (it read like something Father Ghido Saraduci might have written), the answer to the whole Galileo affair finally came into focus.

The explanation for the church’s apparent Dr. Jekyll and Mr. Hyde personality disorder had nothing to do with Galileo being right or wrong or the validity of any specific theory. At the core of the issue were the Pandora box that Galileo unlocked and the resulting devastation the scientific reasoning unleashed on the church’s authority. Where before the scientific revolution, natural disasters, war, disease, and poverty could easily be explained as by-products of sin and demonic forces, now these explanations were no longer believable.

The statement that theology and science share a common interest in questions such as the origin of the universe could be true, but there ends the commonality.  Legitimate scientific discoveries are driven by strong individual curiosity and doubt. The church’s scientheological research is driven by orchestrated attempts to harmonize dogma.  Where true scientific research is concerned with tangible results and the generation of derivative value such as useful technology, the Vatican’s scientific examination produces explanations to questionable theological concepts such as the redemption of aliens.

For a scientific theory to flourish, everything must be open to examination; the observer must constantly reevaluate the universe and construct models that better fit his observations.  This almost cannibalistic process results in the wholesale destruction of old theories (most serious scientists no longer advocate explanations that are based on theories such as the aether or the four elements). But for the church, this constant construction and deconstruction of ideas makes it impossible to maintain a consistent position on any subject.  Being fully aware of the pending doom, they fought tooth and nail to preserve the status quo by enforcing models like the Ptolemaic system.

From the historical prospective, it is interesting to note that Galileo’s scientific revolution coincided with several critical events in the 30 year war. The Vatican quickly realized that the opening floodgates of scientific reasoning coupled with significant changes in the European political map would pose major threats to its hegemony—a fear which within 50 years (starting with the treaty of Westphalia) became a reality upon the birth of the sovereign nation-state and the rise of the secular society where science and free speech would thrive. Not having an effective antidote, the Vatican concluded that the Counter-Reformation did not work and the only cure to halting the pandemic spread of scientific thought was the re-mobilization of the Inquisition, the Jesuits, and a new edition of the Index of Forbidden Books containing writing by such troublemakers as Giordano Bruno and Johannes Kepler.

Having a monopoly on truth and its interpretation goes a long way towards building one of the best selling product brands in history. Being the oldest, largest, and most successful multinational corporation made the church perfectly adept at playing the public relations game and mastering of the art of simultaneously speaking from both sides of its mouth. Now, I know, some would argue that this is a cynical simplification of the church’s attitude toward science and that the Holy See would never utilize such tactics.  If you are one of the skeptics, I invite you to read the following completely contradictory papal statements regarding Galileo:

Loves Me
Pope Pius XII, in his speech to the Pontifical Academy of Sciences, described Galileo as being among the “most audacious heroes of research … not afraid of the stumbling blocks and the risks on the way, nor fearful of the funereal monuments”.

Pope John Paul II admitted the Church had made a “tragic mistake” in rejecting Galileo’s views and offered Galileo a sincere apology.

Loves Me Not
Joseph Ratzinger, (at the time still yet to become Pope Benedict XVI), described the Galileo affair as “a symptomatic case that permits us to see how deep the self-doubt of the modern age of science and technology goes today.” He then quoted Paul Feyerabend, saying “The Church at the time of Galileo kept much more closely to reason than did Galileo himself, and she took into consideration the ethical and social consequences of Galileo’s teaching too. Her verdict against Galileo was rational and just and the revision of this verdict can be justified only on the grounds of what is politically opportune.”  Cardinal Ratzinger further commented about Galileo’s trial and concluded that it was “fair and reasonable”.

I encourage you to reconcile these statements. If you do, please drop me a line and I will do my part to ensure that in the future, your statue too gets erected in the Vatican.  Where specifically, you ask? Why, right next Galileo’s.


© Copyright 2009 Yaacov Apelbaum All Rights Reserved

The Death March

Yaacov Apelbaum-TheDeathMarch

Most software professionals view themselves as the masters of their own destiny, analytical and calculated, wisely exercising free choice in all matters of importance.

This was certainly my mental image of myself as well until several years ago, when I gradually came to realize that given enough time on the job, even the most experienced development manger will eventually have to venture into that dark and irrational world of the death march project.

For those unfamiliar with the term, a death march is not a walk through Ezekiel’s valley of dry bones. Rather, it is a reference to a development project where requirements either exceed the realistic deliverables by at least 50 percent or where critical resources are cut in half without adjusting functionally and schedule delivery accordingly.

Contrary to the common misconception, death march projects are not limited to only naïve and over ambitious startups. To the contrary, they are quite common in large and mature organizations that should know better yet for some poorly understood reason continue to practice every form of anti pattern known to man. How do I know this? Well to confess my sins, over the years I’ve participated in several of these projects.

Perhaps you are wondering why any rational person would choose to participate in or initiate a project that from its onset is clearly doomed to fail. The answer has to do with the adaptive strategies we use in order to survive in highly competitive and schedule driven corporate environments.

When performing a post mortem, most death march software projects typically exhibit the same pathology. The prominent finding is that the team has worked twice as hard and/or twice as long as would be expected in a “normal” project. So for example, if a normal work week is 45 hours, then a death march project team works 15-hour days, six days a week for a 80 hour week. Of course, thanks to a steady diet of caffeine and management coercion, the pressure within the team eventually escalates beyond control and leads to project meltdown.

The psychological drivers behind the willingness of individuals to join what is clearly a long and drawn out sadomasochistic exercise stems from the strong disdain that many of us have for organizational politics and our refusal to take any part in it. Unfortunately, by not participating in the political horse trading, we sacrifice our ability to effectively influence these irrational projects and leave all the decisions to corporate politicians who have little stake in the actual development effort.

Scott Adams, commented on this form of irrational behavior:

“Nothing defines humans better than their willingness to do irrational things in the pursuit of phenomenally unlikely payoffs. This is the principle behind lotteries and dating…”

Having reached this realization myself, I eventually started wondering if there were any early signs or warnings that could help identify an imminent death march. After some introspection and reexamination of previous projects, I have come to conclude that any of the following three (individual or combined) project scenarios will almost guarantee the formation of a death march:

  1. Naivety of Youth—The schedule has been compressed to less than half the amount estimated based on previous delivery; so for example a project that would normally be expected to take six months will be set to be delivered in three months or less. This form of a death march is most common in ra-ra speech environments and “Internet time” startups that naively believe that when it comes to their ability to deliver the “sky is the limit”.
  2. The Senility of Old Age—The development team has been reduced to operate at half the capacity. This may have come about as a result of management’s belief that a new development language, framework or technologies will double the team’s productivity. This is often seen in older companies that are downsizing while at the same time transitioning from one technology to another.
  3. Offshoring Hell—The budget for the project has been cut in half because the business believes that offshoring it is a cheaper alternative. In this scenario, the project manager is informed by the business unit sponsoring the project that it’s a “take it or leave it deal” and if the development manager doesn’t accept the budgetary constraints the business unit will offshore the entire project for less. Thus, in an attempt to save his team from the chopping block, the development manager accepts an impossible challenge.

    Another interesting side effect of this type of project is that as soon as management finally realizes that the project is going nowhere fast, they try to salvage it by throwing additional offshore resources at it, which leads to further delays (Brooks’s law).

It is true that many of the contributing factors to a death march may be beyond your control, but if you find yourself involved in one of these coveted assignments don’t panic, take notice. Contrary to the advice dispensed by some purists (i.e. transfer to another team), being assigned to such a project doesn’t mean that you should abandon it or quit your job. My advice is to keep your ethics and personal priorities separate from the politics of the project. Do your best to contribute to the success of the development, but in so doing be sure to set your manager’s expectations to realistic levels.

State your concerns in a non-argumentative and level headed manner and clearly communicate your conditions for participating in the project in terms of exactly how much overtime you will agree to and your willingness to work weekends and holidays.

Without advocating or orchestrating a mutiny, encourage your team members to speak their minds as well. In these ways, although you may not be able to cancel the project, you will likely succeed in regaining some control over it and reduce the amount of stress everyone on your team incurs.

Happy coding!

© Copyright 2009 Yaacov Apelbaum All Rights Reserved.