Archive for February, 2004

YAGNI is not just stupid, it's arrogant

The thread of discussion started by Mike Spille’s comments on Rob Martin’s entry got me thinking.

"You Aren’t Gonna Need It" is not only a stupid statement, it’s also incredibly arrogant.  It takes some guts to listen to a suggestion and without even thinking about it, trying to understand what motivated it or even, heaven forbid, doing some research, retort "You aren’t gonna need it".

If my past experiences have taught me anything about the evolution of software, it’s "It Ain’t Predictible", or IAP (I’ve always wanted to dub a three-letter acronym, and it looks like your chances of coining such a term are largely increased if you use street-speak, so here is my contribution).

Seriously, it’s just mind-boggling what users will sometimes do with software you put out there.  They will twist it in forms you would never have imagined in your wildest dreams, ask for improvements, discover bugs on corner cases you didn’t even think were possible. 

Now that I am reminiscing, I actually remember vividly that about fifteen years ago, I faced this very problem when I was using a C++ library that wouldn’t let me override what I needed.  I just ended up downloading the source and replacing a few "private" with "public".  Little did I know I had just uncovered the IAP principle.

I don’t know, maybe Rob and I have different ways of solving problems, but we certainly have a different view on teaching.  If a student comes to me and shows me a design that I consider superfluous, I am not going to say "You aren’t gonna need it", but more something like "Okay, we could sit down after class and you could give me a few examples where your design will be better suited than the simpler one I recommend, but right now, I would suggest you focus on the task at hand so that you can fulfill the number one task that as a software developer, you will be facing at every step of your whole career:  deliver your code on time."

 

Accessors and DTO's

Rob Martin
wonders
whether Data Transfer Objects (DTO, also known as value objects)
should have accessors or not:

The programmer was aghast. "DTOs are always made with private
variables and getters and setters!" he said. "Why?" I asked.

Rob argues that DTO’s should not have accessors but only public fields, which
should be the only way to access them:

In my view OO programs contain two kinds of entities: Objects and Data
Structures [...] On the other hand there is no good reason to use getters and
setters in a data structure. A data structure is simply a packet of data,
nothing more.

While I agree with him about the distinction between Objects and Data Structures, the point that Rob
is missing is that it is quite common to start with a Data Structure and have it
evolve toward an Object as your code changes over time.  This has happened
to me countless times and the few times where I gave in to the simplicity of
declaring my Data Structures with public fields cost me some time when I had to
change not only the said structure but all the calling code to use accessors and
constructors instead of direct access.

Another reason why you should always use accessors for your DTO’s is that of
uniformity.

When I am trying to get a value from an object, I don’t want
to have to think "mmmh… is Employee a DTO or an Object?  I think it’s a
DTO so I’ll just write employee.firstName…  oops, no, I forgot it’s an
Object now, so I have to use employee.getFirstName()".

Uniformity is crucial. 

I already have enough to think when I
write my code, I don’t want to spend extra time second guessing myself or having to
browse the class I want to use before I can do something as simple as getting a
value.

 

Software engineering versus management

Laurent is upset about a student getting a software engineer degree and then willing to become a manager:

Request from your management that you be assigned to functions which match these choices; to discover those, look around you and spot the people whose job requires that they perform the kind of activity you prefer. You might well not end up in a position called “Project Manager”, but I guarantee that you will be satisfied with your career choices.

I don’t understand why Laurent is so upset and even judgmental about this “tragically misled student”.

If he feels his vocation is into management, then why question his choice? What if a manager came to you and patronized you for being a software engineer, telling you that it’s an inferior position and that you should strive for better?
This sounds very arrogant to me.

What’s more, in certain countries (and France is certainly one of them), management is often the only career path that allows for more growth (both in terms of responsibilities and salary) than the technical field. We are no longer talking vocation here but simple, pragmatic reality, no matter how sad it is.

Il faut de tout pour faire un monde, and I, for one, would really love to have a manager who has a software engineer degree…

To each their own.

Firefox: okay, but…

Like everybody else, I gave Firefox a try and, yes, it’s very nice. Unfortunately, it has a very strong competitor, which is probably the reason why I won’t switch. This competitor is Mozilla.

I have been using Mozilla for quite a while now and I like it a lot. While I like the idea of these various browsers spinning off the main branch, I have to say I’ve been very disappointed by the lack of innovation they typically sport. Firefox might be snappier than Mozilla, but as far as I can tell, it’s pretty much the only added feature. Everything else is just what Mozilla already has but repackaged (different bookmark management, more centralized preferences, etc…).

Actually, it’s even worse than that: Firefox doesn’t even offer 100% of the features that Mozilla has, like for example Ctrl-Return to open a link in a new tab, a feature I didn’t realize I was using that often until I tried Firefox.

Why do so many people bother branching off the Mozilla line if it’s not to offer brand new features?

Getters and setters are here to stay

Getters and setters are
not going away. Deal with it.

Don’t believe what
wannabe pundits and OO purists tell you. At the end of the day, every object becomes a primitive type.

Unfortunately, Java doesn’t have the prettiest way to handle getters and setters, which leads up to a lot of code obfuscation. Granted, we are now very much used to visually identify the pattern:

  private String m_firstName;
  public String getFirstName() {
    return m_firstName;
  }
  public void setFirstName(String fn) {
    m_firstName = fn;
  }

  private Integer m_socialSecurityNumber;
  public Integer getFirstName() {
    return m_socialSecurityNumber;
  }

Note that in the above example, I declared the field right next to its getters and setters, which improves readability and locality, in my opinion, but it’s a technique that is pretty much never used, making it even harder to find which fields are exposed with getters and setters and which ones are stricly part of the private implementation of the class.

Compare this to the terse but to-the-point pseudo-code:

  property String name;
  property readonly Integer socialSecurityNumber;

In order to support the most flexibility for attributes, a language needs to offer the three functionalities. Here is how Ruby, C# and Java address these three problems:

Java Ruby C#
Concise notation for read-write attributes N/A attr_accessor :first_name public string FirstName {
  get; set;
}
Concise notation for read-only attributes N/A attr_reader :first_name public string FirstName { get; }
Full definition of accessors for additional logic public String getFirstName() {
  /* code */
}
public void setFirstName(String s ) {
  /* code */
}
def first_name
  /* code */
end
def first_name=
 /* code */
end
public string FirstName {
  get {/* code */}
  set { /* code */}
}

Note that another important feature supported by both Ruby and C# — but unfortunately not Java — is that of “Universal Access”. Regardless of how you choose to define your properties, they all end up going through the same code line when executed. In other words, you can start by define “attr_accessor first_name” and then later use more complex logic by defining “def first_name=”. In either cases, assigning this attribute will always end up calling the assignment method.

It’s too bad that properties didn’t make it in Tiger.

JUnit pain

JUnit

Why does a TestCase get instantiated as many times as it contains test methods?

Try this:

public class MyTest extends TestCase {

  public MyTest(String name) {
    super(name);
    System.out.println(“Created a MyTest”);
  }

  public void testA() {}

  public void testB() {}
}

and you will see “Created a MyTest” displayed twice.

My initial reaction when I see code that puzzles me is to give the author the
benefit of the doubt, so my first thought was “Maybe they do this to make sure that test methods are independent from each other, that is, a test cannot fail because of a side effect created by another test method”.

Then I realized that this justification was stupid for two reasons:

  • If I want two test methods to be truly independent, I will just put them in two different classes.
  • The setUp() method is called before each test method, thus guaranteeing that the state of the object is restored before each invocation.

The more I thought about it, the more I realized that being able to share some state between test methods, such as a JDBC connection or a parsed XML file, was actually quite useful. The problem is that JUnit
makes this simply impossible:  you have to put this code in setUp() and
therefore, rerun it before every test method.

At this point, and after finding all these deficiencies in JUnit’s design and implementation, I am beginning to think we are once more stuck with a de facto standard that is utterly broken.

Unless someone can explain to me this behavior?

Sublime Lion King

I went to see the
Lion King
Musical
last night, and I was blown away.

The movie was already one of my all-time favorite musicals, mixing the
musical wizardry of Sir Elton John with the powerful eloquence of Tim Rice. 
Adapting this masterpiece to a stage certainly seemed impossible, but this would
be underestimating the talent of Julie Taymor (costumes, and also author of some
of the new songs) and Garth Fagan (choreographer).

It was quite a surprise for me to discover that not only are the new songs
blending perfectly with the original score written by John/Rice, but that they
are beautiful in their own right and contribute in no small measure to the sense
of wonder that you are bound to feel while watching the show unfold.  The
mix of African beats and lyrics with the contemporary talent of these musicians
put The Lion King at the very top of my top all-time best Broadway musicals,
along with Rent.

Even if you are familiar with the movie and the original soundtrack, I
strongly recommend that you listen to the new soundtrack before watching the
show.  There is so much happening on stage at all time that you will miss
out greatly on a lot of background musicals if your ears haven’t been trained to
the new material.

The musical highlights in my eyes are "They live in you" (both the first time
and the magnificent reprise at the end), Stampede, the heart-wrenching "Shadowland",
but above all this, the poignant "Circle of Life", which open and close the show
and never fails to get my heart thumping.  There is also another extremely
emotional and bewildering technical achievement around the end of the show,
which I won’t disclose because it would lessen its impact.

If you are lucky enough to get a chance to see this slice of heaven, don’t
miss it.

 

Java field of dreams

Why do we put Java fields at the top of the class?

Here is a typical example:

public class Employee {
  private String m_firstName;
  private String m_lastName;

  public Employee(String firstName, String lastName) {
  …

From day one, this convention has always struck me as odd and
counter-intuitive, especially coming from a C++ background where developers go
to great lengths to hide private members.

When I read a source code for the first time, I couldn’t care less about the
log instance and resource bundle it uses, or all the private HashMaps needed to
maintain its state.  My attention usually goes immediately to the outline
of the class showing all the public methods, and then to the constructor. 
All the rest is noise to me at this early stage.

Since it has now (sadly) become a standard, I put the Java fields of my
classes at the top, like everyone else, but I still can’t figure out why such a
nonsensical convention happened in the first place.

Any suggestion?

 

Snowboarding

I was snowboarding in Tahoe this past weekend.  Not the best day, but
certainly the first day in the season with some decent powder.  Sugar Bowls
has some great spots for an out-of-bounds escapade.  I took a couple of
pictures with my camera phone which, to my surprise, didn’t turn up too bad.

 

I can’t wait for 2 mega-pixel phones :-)