Monthly Archives: October 2013

PHPHOST BLOG

Web Hosting Related Articles You May Need

Too Many Parameters in Java Methods, Part 8: Tooling

The first seven posts of my series of dealing with too many parameters expected in Java methods focused on alternative approaches to reduce the number of parameters a method or constructor expects. In this eighth post in the series, I look at tools tha… Continue reading

Posted in Eclipse, IntelliJ IDEA, Java (General), NetBeans, Syndicated | Comments Off on Too Many Parameters in Java Methods, Part 8: Tooling

Too Many Parameters in Java Methods, Part 7: Mutable State

In this seventh post of my series on addressing the issue of too many parameters in a Java method or constructor, I look at using state to reduce the need to pass parameters. One of the reasons I have waited until the 7th post of this series to address this is that it is one of my least favorite approaches for reducing parameters passed to methods and constructors. That stated, there are multiple flavors of this approach and I definitely prefer some flavors over others.

Perhaps the best known and most widely scorned approach in all of software development for using state to reduce parameter methods is the use global variables. Although it may be semantically accurate to say that Java does not have global variables, the reality is that for good or for bad the equivalent of global variables is achieved in Java via public static constructs. A particularly popular way to achieve this in Java is via the Stateful Singleton.

In Patterns of Enterprise Application Architecture, Martin Fowler wrote that “any global data is always guilty until proven innocent.” Global variables and “global-like” constructs in Java are considered bad form for several reasons. They can make it difficult for developers maintaining and reading code to know where the values are defined or last changed or even come from. By their very nature and intent, global data violates the principles of encapsulation and data hiding.

Miško Hevery has written the following regarding the problems of static globals in an object-oriented language:

Accessing global state statically doesn’t clarify those shared dependencies to readers of the constructors and methods that use the Global State. Global State and Singletons make APIs lie about their true dependencies. … The root problem with global state is that it is globally accessible. In an ideal world, an object should be able to interact only with other objects which were directly passed into it (through a constructor, or method call).

Having state available globally reduces the need for parameters because there is no need for one object to pass data to another object if both objects already have direct access to that data. However, as Hevery put it, that’s completely orthogonal to the intent of object-oriented design.

Mutable state is also an increasing problem as concurrent applications become more common. In his JavaOne 2012 presentation on Scala, Scala creator Martin Odersky stated that “every piece of mutable state you have is a liability” in a highly concurrent world and added that the problem is “non-determinism caused by concurrent threads accessing shared mutable state.”

Although there are reasons to avoid mutable state, it still remains a generally popular approach in software development. I think there are several reasons for this including that it’s superfically easy to write mutable state sharing code and mutable shared code does provide ease of access. Some types of mutable data are popular because those types of mutable data have been taught and learned as effective for years. Finally, three are times when mutable state may be the most appropriate solution. For that last reason and to be complete, I now look at how the use of mutable state can reduce the number of parameters a method must expect.

Stateful Singleton and Static Variables

A Java implementation of Singleton and other public Java static fields are generally available to any Java code within the same Java Virtual Machine (JVM) and loaded with the same classloader [for more details, see When is a Singleton not a Singleton?].

Any data stored universally (at least from JVM/classloader perspective) is already available to client code in the same JVM and loaded with the same class loader. Because of this, there is no need to pass that data between clients and methods or constructors in that same JVM/classloader combination.

Instance State

While “statics” are considered “globally available,” narrower instance-level state can also be used in a similar fashion to reduce the need to pass parameters between methods of the same class. An advantage of this over global variables is that the accessibility is limited to instances of the class (private fields) or instances of the class’s children (private fields). Of course, if the fields are public, accessibility is pretty wide open, but the same data is not automatically available to other code in the same JVM/classloader.

The next code listing demonstrates how state data can and sometimes is used to reduce the need for parameters between two methods internal to a given class.

Example of Instance State Used to Avoid Passing Parameters

   /**
    * Simple example of using instance variable so that there is no need to
    * pass parameters to other methods defined in the same class.
    */
   public void doSomethingGoodWithInstanceVariables()
   {
      this.person =
         Person.createInstanceWithNameAndAddressOnly(
            new FullName.FullNameBuilder(new Name("Flintstone"), new Name("Fred")).createFullName(),
            new Address.AddressBuilder(new City("Bedrock"), State.UN).createAddress());
      printPerson();
   }

   /**
    * Prints instance of Person without requiring it to be passed in because it
    * is an instance variable.
    */
   public void printPerson()
   {
      out.println(this.person);
   }

The above example is somewhat contrived and simplified, but does illustrate the point: the instance variable person can be accessed by other instance methods defined in the same class, so that instance does not need to be passed between those instance methods. This does reduce the signature of potentially (public accessibility means it may be used by external methods) internal methods, but also introduces state and now means that the invoked method impacts the state of that same object. In other words, the benefit of not having to pass the parameter comes at the cost of another piece of mutable state. The other side of the trade-off, needing to pass the instance of Person because it is not an instance variable, is shown in the next code listing for comparison.

Example of Passing Parameter Rather than Using Instance Variable

   /**
    * Simple example of passing a parameter rather than using an instance variable.
    */
   public void doSomethingGoodWithoutInstanceVariables()
   {
      final Person person =
         Person.createInstanceWithNameAndAddressOnly(
            new FullName.FullNameBuilder(new Name("Flintstone"), new Name("Fred")).createFullName(),
            new Address.AddressBuilder(new City("Bedrock"), State.UN).createAddress());
      printPerson(person);
   }

   /**
    * Prints instance of Person that is passed in as a parameter.
    * 
    * @param person Instance of Person to be printed.
    */
   public void printPerson(final Person person)
   {
      out.println(person);
   }

The previous two code listings illustrate that parameter passing can be reduced by using instance state. I generally prefer to not use instance state solely to avoid parameter passing. If instance state is needed for other reasons, than the reduction of parameters to be passed is a nice side benefit, but I don’t like introducing unnecessary instance state simply to remove or reduce the number of parameters. Although there was a time when the readability of reduced parameters might have justified instance state in a large single-threaded environment, I feel that the slight readability gain from reduced parameters is not worth the cost of classes that are not thread-safe in an increasingly multi-threaded world. I still don’t like to pass a whole lot of parameters between methods of the same class, but I can use the parameters object (perhaps with a package-private scope class) to reduce the number of these parameters and pass that parameters object around instead of the large number of parameters.

JavaBean Style Construction

The JavaBeans convention/style has become extremely popular in the Java development community. Many frameworks such as Spring Framework and Hibernate rely on classes adhering to the JavaBeans conventions and some of the standards like Java Persistence API also are built around the JavaBeans conventions. There are multiple reasons for the popularity of the JavaBeans style including its ease-of-use and the ability to use reflection against this code adhering to this convention to avoid additional configuration.

The general idea behind the JavaBean style is to instantiate an object with a no-argument constructor and then set its fields via single-argument “set” methods and access it fields via no-argument “get” methods. This is demonstrated in the next code listings. The first listing shows a simple example of a PersonBean class with no-arguments constructor and getter and setter methods. That code listing also includes some of the JavaBeans-style classes it uses. That code listing is followed by code using that JavaBean style class.

Examples of JavaBeans Style Class

public class PersonBean
{
   private FullNameBean name;
   private AddressBean address;
   private Gender gender;
   private EmploymentStatus employment;
   private HomeownerStatus homeOwnerStatus;

   /** No-arguments constructor. */
   public PersonBean() {}

   public FullNameBean getName()
   {
      return this.name;
   }
   
   public void setName(final FullNameBean newName)
   {
      this.name = newName;
   }
   
   public AddressBean getAddress()
   {
      return this.address;
   }
   
   public void setAddress(final AddressBean newAddress)
   {
      this.address = newAddress;
   }

   public Gender getGender()
   {
      return this.gender;
   }
   
   public void setGender(final Gender newGender)
   {
      this.gender = newGender;
   }
   
   public EmploymentStatus getEmployment()
   {
      return this.employment;
   }
   
   public void setEmployment(final EmploymentStatus newEmployment)
   {
      this.employment = newEmployment;
   }

   public HomeownerStatus getHomeOwnerStatus()
   {
      return this.homeOwnerStatus;
   }

   public void setHomeOwnerStatus(final HomeownerStatus newHomeOwnerStatus)
   {
      this.homeOwnerStatus = newHomeOwnerStatus;
   }
}

/**
 * Full name of a person in JavaBean style.
 * 
 * @author Dustin
 */
public final class FullNameBean
{
   private Name lastName;
   private Name firstName;
   private Name middleName;
   private Salutation salutation;
   private Suffix suffix;

   /** No-args constructor for JavaBean style instantiation. */
   private FullNameBean() {}

   public Name getFirstName()
   {
      return this.firstName;
   }

   public void setFirstName(final Name newFirstName)
   {
      this.firstName = newFirstName;
   }

   public Name getLastName()
   {
      return this.lastName;
   }

   public void setLastName(final Name newLastName)
   {
      this.lastName = newLastName;
   }

   public Name getMiddleName()
   {
      return this.middleName;
   }

   public void setMiddleName(final Name newMiddleName)
   {
      this.middleName = newMiddleName;
   }

   public Salutation getSalutation()
   {
      return this.salutation;
   }
 
   public void setSalutation(final Salutation newSalutation)
   {
      this.salutation = newSalutation;
   }

   public Suffix getSuffix()
   {
      return this.suffix;
   }

   public void setSuffix(final Suffix newSuffix)
   {
      this.suffix = newSuffix;
   }

   @Override
   public String toString()
   {
      return  this.salutation + " " + this.firstName + " " + this.middleName
            + this.lastName + ", " + this.suffix;
   }
}


package dustin.examples;

/**
 * Representation of a United States address (JavaBeans style).
 * 
 * @author Dustin
 */
public final class AddressBean
{
   private StreetAddress streetAddress;
   private City city;
   private State state;

   /** No-arguments constructor for JavaBeans-style instantiation. */
   private AddressBean() {}

   public StreetAddress getStreetAddress()
   {
      return this.streetAddress;
   }

   public void setStreetAddress(final StreetAddress newStreetAddress)
   {
      this.streetAddress = newStreetAddress;
   }

   public City getCity()
   {
      return this.city;
   }

   public void setCity(final City newCity)
   {
      this.city = newCity;
   }

   public State getState()
   {
      return this.state;
   }

   public void setState(final State newState)
   {
      this.state = newState;
   }

   @Override
   public String toString()
   {
      return this.streetAddress + ", " + this.city + ", " + this.state;
   }
}

Example of JavaBeans Style Instantiation and Population

   public PersonBean createPerson()
   {
      final PersonBean person = new PersonBean();
      final FullNameBean personName = new FullNameBean();
      personName.setFirstName(new Name("Fred"));
      personName.setLastName(new Name("Flintstone"));
      person.setName(personName);
      final AddressBean address = new AddressBean();
      address.setStreetAddress(new StreetAddress("345 Cave Stone Road"));
      address.setCity(new City("Bedrock"));
      person.setAddress(address);
      return person;
   }

The examples just shown demonstrate how the JavaBeans style approach can be used. This approach makes some concessions to reduce the need to pass a large number of parameters to a class’s constructor. Instead, no parameters are passed to the constructor and each individual attribute that is needed must be set. One of the advantages of the JavaBeans style approach is that readability is enhanced as compared to a constructor with a large number of parameters because each of the “set” methods is hopefully named in a readable way.

The JavaBeans approach is simple to understand and definitely achieves the goal of reducing lengthy parameters in the case of constructors. However, there are some disadvantages to this approach as well. One advantage is a lot of tedious client code for instantiating the object and setting its attributes one-at-a-time. It is easy with this approach to neglect to set a required attribute because there is no way for the compiler to enforce all required parameters be set without leaving the JavaBeans convention. Perhaps most damaging, there are several objects instantiated in this last code listing and these objects exist in different incomplete states from the time they are instantiated until the time the final “set” method is called. During that time, the objects are in what is really an “undefined” or “incomplete” state. The existence of “set” methods necessarily means that the class’s attributes cannot be final, rendering the entire object highly mutable.

Regarding the prevalent use of the JavaBeans pattern in Java, several credible authors have called into question its value. Allen Holub’s controversial article Why getter and setter methods are evil starts off with no holds barred:

Though getter/setter methods are commonplace in Java, they are not particularly object oriented (OO). In fact, they can damage your code’s maintainability. Moreover, the presence of numerous getter and setter methods is a red flag that the program isn’t necessarily well designed from an OO perspective.

Josh Bloch, in his less forceful and more gently persuasive tone, says of the JavaBeans getter/setter style: “The JavaBeans pattern has serious disadvantages of its own” (Effective Java, Second Edition, Item #2). It is in this context that Bloch recommends the builder pattern instead for object construction.

I’m not against using the JavaBeans get/set style when the framework I’ve selected for other reasons requires it and the reasons for using that framework justify it. There are also areas where the JavaBeans style class is particularly well suited such as interacting with a data store and holding data from the data store for use by the application. However, I am not a fan of using the JavaBeans style for instantiating a question simply to avoid the need to pass parameters. I prefer one of the other approaches such as builder for that purpose.

Benefits and Advantages

I’ve covered different approaches to reducing the number of arguments to a method or constructor in this post, but they also share the same trade-off: exposing mutable state to reduce or eliminate the number of parameters that must be passed to a method or to a constructor. The advantages of these approaches are simplicity, generally readable (though “globals” can be difficult to read), and ease of first writing and use. Of course, their biggest advantage from this post’s perspective is that they generally eliminate the need for any parameter passing.

Costs and Disadvantages

The trait that all approaches covered in this post share is the exposure of mutable state. This can lead to an extremely high cost if the code is used in a highly concurrent environment. There is a certain degree of unpredictability when object state is exposed for anyone to tinker with it as they like. It can be difficult to know which code made the wrong change or failed to make a necessary change (such as failing to call a “set” method when populating a newly instantiated object).

Conclusion

Even some of the approaches to reducing parameters that I have covered earlier (such as custom types and parameters objects) can be implemented in such a way that there is (optional) mutable state, but those approaches do not require mutable state. In contrast, the approaches covered in this post to reducing parameters to methods and constructors do require mutable state.

Some of the approaches covered in this post are highly popular despite their drawbacks. This may be for a variety of reasons including prevalence of use in popular frameworks (forcing users of the framework to use that style and also providing examples to others for their own code development). Other reasons for these approaches’ popularity is the relative ease of initial development and the seemingly (deceptively) relatively little thought that needs to go into design with these approaches. In general, I prefer to spend a little more design and implementation effort to use builders and less mutable approaches when practical. However, there are cases where these mutable state approaches work well in reducing the number of parameters passed around and introduce no more risk than was already present. My feeling is that Java developers should carefully consider use of any mutable Java classes and ensure that the mutability is either desired or is a cost that is justified by the reasons for using a mutable state approach.

Original posting available at http://marxsoftware.blogspot.com/ (Inspired by Actual Events)

Continue reading

Posted in Java (General), Syndicated | Comments Off on Too Many Parameters in Java Methods, Part 7: Mutable State

Why Does Windows Have Terrible Battery Life?

I’ve become a huge fan of touch computing. I believe that most things we think of as “computers” will be de-facto tablets, either in our pocket, in our hands, possibly even mounted on our wrists or forearms.

I can’t wait for the iPad 5 this week (I’ll be ordering three), and my Surface Pro 2 should arrive this week too. Because it is a blazingly fast, modern Intel machine, I like to use the Surface Pro to predict where tablet performance ought to be for everyone in 2 to 3 years. I think of it as an iPad 7.

My main complaint with the Surface Pro is the incredibly lackluster battery life. Granted, this is a classic Intel x86 box we’re talking about, not some efficient ARM system-on-a-chip designed to run on a tiny battery. Still, I was hopeful that the first Surface Pro with Haswell inside would produce giant gains in battery life as Intel promised. Then I saw this graph:

Web browsing battery life, Surface Pro vs Surface Pro 2

So WiFi web browsing battery life, arguably the most common user activity there is on a computer these days, goes from 4.7 hours on the Surface Pro to 6.7 hours on the Surface Pro 2, a 42% increase. That’s a decent increase, I suppose, but I was hoping for something more like 8 hours, something closer to doubling of battery life – to bring the Surface Pro in line with other tablets.

Nearly 7 whole hours of WiFi web browsing for a real computer in tablet form factor … that’s not bad, right? Let’s see how the 2013 MacBook Air does, which spec-wise is about as close as we can get to the Surface Pro 2. The screen is somewhat lower resolution and not touch capable, of course, but under the hood, the i5-4200u CPU and LPDDR3 RAM are nearly the same. It’s a real computer, too, using the latest Intel technology.

Macbook-air-2013-web-browsing

The Surface Pro 2 has a 42 Wh battery, which puts it closer to the 11 inch Air in capacity. Still, over 11 hours of battery life browsing the web on WiFi? That means the Air is somehow producing nearly two times the battery efficiency of the best hardware and software combination Microsoft can muster, for what I consider to be the most common usage pattern on a computer today. That’s shocking. Scandalous, even.

UPDATE: Turns out the Surface 2 Pro was shipped with bad firmware. Once updated, the WiFi adapter enters lower idle power states and this helps a lot, going from 6.6 hours of browsing time to 8.3 hours, a 25% improvement! That puts it much more in line with the rest of the field, at least, even if it doesn’t achieve Mac like runtime.

It’s not exactly news that Windows historically doesn’t do as well as OS X on battery life. Way back in 2009, AnandTech tested a MacBook Pro with multiple operating systems:

2009 15-inch MacBook Pro (73WHr battery) OS X 10.5.7 Windows Vista x64 SP1 Windows 7 RC1
Wireless Web Browsing (No Flash) Battery Life 8.13 hours 6.02 hours 5.48 hours

That’s fine, I knew about this discrepancy, but here’s what really bothers me:

  1. The Windows light usage battery life situation has not improved at all since 2009. If anything the disparity between OS X and Windows light usage battery life has gotten worse.
  2. Microsoft positions Windows 8 as an operating system that’s great for tablets, which are designed for casual web browsing and light app use – but how can that possibly be true when Windows idle power management is so much worse than the competition’s desktop operating system in OS X – much less their tablet and phone operating system, iOS?

(It’s true that Bay Trail, Intel’s new lower power CPU from the Atom family, achieves 8.6 hours of WiFi web browsing. That’s solidly in the middle of the tablet pack for battery life. But all the evidence tells me that the very same hardware would do a lot better in OS X, or even iOS. At least Intel has finally produced something that’s reasonably competitive with the latest ARM chips.)

Perhaps most damning of all, if you take the latest and greatest 13″ MacBook Air, and install Windows 8 on it, guess what happens to battery life?

One of the best things about the standard 2013 MacBook Air 13″ is that it has record-breaking battery life of 14 hrs 25 min (with the screen brightness at 100 cd/m², headphones plugged in and the Wi-Fi, Bluetooth and keyboard backlighting turned off). Under Windows 8 the results are more mixed [..] in the same conditions it lasts only 7 hrs 40 min. That’s still very high—it’s better than the Asus Zenbook Prime UX31A’s 6 hours and the Samsung Series 7 Ultra’s 5 hours—but it’s only half the astronomical 14 hours + that the 13″ MacBook Air is capable of.

Instead of the 26% less battery life in Windows that Anand measured in 2009, we’re now seeing 50% less battery life. This is an enormous gap between Windows and OS X in what is arguably the most common form of computer usage today, basic WiFi web browsing. That’s shameful. Embarrassing, even.

I had a brief Twitter conversation with Anand Shimpi of Anandtech about this, and he was as perplexed as I was. Nobody could explain the technical basis for this vast difference in idle power management on the same hardware. None of the PC vendors he spoke to could justify it, or produce a Windows box that managed similar battery life to OS X. And that battery life gap is worse today – even when using Microsoft’s own hardware, designed in Microsoft’s labs, running Microsoft’s latest operating system released this week. Microsoft can no longer hand wave this vast difference away based on vague references to “poorly optimized third party drivers”.

Apple is clearly doing a great job here. Kudos. If you want a device that delivers maximum battery life for light web browsing, there’s no question that you should get something with an Apple logo on it. I just wish somebody could explain to me and Anand why Windows is so awful at managing idle power. We’re at a loss to understand why Windows’ terrible – and worsening! – idle battery life performance isn’t the source of far more industry outrage.

[advertisement] How are you showing off your awesome? Create a Stack Overflow Careers profile and show off all of your hard work from Stack Overflow, Github, and virtually every other coding site. Who knows, you might even get recruited for a great new position!

Continue reading

Posted in Syndicated | Comments Off on Why Does Windows Have Terrible Battery Life?

Why Does Windows Have Terrible Battery Life?

I’ve become a huge fan of touch computing. I believe that most things we think of as “computers” will be de-facto tablets, either in our pocket, in our hands, possibly even mounted on our wrists or forearms.

I can’t wait for the iPad 5 this week (I’ll be ordering three), and my Surface Pro 2 should arrive this week too. Because it is a blazingly fast, modern Intel machine, I like to use the Surface Pro to predict where tablet performance ought to be for everyone in 2 to 3 years. I think of it as an iPad 7.

My main complaint with the Surface Pro is the incredibly lackluster battery life. Granted, this is a classic Intel x86 box we’re talking about, not some efficient ARM system-on-a-chip designed to run on a tiny battery. Still, I was hopeful that the first Surface Pro with Haswell inside would produce giant gains in battery life as Intel promised. Then I saw this graph:

Web browsing battery life, Surface Pro vs Surface Pro 2

So WiFi web browsing battery life, arguably the most common user activity there is on a computer these days, goes from 4.7 hours on the Surface Pro to 6.7 hours on the Surface Pro 2, a 42% increase. That’s a decent increase, I suppose, but I was hoping for something more like 8 hours, something closer to doubling of battery life – to bring the Surface Pro in line with other tablets.

Nearly 7 whole hours of WiFi web browsing for a real computer in tablet form factor … that’s not bad, right? Let’s see how the 2013 MacBook Air does, which spec-wise is about as close as we can get to the Surface Pro 2. The screen is somewhat lower resolution and not touch capable, of course, but under the hood, the i5-4200u CPU and LPDDR3 RAM are nearly the same. It’s a real computer, too, using the latest Intel technology.

Macbook-air-2013-web-browsing

The Surface Pro 2 has a 42 Wh battery, which puts it closer to the 11 inch Air in capacity. Still, over 11 hours of battery life browsing the web on WiFi? That means the Air is somehow producing nearly two times the battery efficiency of the best hardware and software combination Microsoft can muster, for what I consider to be the most common usage pattern on a computer today. That’s shocking. Scandalous, even.

UPDATE: Turns out the Surface 2 Pro was shipped with bad firmware. Once updated, the WiFi adapter enters lower idle power states and this helps a lot, going from 6.6 hours of browsing time to 8.3 hours, a 25% improvement! That puts it much more in line with the rest of the field, at least, even if it doesn’t achieve Mac like runtime.

It’s not exactly news that Windows historically doesn’t do as well as OS X on battery life. Way back in 2009, AnandTech tested a MacBook Pro with multiple operating systems:

2009 15-inch MacBook Pro (73WHr battery) OS X 10.5.7 Windows Vista x64 SP1 Windows 7 RC1
Wireless Web Browsing (No Flash) Battery Life 8.13 hours 6.02 hours 5.48 hours

That’s fine, I knew about this discrepancy, but here’s what really bothers me:

  1. The Windows light usage battery life situation has not improved at all since 2009. If anything the disparity between OS X and Windows light usage battery life has gotten worse.
  2. Microsoft positions Windows 8 as an operating system that’s great for tablets, which are designed for casual web browsing and light app use – but how can that possibly be true when Windows idle power management is so much worse than the competition’s desktop operating system in OS X – much less their tablet and phone operating system, iOS?

(It’s true that Bay Trail, Intel’s new lower power CPU from the Atom family, achieves 8.6 hours of WiFi web browsing. That’s solidly in the middle of the tablet pack for battery life. But all the evidence tells me that the very same hardware would do a lot better in OS X, or even iOS. At least Intel has finally produced something that’s reasonably competitive with the latest ARM chips.)

Perhaps most damning of all, if you take the latest and greatest 13″ MacBook Air, and install Windows 8 on it, guess what happens to battery life?

One of the best things about the standard 2013 MacBook Air 13″ is that it has record-breaking battery life of 14 hrs 25 min (with the screen brightness at 100 cd/m², headphones plugged in and the Wi-Fi, Bluetooth and keyboard backlighting turned off). Under Windows 8 the results are more mixed [..] in the same conditions it lasts only 7 hrs 40 min. That’s still very high—it’s better than the Asus Zenbook Prime UX31A’s 6 hours and the Samsung Series 7 Ultra’s 5 hours—but it’s only half the astronomical 14 hours + that the 13″ MacBook Air is capable of.

Instead of the 26% less battery life in Windows that Anand measured in 2009, we’re now seeing 50% less battery life. This is an enormous gap between Windows and OS X in what is arguably the most common form of computer usage today, basic WiFi web browsing. That’s shameful. Embarrassing, even.

I had a brief Twitter conversation with Anand Shimpi of Anandtech about this, and he was as perplexed as I was. Nobody could explain the technical basis for this vast difference in idle power management on the same hardware. None of the PC vendors he spoke to could justify it, or produce a Windows box that managed similar battery life to OS X. And that battery life gap is worse today – even when using Microsoft’s own hardware, designed in Microsoft’s labs, running Microsoft’s latest operating system released this week. Microsoft can no longer hand wave this vast difference away based on vague references to “poorly optimized third party drivers”.

Apple is clearly doing a great job here. Kudos. If you want a device that delivers maximum battery life for light web browsing, there’s no question that you should get something with an Apple logo on it. I just wish somebody could explain to me and Anand why Windows is so awful at managing idle power. We’re at a loss to understand why Windows’ terrible – and worsening! – idle battery life performance isn’t the source of far more industry outrage.

[advertisement] How are you showing off your awesome? Create a Stack Overflow Careers profile and show off all of your hard work from Stack Overflow, Github, and virtually every other coding site. Who knows, you might even get recruited for a great new position!

Continue reading

Posted in Syndicated | Comments Off on Why Does Windows Have Terrible Battery Life?

Why Does Windows Have Terrible Battery Life?

I’ve become a huge fan of touch computing. I believe that most things we think of as “computers” will be de-facto tablets, either in our pocket, in our hands, possibly even mounted on our wrists or forearms.

I can’t wait for the iPad 5 this week (I’ll be ordering three), and my Surface Pro 2 should arrive this week too. Because it is a blazingly fast, modern Intel machine, I like to use the Surface Pro to predict where tablet performance ought to be for everyone in 2 to 3 years. I think of it as an iPad 7.

My main complaint with the Surface Pro is the incredibly lackluster battery life. Granted, this is a classic Intel x86 box we’re talking about, not some efficient ARM system-on-a-chip designed to run on a tiny battery. Still, I was hopeful that the first Surface Pro with Haswell inside would produce giant gains in battery life as Intel promised. Then I saw this graph:

Web browsing battery life, Surface Pro vs Surface Pro 2

So WiFi web browsing battery life, arguably the most common user activity there is on a computer these days, goes from 4.7 hours on the Surface Pro to 6.7 hours on the Surface Pro 2, a 42% increase. That’s a decent increase, I suppose, but I was hoping for something more like 8 hours, something closer to doubling of battery life – to bring the Surface Pro in line with other tablets.

Nearly 7 whole hours of WiFi web browsing for a real computer in tablet form factor … that’s not bad, right? Let’s see how the 2013 MacBook Air does, which spec-wise is about as close as we can get to the Surface Pro 2. The screen is somewhat lower resolution and not touch capable, of course, but under the hood, the i5-4200u CPU and LPDDR3 RAM are nearly the same. It’s a real computer, too, using the latest Intel technology.

Macbook-air-2013-web-browsing

The Surface Pro 2 has a 42 Wh battery, which puts it closer to the 11 inch Air in capacity. Still, over 11 hours of battery life browsing the web on WiFi? That means the Air is somehow producing nearly two times the battery efficiency of the best hardware and software combination Microsoft can muster, for what I consider to be the most common usage pattern on a computer today. That’s shocking. Scandalous, even.

UPDATE: Turns out the Surface 2 Pro was shipped with bad firmware. Once updated, the WiFi adapter enters lower idle power states and this helps a lot, going from 6.6 hours of browsing time to 8.3 hours, a 25% improvement! That puts it much more in line with the rest of the field, at least, even if it doesn’t achieve Mac like runtime.

It’s not exactly news that Windows historically doesn’t do as well as OS X on battery life. Way back in 2009, AnandTech tested a MacBook Pro with multiple operating systems:

2009 15-inch MacBook Pro (73WHr battery) OS X 10.5.7 Windows Vista x64 SP1 Windows 7 RC1
Wireless Web Browsing (No Flash) Battery Life 8.13 hours 6.02 hours 5.48 hours

That’s fine, I knew about this discrepancy, but here’s what really bothers me:

  1. The Windows light usage battery life situation has not improved at all since 2009. If anything the disparity between OS X and Windows light usage battery life has gotten worse.
  2. Microsoft positions Windows 8 as an operating system that’s great for tablets, which are designed for casual web browsing and light app use – but how can that possibly be true when Windows idle power management is so much worse than the competition’s desktop operating system in OS X – much less their tablet and phone operating system, iOS?

(It’s true that Bay Trail, Intel’s new lower power CPU from the Atom family, achieves 8.6 hours of WiFi web browsing. That’s solidly in the middle of the tablet pack for battery life. But all the evidence tells me that the very same hardware would do a lot better in OS X, or even iOS. At least Intel has finally produced something that’s reasonably competitive with the latest ARM chips.)

Perhaps most damning of all, if you take the latest and greatest 13″ MacBook Air, and install Windows 8 on it, guess what happens to battery life?

One of the best things about the standard 2013 MacBook Air 13″ is that it has record-breaking battery life of 14 hrs 25 min (with the screen brightness at 100 cd/m², headphones plugged in and the Wi-Fi, Bluetooth and keyboard backlighting turned off). Under Windows 8 the results are more mixed [..] in the same conditions it lasts only 7 hrs 40 min. That’s still very high—it’s better than the Asus Zenbook Prime UX31A’s 6 hours and the Samsung Series 7 Ultra’s 5 hours—but it’s only half the astronomical 14 hours + that the 13″ MacBook Air is capable of.

Instead of the 26% less battery life in Windows that Anand measured in 2009, we’re now seeing 50% less battery life. This is an enormous gap between Windows and OS X in what is arguably the most common form of computer usage today, basic WiFi web browsing. That’s shameful. Embarrassing, even.

I had a brief Twitter conversation with Anand Shimpi of Anandtech about this, and he was as perplexed as I was. Nobody could explain the technical basis for this vast difference in idle power management on the same hardware. None of the PC vendors he spoke to could justify it, or produce a Windows box that managed similar battery life to OS X. And that battery life gap is worse today – even when using Microsoft’s own hardware, designed in Microsoft’s labs, running Microsoft’s latest operating system released this week. Microsoft can no longer hand wave this vast difference away based on vague references to “poorly optimized third party drivers”.

Apple is clearly doing a great job here. Kudos. If you want a device that delivers maximum battery life for light web browsing, there’s no question that you should get something with an Apple logo on it. I just wish somebody could explain to me and Anand why Windows is so awful at managing idle power. We’re at a loss to understand why Windows’ terrible – and worsening! – idle battery life performance isn’t the source of far more industry outrage.

[advertisement] How are you showing off your awesome? Create a Stack Overflow Careers profile and show off all of your hard work from Stack Overflow, Github, and virtually every other coding site. Who knows, you might even get recruited for a great new position!

Continue reading

Posted in Syndicated | Comments Off on Why Does Windows Have Terrible Battery Life?

Too Many Parameters in Java Methods, Part 6: Method Returns

In the current series of posts I am writing on reducing the number of parameters required to call Java methods and constructors, I have focused so far on approaches that directly affect the parameters themselves (custom types, parameters objects, build… Continue reading

Posted in Java (General), Syndicated | Comments Off on Too Many Parameters in Java Methods, Part 6: Method Returns

You Don’t Need Millions of Dollars

Masters of Doom is the story of John Carmack and John Romero creating the seminal games Wolfenstein 3D, Doom, and Quake.

Masters-of-doom-book-cover

It’s an amazing work on so many levels – but primarily because of the exhaustive research the author undertook to tell this story.

To re-create the story of the Two Johns, I conducted hundreds of interviews over six years, often with each person on multiple occasions. After moving to Dallas in the fall of 2000 for research, I became known in offices, barbecue joints, and bars around town as “the guy writing the Book.” John Romero and John Carmack each spent dozens of hours in person answering my most picayune questions: how they were feeling, what they were thinking, what they were saying, hearing, seeing, playing. What they and others couldn’t recall, I unearthed from websites, newsgroups, e-mails, chat transcripts, and magazines (though I drew from some of these articles, I made a point of getting the gamers’ own versions of what happened as well). I also played a delirious amount of games: at home, online, and at a couple tournaments (yeah, I lost).

I spent six months transcribing all my taped interviews. From this material, I assembled a narrative of dialogue and description that re-creates the events as faithfully and accurately as possible. As often as appropriate, I told the story from each person’s point of view to give readers the different perspectives.

It’s unusual to find a book about a contentious, complex friendship and business relationship that both parties sign off on – and even a decade later, regularly recommend to people interested in their personal back stories. But it is a testament to just how right Kushner got this story that both Romero and Carmack do. This is exactly the sort of meticulously researched, multiple viewpoint biography that you’d want to read about important people in your industry. In that sense, it’s kind of the opposite of the Jobs biography, which I liked well enough, but it presented one viewpoint, and often in a very incomplete, sloppily researched way. I would kill to read a book this good about Jobs.

In a way, I grew up with these guys. I am almost exactly the same age they are. I missed the Wolfenstein 3D release because I was still in college, but come December 1993, there I was, bursting with anticipation waiting for the release of Doom along with every other early PC gamer. And who gave Doom its name? Oddly enough, Tom Cruise did.

I’ve had a lifelong love affair with first person shooters since encountering Wolf3D and Doom. I played about every Doom engine game there was to death. I even had a brief encounter with Romero himself on the modem based multiplayer hub DWANGO where I proverbially “sucked it down”. And after the Internet hit around ’95, I continued to follow Quake development obsessively online, poring over every .plan file update, and living the drama of the inevitable breakup, the emergence of GLQuake and 3D accelerators, and the road to Quake 3.

It is also an incredibly inspiring story. Here’s a stereotypical group of geeky programmers from sketchy home backgrounds who went on to … basically create an entire industry from scratch on their own terms.

Shareware. Romero was familiar with the concept. It dated back to a guy named Andrew Fluegelman, founding editor of PC World magazine. In 1980, Fluegelman wrote a program called PC-Talk and released it online with a note saying that anyone who liked the wares should feel free to send him some “appreciation” money. Soon enough he had to hire a staff to count all the checks. Fluegelman called the practice “shareware,” “an experiment in economics.” Over the eighties other hackers picked up the ball, making their programs for Apples, PCs, and other computers available in the same honor code: Try it, if you like it, pay me. The payment would entitle the customer to receive technical support and updates.

The Association of Shareware Professionals put the business, largely domestic, between $10 and $20 million annually—even with only an estimated 10 percent of customers paying to register a shareware title. Forbes magazine marveled at the trend, writing in 1988 that “if this doesn’t sound like a very sound way to build a business, think again.” Shareware, it argued, relied not on expensive advertising but on word of mouth or, as one practitioner put it, “word of disk.” Robert Wallace, a top programmer at Microsoft, turned a shareware program of his called PC-Write into a multimillion-dollar empire. Most authors, however, were happy to break six figures and often made little more than $25,000 per year. Selling a thousand copies of a title in one year was a great success. Shareware was still a radical conceit, one that, furthermore, had been used only for utility programs, like check-balancing programs and word-processing wares. [Shareware] had never been exploited for games.

Does anyone even remember what shareware is? What is the equivalent to shareware today? Distributing software yourself on the Internet? Sort of. I’d say it’s more analogous to the various app stores: Google Play, Apple App Store, Windows Store. Going directly to the users. But they found shareware games didn’t work, at least initially:

When it came time to distribute the games, Scott took a long, hard look at the shareware market. He liked what he saw: the fact that he could run everything himself without having to deal with retailers or publishers. So he followed suit, putting out two text-based games in their entirety and waiting for the cash to roll in. But the cash didn’t roll; it didn’t even trickle. Gamers, he realized, might be a different breed from those consumers who actually paid for utility shareware. They were more apt simply to take what they could get for free. Scott did some research and realized he wasn’t alone; other programmers who had released games in their entirety as shareware were broke too. People may be honest, he thought, but they’re also generally lazy. They need an incentive.

Then he got an idea. Instead of giving away the entire game, why not give out only the first portion, then make the player buy the rest of the game directly from him? No one had tried it before, but there was no reason it couldn’t work. The games Scott was making were perfectly suited to such a plan because they were broken up into short episodes or “levels” of play. He could simply put out, say, fifteen levels of a game, then tell players that if they sent him a check he would send them the remaining thirty.

You know how game companies spent the last 5 years figuring out that free games with 100% in-app purchases are the optimum (and maybe, only) business model for games today? The guys at id had figured that all out twenty seven years ago. Those sounds you hear in the distance are a little bit of history repeating.

Id Software was more than a unique business model that gave almost all the power to the programmers. It was the explosive combination of shareware delivery with a particular genius programmer inventing new techniques for PC games that nobody had seen before: John Carmack. It may sound prosaic and banal now, but smooth scrolling platforming, texture mapped walls, lighting models, and high speed software 3D rendering on a PC were all virtually unheard of at the time Carmack created the engines that made them commonplace.

Carmack_Headshot_PR_660

Carmack, like Abrash, is a legend in programming circles, and for good reason. The stories in this book about him are, frankly, a little scary. His devotion to the machine borders on fanatical; he regularly worked 80 hour weeks and he’d take “vacations” where it was just him and a computer alone in a hotel room for a whole week – just for fun, to relax. His output is herculean. But he also realizes that all his hard work is made possible by a long line of other programmers who came before him.

Al had never seen a side scrolling like this for the PC. “Wow,” he told Carmack, “you should patent this technology.

Carmack turned red. “If you ever ask me to patent anything,” he snapped, “I’ll quit.” Al assumed Carmack was trying to protect his own financial interests, but in reality he had struck what was growing into an increasingly raw nerve for the young, idealistic programmer. It was one of the few things that could truly make him angry. It was ingrained in his bones since his first reading of the Hacker Ethic. All of science and technology and culture and learning and academics is built upon using the work that others have done before, Carmack thought. But to take a patenting approach and say it’s like, well, this idea is my idea, you cannot extend this idea in any way, because I own this idea—it just seems so fundamentally wrong. Patents were jeopardizing the very thing that was central to his life: writing code to solve problems. If the world became a place in which he couldn’t solve a problem without infringing on someone’s patents, he would be very unhappy living there.

In that spirit, Carmack regularly releases his old engines under GPL for other programmers to learn from. Don’t miss Fabien Sanglard’s epic deconstruction of the Doom 3 codebase, for example. That’s only one iteration behind the current id engine which was used for Rage and (apparently) will be used for the upcoming Doom 4.

One of my very favorite quotes of all time comes at the end of the book.

Carmack disdained talk of highfalutin things like legacies but when pressed would allow at least one thought on his own. “In the information age, the barriers just aren’t there,” he said. “The barriers are self-imposed. If you want to set off and go develop some grand new thing, you don’t need millions of dollars of capitalization. You need enough pizza and Diet Coke to stick in your refrigerator, a cheap PC to work on, and the dedication to go through with it. We slept on floors. We waded across rivers.”

And indeed they did, as the book will attest. Both @ID_AA_Carmack and @romero are still lifelong, influential, inspiring members of the game and programming communities. They are here for the long haul because they love this stuff and always have.

The ultimate point of Masters of Doom is that today you no longer need to be as brilliant as John Carmack to achieve success, and John Carmack himself will be the first to tell you that. Where John was sitting in a cubicle by himself in Mesquite, Texas for 80 hours a week painstakingly inventing all this stuff from first principles, on hardware that was barely capable, you have a supercomputer in your pocket, another supercomputer on your desk, and two dozen open source frameworks and libraries that can do 90% of the work for you. You have GitHub, Wikipedia, Stack Overflow, and the whole of the Internet.

All you have to do is get off your butt and use them.

[advertisement] Hiring developers? Post your open positions with Stack Overflow Careers and reach over 20MM awesome devs already on Stack Overflow. Create your satisfaction-guaranteed job listing today!

Continue reading

Posted in Syndicated | Comments Off on You Don’t Need Millions of Dollars

You Don't Need Millions of Dollars

Masters of Doom is the story of John Carmack and John Romero creating the seminal games Wolfenstein 3D, Doom, and Quake.

Masters-of-doom-book-cover

It’s an amazing work on so many levels – but primarily because of the exhaustive research the author undertook to tell this story.

To re-create the story of the Two Johns, I conducted hundreds of interviews over six years, often with each person on multiple occasions. After moving to Dallas in the fall of 2000 for research, I became known in offices, barbecue joints, and bars around town as “the guy writing the Book.” John Romero and John Carmack each spent dozens of hours in person answering my most picayune questions: how they were feeling, what they were thinking, what they were saying, hearing, seeing, playing. What they and others couldn’t recall, I unearthed from websites, newsgroups, e-mails, chat transcripts, and magazines (though I drew from some of these articles, I made a point of getting the gamers’ own versions of what happened as well). I also played a delirious amount of games: at home, online, and at a couple tournaments (yeah, I lost).

I spent six months transcribing all my taped interviews. From this material, I assembled a narrative of dialogue and description that re-creates the events as faithfully and accurately as possible. As often as appropriate, I told the story from each person’s point of view to give readers the different perspectives.

It’s unusual to find a book about a contentious, complex friendship and business relationship that both parties sign off on – and even a decade later, regularly recommend to people interested in their personal back stories. But it is a testament to just how right Kushner got this story that both Romero and Carmack do. This is exactly the sort of meticulously researched, multiple viewpoint biography that you’d want to read about important people in your industry. In that sense, it’s kind of the opposite of the Jobs biography, which I liked well enough, but it presented one viewpoint, and often in a very incomplete, sloppily researched way. I would kill to read a book this good about Jobs.

In a way, I grew up with these guys. I am almost exactly the same age they are. I missed the Wolfenstein 3D release because I was still in college, but come December 1993, there I was, bursting with anticipation waiting for the release of Doom along with every other early PC gamer. And who gave Doom its name? Oddly enough, Tom Cruise did.

I’ve had a lifelong love affair with first person shooters since encountering Wolf3D and Doom. I played about every Doom engine game there was to death. I even had a brief encounter with Romero himself on the modem based multiplayer hub DWANGO where I proverbially “sucked it down”. And after the Internet hit around ’95, I continued to follow Quake development obsessively online, poring over every .plan file update, and living the drama of the inevitable breakup, the emergence of GLQuake and 3D accelerators, and the road to Quake 3.

It is also an incredibly inspiring story. Here’s a stereotypical group of geeky programmers from sketchy home backgrounds who went on to … basically create an entire industry from scratch on their own terms.

Shareware. Romero was familiar with the concept. It dated back to a guy named Andrew Fluegelman, founding editor of PC World magazine. In 1980, Fluegelman wrote a program called PC-Talk and released it online with a note saying that anyone who liked the wares should feel free to send him some “appreciation” money. Soon enough he had to hire a staff to count all the checks. Fluegelman called the practice “shareware,” “an experiment in economics.” Over the eighties other hackers picked up the ball, making their programs for Apples, PCs, and other computers available in the same honor code: Try it, if you like it, pay me. The payment would entitle the customer to receive technical support and updates.

The Association of Shareware Professionals put the business, largely domestic, between $10 and $20 million annually—even with only an estimated 10 percent of customers paying to register a shareware title. Forbes magazine marveled at the trend, writing in 1988 that “if this doesn’t sound like a very sound way to build a business, think again.” Shareware, it argued, relied not on expensive advertising but on word of mouth or, as one practitioner put it, “word of disk.” Robert Wallace, a top programmer at Microsoft, turned a shareware program of his called PC-Write into a multimillion-dollar empire. Most authors, however, were happy to break six figures and often made little more than $25,000 per year. Selling a thousand copies of a title in one year was a great success. Shareware was still a radical conceit, one that, furthermore, had been used only for utility programs, like check-balancing programs and word-processing wares. [Shareware] had never been exploited for games.

Does anyone even remember what shareware is? What is the equivalent to shareware today? Distributing software yourself on the Internet? Sort of. I’d say it’s more analogous to the various app stores: Google Play, Apple App Store, Windows Store. Going directly to the users. But they found shareware games didn’t work, at least initially:

When it came time to distribute the games, Scott took a long, hard look at the shareware market. He liked what he saw: the fact that he could run everything himself without having to deal with retailers or publishers. So he followed suit, putting out two text-based games in their entirety and waiting for the cash to roll in. But the cash didn’t roll; it didn’t even trickle. Gamers, he realized, might be a different breed from those consumers who actually paid for utility shareware. They were more apt simply to take what they could get for free. Scott did some research and realized he wasn’t alone; other programmers who had released games in their entirety as shareware were broke too. People may be honest, he thought, but they’re also generally lazy. They need an incentive.

Then he got an idea. Instead of giving away the entire game, why not give out only the first portion, then make the player buy the rest of the game directly from him? No one had tried it before, but there was no reason it couldn’t work. The games Scott was making were perfectly suited to such a plan because they were broken up into short episodes or “levels” of play. He could simply put out, say, fifteen levels of a game, then tell players that if they sent him a check he would send them the remaining thirty.

You know how game companies spent the last 5 years figuring out that free games with 100% in-app purchases are the optimum (and maybe, only) business model for games today? The guys at id had figured that all out twenty seven years ago. Those sounds you hear in the distance are a little bit of history repeating.

Id Software was more than a unique business model that gave almost all the power to the programmers. It was the explosive combination of shareware delivery with a particular genius programmer inventing new techniques for PC games that nobody had seen before: John Carmack. It may sound prosaic and banal now, but smooth scrolling platforming, texture mapped walls, lighting models, and high speed software 3D rendering on a PC were all virtually unheard of at the time Carmack created the engines that made them commonplace.

Carmack_Headshot_PR_660

Carmack, like Abrash, is a legend in programming circles, and for good reason. The stories in this book about him are, frankly, a little scary. His devotion to the machine borders on fanatical; he regularly worked 80 hour weeks and he’d take “vacations” where it was just him and a computer alone in a hotel room for a whole week – just for fun, to relax. His output is herculean. But he also realizes that all his hard work is made possible by a long line of other programmers who came before him.

Al had never seen a side scrolling like this for the PC. “Wow,” he told Carmack, “you should patent this technology.

Carmack turned red. “If you ever ask me to patent anything,” he snapped, “I’ll quit.” Al assumed Carmack was trying to protect his own financial interests, but in reality he had struck what was growing into an increasingly raw nerve for the young, idealistic programmer. It was one of the few things that could truly make him angry. It was ingrained in his bones since his first reading of the Hacker Ethic. All of science and technology and culture and learning and academics is built upon using the work that others have done before, Carmack thought. But to take a patenting approach and say it’s like, well, this idea is my idea, you cannot extend this idea in any way, because I own this idea—it just seems so fundamentally wrong. Patents were jeopardizing the very thing that was central to his life: writing code to solve problems. If the world became a place in which he couldn’t solve a problem without infringing on someone’s patents, he would be very unhappy living there.

In that spirit, Carmack regularly releases his old engines under GPL for other programmers to learn from. Don’t miss Fabien Sanglard’s epic deconstruction of the Doom 3 codebase, for example. That’s only one iteration behind the current id engine which was used for Rage and (apparently) will be used for the upcoming Doom 4.

One of my very favorite quotes of all time comes at the end of the book.

Carmack disdained talk of highfalutin things like legacies but when pressed would allow at least one thought on his own. “In the information age, the barriers just aren’t there,” he said. “The barriers are self-imposed. If you want to set off and go develop some grand new thing, you don’t need millions of dollars of capitalization. You need enough pizza and Diet Coke to stick in your refrigerator, a cheap PC to work on, and the dedication to go through with it. We slept on floors. We waded across rivers.”

And indeed they did, as the book will attest. Both @ID_AA_Carmack and @romero are still lifelong, influential, inspiring members of the game and programming communities. They are here for the long haul because they love this stuff and always have.

The ultimate point of Masters of Doom is that today you no longer need to be as brilliant as John Carmack to achieve success, and John Carmack himself will be the first to tell you that. Where John was sitting in a cubicle by himself in Mesquite, Texas for 80 hours a week painstakingly inventing all this stuff from first principles, on hardware that was barely capable, you have a supercomputer in your pocket, another supercomputer on your desk, and two dozen open source frameworks and libraries that can do 90% of the work for you. You have GitHub, Wikipedia, Stack Overflow, and the whole of the Internet.

All you have to do is get off your butt and use them.

[advertisement] Hiring developers? Post your open positions with Stack Overflow Careers and reach over 20MM awesome devs already on Stack Overflow. Create your satisfaction-guaranteed job listing today!

Continue reading

Posted in Syndicated | Comments Off on You Don't Need Millions of Dollars

You Don't Need Millions of Dollars

Masters of Doom is the story of John Carmack and John Romero creating the seminal games Wolfenstein 3D, Doom, and Quake.

Masters-of-doom-book-cover

It’s an amazing work on so many levels – but primarily because of the exhaustive research the author undertook to tell this story.

To re-create the story of the Two Johns, I conducted hundreds of interviews over six years, often with each person on multiple occasions. After moving to Dallas in the fall of 2000 for research, I became known in offices, barbecue joints, and bars around town as “the guy writing the Book.” John Romero and John Carmack each spent dozens of hours in person answering my most picayune questions: how they were feeling, what they were thinking, what they were saying, hearing, seeing, playing. What they and others couldn’t recall, I unearthed from websites, newsgroups, e-mails, chat transcripts, and magazines (though I drew from some of these articles, I made a point of getting the gamers’ own versions of what happened as well). I also played a delirious amount of games: at home, online, and at a couple tournaments (yeah, I lost).

I spent six months transcribing all my taped interviews. From this material, I assembled a narrative of dialogue and description that re-creates the events as faithfully and accurately as possible. As often as appropriate, I told the story from each person’s point of view to give readers the different perspectives.

It’s unusual to find a book about a contentious, complex friendship and business relationship that both parties sign off on – and even a decade later, regularly recommend to people interested in their personal back stories. But it is a testament to just how right Kushner got this story that both Romero and Carmack do. This is exactly the sort of meticulously researched, multiple viewpoint biography that you’d want to read about important people in your industry. In that sense, it’s kind of the opposite of the Jobs biography, which I liked well enough, but it presented one viewpoint, and often in a very incomplete, sloppily researched way. I would kill to read a book this good about Jobs.

In a way, I grew up with these guys. I am almost exactly the same age they are. I missed the Wolfenstein 3D release because I was still in college, but come December 1993, there I was, bursting with anticipation waiting for the release of Doom along with every other early PC gamer. And who gave Doom its name? Oddly enough, Tom Cruise did.

I’ve had a lifelong love affair with first person shooters since encountering Wolf3D and Doom. I played about every Doom engine game there was to death. I even had a brief encounter with Romero himself on the modem based multiplayer hub DWANGO where I proverbially “sucked it down”. And after the Internet hit around ’95, I continued to follow Quake development obsessively online, poring over every .plan file update, and living the drama of the inevitable breakup, the emergence of GLQuake and 3D accelerators, and the road to Quake 3.

It is also an incredibly inspiring story. Here’s a stereotypical group of geeky programmers from sketchy home backgrounds who went on to … basically create an entire industry from scratch on their own terms.

Shareware. Romero was familiar with the concept. It dated back to a guy named Andrew Fluegelman, founding editor of PC World magazine. In 1980, Fluegelman wrote a program called PC-Talk and released it online with a note saying that anyone who liked the wares should feel free to send him some “appreciation” money. Soon enough he had to hire a staff to count all the checks. Fluegelman called the practice “shareware,” “an experiment in economics.” Over the eighties other hackers picked up the ball, making their programs for Apples, PCs, and other computers available in the same honor code: Try it, if you like it, pay me. The payment would entitle the customer to receive technical support and updates.

The Association of Shareware Professionals put the business, largely domestic, between $10 and $20 million annually—even with only an estimated 10 percent of customers paying to register a shareware title. Forbes magazine marveled at the trend, writing in 1988 that “if this doesn’t sound like a very sound way to build a business, think again.” Shareware, it argued, relied not on expensive advertising but on word of mouth or, as one practitioner put it, “word of disk.” Robert Wallace, a top programmer at Microsoft, turned a shareware program of his called PC-Write into a multimillion-dollar empire. Most authors, however, were happy to break six figures and often made little more than $25,000 per year. Selling a thousand copies of a title in one year was a great success. Shareware was still a radical conceit, one that, furthermore, had been used only for utility programs, like check-balancing programs and word-processing wares. [Shareware] had never been exploited for games.

Does anyone even remember what shareware is? What is the equivalent to shareware today? Distributing software yourself on the Internet? Sort of. I’d say it’s more analogous to the various app stores: Google Play, Apple App Store, Windows Store. Going directly to the users. But they found shareware games didn’t work, at least initially:

When it came time to distribute the games, Scott took a long, hard look at the shareware market. He liked what he saw: the fact that he could run everything himself without having to deal with retailers or publishers. So he followed suit, putting out two text-based games in their entirety and waiting for the cash to roll in. But the cash didn’t roll; it didn’t even trickle. Gamers, he realized, might be a different breed from those consumers who actually paid for utility shareware. They were more apt simply to take what they could get for free. Scott did some research and realized he wasn’t alone; other programmers who had released games in their entirety as shareware were broke too. People may be honest, he thought, but they’re also generally lazy. They need an incentive.

Then he got an idea. Instead of giving away the entire game, why not give out only the first portion, then make the player buy the rest of the game directly from him? No one had tried it before, but there was no reason it couldn’t work. The games Scott was making were perfectly suited to such a plan because they were broken up into short episodes or “levels” of play. He could simply put out, say, fifteen levels of a game, then tell players that if they sent him a check he would send them the remaining thirty.

You know how game companies spent the last 5 years figuring out that free games with 100% in-app purchases are the optimum (and maybe, only) business model for games today? The guys at id had figured that all out twenty seven years ago. Those sounds you hear in the distance are a little bit of history repeating.

Id Software was more than a unique business model that gave almost all the power to the programmers. It was the explosive combination of shareware delivery with a particular genius programmer inventing new techniques for PC games that nobody had seen before: John Carmack. It may sound prosaic and banal now, but smooth scrolling platforming, texture mapped walls, lighting models, and high speed software 3D rendering on a PC were all virtually unheard of at the time Carmack created the engines that made them commonplace.

Carmack_Headshot_PR_660

Carmack, like Abrash, is a legend in programming circles, and for good reason. The stories in this book about him are, frankly, a little scary. His devotion to the machine borders on fanatical; he regularly worked 80 hour weeks and he’d take “vacations” where it was just him and a computer alone in a hotel room for a whole week – just for fun, to relax. His output is herculean. But he also realizes that all his hard work is made possible by a long line of other programmers who came before him.

Al had never seen a side scrolling like this for the PC. “Wow,” he told Carmack, “you should patent this technology.

Carmack turned red. “If you ever ask me to patent anything,” he snapped, “I’ll quit.” Al assumed Carmack was trying to protect his own financial interests, but in reality he had struck what was growing into an increasingly raw nerve for the young, idealistic programmer. It was one of the few things that could truly make him angry. It was ingrained in his bones since his first reading of the Hacker Ethic. All of science and technology and culture and learning and academics is built upon using the work that others have done before, Carmack thought. But to take a patenting approach and say it’s like, well, this idea is my idea, you cannot extend this idea in any way, because I own this idea—it just seems so fundamentally wrong. Patents were jeopardizing the very thing that was central to his life: writing code to solve problems. If the world became a place in which he couldn’t solve a problem without infringing on someone’s patents, he would be very unhappy living there.

In that spirit, Carmack regularly releases his old engines under GPL for other programmers to learn from. Don’t miss Fabien Sanglard’s epic deconstruction of the Doom 3 codebase, for example. That’s only one iteration behind the current id engine which was used for Rage and (apparently) will be used for the upcoming Doom 4.

One of my very favorite quotes of all time comes at the end of the book.

Carmack disdained talk of highfalutin things like legacies but when pressed would allow at least one thought on his own. “In the information age, the barriers just aren’t there,” he said. “The barriers are self-imposed. If you want to set off and go develop some grand new thing, you don’t need millions of dollars of capitalization. You need enough pizza and Diet Coke to stick in your refrigerator, a cheap PC to work on, and the dedication to go through with it. We slept on floors. We waded across rivers.”

And indeed they did, as the book will attest. Both @ID_AA_Carmack and @romero are still lifelong, influential, inspiring members of the game and programming communities. They are here for the long haul because they love this stuff and always have.

The ultimate point of Masters of Doom is that today you no longer need to be as brilliant as John Carmack to achieve success, and John Carmack himself will be the first to tell you that. Where John was sitting in a cubicle by himself in Mesquite, Texas for 80 hours a week painstakingly inventing all this stuff from first principles, on hardware that was barely capable, you have a supercomputer in your pocket, another supercomputer on your desk, and two dozen open source frameworks and libraries that can do 90% of the work for you. You have GitHub, Wikipedia, Stack Overflow, and the whole of the Internet.

All you have to do is get off your butt and use them.

[advertisement] Hiring developers? Post your open positions with Stack Overflow Careers and reach over 20MM awesome devs already on Stack Overflow. Create your satisfaction-guaranteed job listing today!

Continue reading

Posted in Syndicated | Comments Off on You Don't Need Millions of Dollars

Too Many Parameters in Java Methods, Part 5: Method Naming

In my previous post (Part 4 of my series on dealing with too many parameters in Java methods), I looked at method overloading as one approach to providing clients with versions of methods or constructors requiring fewer parameters. I described some dis… Continue reading

Posted in Java (General), Syndicated | Comments Off on Too Many Parameters in Java Methods, Part 5: Method Naming