Joel Test: Applicability in 2014?

I think the Joel Test is still very applicable in 2014, almost 15 years later.  While organizations should be considering doing more than the list states in its brief yes/no questions, the Joel Test serves as a minimum baseline that organizations cannot dismiss or argue with.  Therefore, I don't believe the Joel Test needs updating. 

However, some worthy, relatively recent elaborations on the Joel Test include:

• The Joel Test – Updated for 2010
• The Joel Test updated for 2013

Being a consultant, I find the Joel Test applicable to new projects I join, rather than applying it to an organization.  When leading a project, it is also a good checklist.

Notes on "GTAC 2011: Opening Keynote Address - Test is Dead" presentation

The main message is that there needs to be validation of the product idea up front, rather than getting the product idea wrong and potentially killing a start-up one or two years down the road.  This is not prototyping which can be considered verifying that the underlying technologies should work together but a stage prior to this, using "arts and crafts"-type materials rather than hardware/software. 

The secondary message is that calling yourself a tester, even an automation tester, or "quality assurance person" is detrimental to one's career as these skills are thought of as commodities.  That is, the person is interchangeable with an offshore resource.  Rather QA people should take the role of "righters" or people that make a project "right".  I argue that everyone on a project should be responsible for making a project "right", but from past experience, getting your voice heard can be challenging, especially on more hierarchical teams.  Also inertia is a hard thing to fight. 

You Are not the User

Read Ask "What Would the User Do?" (You Are not the User) last week or so.  My thoughts on the article:

• It is always better to have a prototype, on paper or a digital mockup, of the user interface so that a user can work through it, rather than a verbose "user interface requirements" document
• As developers, although we usually are able to figure out new user interfaces we encounter, we often do the same things novice users do especially when things don't work as expected.  E.g. once we figure out a user interface, we may do the same steps all the time instead of looking for a short-cut.  And sometimes we stick with the same tools or older versions because we find it too much of a learning curve to try new ones

97 Things

Making time to read one article everyday from 97 Things Every Programmer Should Know (book format or online) and write about it the following day or soon after.  Advice I've read so far:

• "Act with Prudence" - one way (not perfect) to keep track of technical debt is to use TODOs in the code.  The text associated with a TODO should be specific enough so that someone else reading it in the context of the code understands what still needs to be done.  
• "Apply Functional Programming Principles" - (a) indeed, as the author Edward Garson states, mis-use of object-oriented programming creates bad designs.  In particular, IMO, the difference between using setters versus parameters to a method is not entirely clear.  The advent of Spring also has popularized the use of setters although Spring can just as easily work with constructors so that when an object is instantiated, its state is correct and it is ready to be used.  My rule of thumb is when in doubt, use parameters to a method to pass arguments, not with setters.  (b) As the author also states, test-driven design also helps to promote better design.  IMO it is because as you write automated test cases, you become a user of your API ("Eating your own dog food" principle), and you begin to understand what makes an API easier/cleaner to program against.  

Re-using your code with Perl modules

Re-use of code, when not copying-and-pasting, is a good thing.  I consider myself beyond a novice Perl programmer.  But since it was never a primary tool at work, I never learned how to develop re-usable Perl modules properly.  Following is a bare-bones implementation of a Perl module.  Note that a module containing a Perl class implementation would not have to use Exporter (nor should it!)

#!/usr/bin/perl
use strict;
use warnings;

package MyPkg;

require Exporter;

our @ISA = qw(Exporter);
our @EXPORT_OK = qw(myfunc);


sub myfunc{ 
 print "bar";
}


1;

In this case, the file containing this code should be named MyPkg.pm, to match the name of the package.  A bare-bones caller of this code could be as simple as:

 

#!/usr/bin/perl
use strict;
use warnings;

use MyPkg qw{myfunc};

myfunc();

Some additional notes:

• In the module, require Exporter; is not always necessary (not yet clear the situation for its necessity)
• If your package is something like MyGroup::MySubGroup, two things to observe:  (1) the name of your .pm file should be MySubGroup.pm and (2) the file should be placed in a subdirectory relative to @INC paths named MyGroup.  For example, if you want to locate your re-usable module togehter with your Perl script, you would put it in a subdirectory of the directory with the Perl script named MyGroup