Blog  |  Publications  |  Puzzles
Fun & Games  |  About

Things you can infer from one dialog box

It is harder for a big company to produce decent software than a small company, as illustrated by this ugly little dialog box:

Why do big companies have trouble making decent software?

1) They have too many employees.

I believe that design and coding should be done by very small teams, and that the same people who code should design. Almost every time I visit a large company (and I’ve visited several over the last 15 years or so), I see a software team that is from 3 to 10 times too large. At these sizes, the majority of the engineers become “paper engineers.” They spend most of their time in meetings doing “design,” and delegate the actual coding to underlings, who are not experienced enough to code efficiently.

2) They have too many constraints.

Software projects at large companies are generally affected by constraints that have nothing to do with engineering. As a result, the teams are often under unreasonable deadlines. Many managers believe that the only way they can meet unreasonable deadlines is to hire more engineers. This never works, it just makes the work take longer. When this doesn’t work, the managers outsource important jobs that should be done in-house to external companies (with smaller, and more effective teams). The outsourcing produces even more in-house communication problems, and utlimately the quality of the software is compromised.

Although large companies are not incapable of producing good software, they are severely challenged and must take extraordinary measures to overcome those challenges.

Case in point: Adobe (Acrobat) Reader.

I have a love/hate relationship with Adobe Acrobat. I love the PDF format, or more accurately, I love being able to generate documents that contain things such as music notation, puzzle diagrams and math formulas, and share them with any newbie on the planet without too much trouble. PDF is a good format for doing this, since most people have Adobe’s PDF reader. I usually use non-Adobe tools, such as my own Perl scripts (with various open-source libraries) and the excellent open-source programs GhostView/Ghostscript to generate these files.

On the other hand, I think Adobe Reader is bloated and buggy and I hate having to support it. My free Sudoku puzzles generate at least one or two Adobe-related support emails a week.

Version 6 of Adobe Reader was especially nasty – it had a horribly long load time, as it loaded a bunch of plug-ins (which I never used). The unofficial workaround to this was to delete all but one or two of the plugins. Programs that see such wide use should not require “unofficial workarounds.”

Version 6 of Adobe Reader has some nasty bugs and it often crashes current versions of Firefox.

To avoid the problems with Version 6, I recently downloaded the installer for version 7 of Adobe Reader (perhaps the bugs are an inducement to get you to upgrade?). Like lots of free programs distributed by large companies, I had to click on a few checkboxes to prevent it from installing stuff I don’t want, such as the Yahoo toolbar. I realize this is a very common practice these days, I’ve seen it in installers from most large companies such as AOL, Microsoft, Adobe, and others. Its also annoying as hell, and bad marketing.

While installing Adobe Reader 7, I was greeted with this remarkable, and theoretically unnecessary dialog box:

This dialog gives away a number of interesting bits of information about the Adobe Corporation. First of all, it tells us that despite Adobe’s large size, their engineers are incapable of making a software installer that meets all the requirements of Adobe’s marketing department. In all likelihood, the folks in the marketing department decided to outsource with “NETOPSYSTEMS” to fix a problem with Adobe’s installer (a problem that could have been avoided by not including crap like the Yahoo toolbar and a bunch of unnecessary plugins).

Secondly it tells us that the marketing department was so desparate to fix this problem, that they were willing to let another company display their branding information during the installation process. Most large companinies hate doing this, and it shows that Adobe was pretty desparate to get this product out the door. Perhaps they reached a compromise solution and got them to dim it out on the bottom a bit.

Thirdly it tells us that Adobe, despite being a very large company with large resources, does not do a very good job of doing quality control on it’s software installers, because otherwise, someone would have surely noticed that the text in that dialog box is cut off on at least some machines (namely, mine, a run-of-the-mill laptop from Dell).

Fourthly, it tells us that the brilliant user-interface designers of FEAD believes that I really care to know that this particular step in the installation process is 64.4 percent done (or that the coder is working under deadline and using a built-in widget). This is a common feature in interface designs called “unnecessary accuracy,” (the bar alone should be sufficient here) and it is probable evidence that Netopsystems is affected by the diffferent set of challenges that affect companies that are too small.

Finally, it tells us that the code for Adobe Reader 7 is just too damn big, and so is Adobe.

But perhaps I grumble too much. Like a shark and pilot fish, it is because large companies like Adobe exist and prosper that small companies like Netopsystems exist and prosper.

Share and Enjoy:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • Design Float
  • E-mail this story to a friend!
  • HackerNews
  • MySpace
  • Reddit
  • Slashdot
  • StumbleUpon
  • Suggest to Techmeme via Twitter
  • Twitter

One Response to “Things you can infer from one dialog box”

  1. KrazyDad » Blog Archive » Text to Song Says:

    [...] Tracktion is a model of my conviction that the best software is written by one or two extremely talented designer/programmers, rather than large teams of middling programmers. Jules had a very clear idea when he started writing Tracktion of how he wanted it to work, and what he believed was broken in other music software packages. He intentionally violated a number of design conventions which are ubiquitious in music software (such as using tons of windows for different functions, and mimicking the user interfaces of historically popular audio interfaces). Instead Jules asked the question, “If you forget the last 100 years of music studio history, what is actually the most efficient and logical way to construct music on a computer?” Jules then set about answering that question by making some great music software. [...]