A Spring Container In The Real World

Ala JavaSpecialists’ newsletter, this post comes to you from the beautiful Kuils River region of greater Cape Town, also known as the Kuils Riviera. Here you are reminded that to some “life is not a beach”, in particular when passing by the local township where dismal poverty and a hand to mouth existance reigns.

On that note, lets dive straight into the subject matter of this post, performing the most basic validation in your Spring beans to quickly detect stupid mistakes.

Now, as a Spring user you have a number of options when it comes to configuring dependencies you wish to have injected into a given bean. You can use autowiring, which itself has further options, such as autowiring by type or name, or you can use xml configuration with explicit bean references. Regardless of what you use, it pays to use the Spring container’s initialization callback mechanism to avoid or easily detect basic mistakes that can easily eat up hours of development time. This entails validating your dependencies, at the very least in terms of whether they are null or not, in a consistent fashion in any given project.

Lets first get onto an example of such a basic mistake, in which a suspected wiring configuration error, which turned out to be a programmer error, cost precious time, and then move onto what do to, consistently, to avoid future similar wasteage.

BEFORE

Herewith a class under test, note the @Autowired bean propertyService.

public class ConfigServiceImpl implements ConfigService {

    @Autowired
    @Qualifier("propertyServiceBean")
    protected PropertyService propertyService;

    // NO INIT METHOD

...
}

Here is the stupid mistake.

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = {"/com/mayloom/activiti/config/spring-context.xml"})
public class ConfigServiceTest {

   @Autowired
   private ConfigService configService;

   @Test
   public void updateConfiguration() {

      ConfigService configService = new ConfigServiceImpl(); // This line must be removed

      Properties props = configService.getProperties();

The mistake is the programmer is autowiring the configService yet also instatiating it. The latter renders Autowiring of dependencies in configService as useless, the entire line must be removed. It could be that this was a class that was later turned into a Spring bean, so just an oversight.

This the the result of the mistake, or at least a snippet of the surefire report showing the offending NullPointerException.

-------------------------------------------------------------------------------
Test set: com.mayloom.config.ConfigServiceTest
-------------------------------------------------------------------------------
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.282 sec <<< FAILURE!
updateConfiguration(com.mayloom.config.ConfigServiceTest)  Time elapsed: 0.266 sec  <<< ERROR!
java.lang.NullPointerException
	at com.mayloom.config.ConfigServiceImpl.getProperties(ConfigServiceImpl.java:72)

Now, if you had been making various Spring configuration changes in your project, and you see the above, one could start thinking that a wiring configuration error is the cause and waste hours reconfiguring and basically looking in the wrong place, even though the mistake made is quite obvious to us now.

AFTER

To quickly rule out wiring errors as a cause, in this case, and in general, all one has to do is to check that wired dependencies are not null as shown in the Default initialization and destroy methods section of the Spring manual.

So, we would end up with the pertitent section of our spring configuration looking as as shown below, with the default-init-method being what we want to include.

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:context="http://www.springframework.org/schema/context"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
           http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
           http://www.springframework.org/schema/context
		   http://www.springframework.org/schema/context/spring-context-3.0.xsd" default-init-method="init">

Next, we’ll update ConfigServiceImpl as shown below.

public class ConfigServiceImpl implements ConfigService {
	
  @Autowired
  @Qualifier("propertyServiceBean")
  protected PropertyService propertyService;
	
  // this is (unsurprisingly) the initialization callback method
  public void init() {
    	log.info("==================== ConfigServiceImpl =========================");
        if (this.propertyService == null) {
            throw new IllegalStateException("The [propertyService] property must be set.");
        }
    }

Thats pretty much it, no advanced concurrency lesson here, no generics to marvel at, but it may save you time.

Brute Force Fix

To get onto the fix first. All I needed to do was to configure the nproc settings for the user in question (it happened to be jenkins) upwards in /etc/security/limits.conf

Playing

Before getting onto the most obvious fix, I went off on a tangent and refreshed my memory on the effects of the heap size, permanent generation size, thread stack  size and other related topics (the bash based thread count script is a work in progress). A simple program to help you determine how many threads you can create can be found below if you are also keen on experimentation.

public class RunOutOfMemory {
	
/**
* Results
* 
* ==== Environment: 32bit Win 7, 2GB RAM, Java 7 ====
* 
* Reducing the default maximum thread stack size allows more of the process' virtual 
* memory address space to be used by the Java heap and vice-versa.
* 
* Note, when it comes to virtual memory usage consumed by the jvm process, we are 
* not including the heap and permanent generation allocation.
* 
* Test: 1. ALL VM arguments at default values: OutOfMemory with 3974 threads = 
*                                                       1238 MB (320k / thread)
* 	2. -Xss1m, rest VM arguments at default values: OutOfMemory with 1211 threads 
*                                                                           = 1211 MB  
* 	3. -Xss2m, rest VM arguments at default values: OutOfMemory with 533 threads 
*                                                                           = 1066 MB
*       4. -Xss128k, rest VM arguments at default values: OutOfMemory with 10358 threads 
*                                                                           = 1294 MB
* 
* "On Windows, the default thread stack size is read from the binary (java.exe). As of 
* Java SE 6, this value is 320k in the 32-bit VM and 1024k in the 64-bit VM." oracle.com
* 
* ==== Linux ====
* 
* NOTE: Pay close attention to your limits configured in /etc/security/limits.conf You 
* may want to adjust the nproc setting for your process upwards if you are seeing a 
* "cannot create native thread" message
*/
		public static void main(String[] pArgs) {

			try {
				// keep spawning new threads forever
				while (true) {
					// thread begins execution, JVM calls run method of this new thread
					new TestThread().start();
				}
			} catch (java.lang.OutOfMemoryError e ) {
    	  
				// when out of memory error is reached, print out the number of
				// successful threads spawned and exit
				System.out.println(TestThread.CREATE_COUNT);
				System.exit(-1);
			}
		}

		
		static class TestThread extends Thread {
			
			private static int CREATE_COUNT = 0;
			
			public TestThread() {
				CREATE_COUNT++;
			}
			
			// make the thread wait for eternity after being spawned
			public void run() {
				this.suspend();
			}
		}
}

I came across the Vaio Y Series in the aftermath of a botched laptop upgrade. It all started in an effort to enhance the battery life of the old chunky beast, without too much thought I  recently went out and bought a 64GB Kingston SSDNow V100, downloaded the freshly released Ubuntu 11.11 ISO and went to work. Sadly the laptop was in such a sad state that it didn’t work out, so I went out and bought a 32 bit Sony Vaio Y Series laptop (VPCYB35AG) which  had fairly decent reviews in terms of battery life, and I absolutely loved the size and 11.6 inch HD screen.

I started by backing up the Windows 7 Starter edition OS onto a 16GB flash drive, and then swapped drives, the reason for the backup to flash drive, in addition to the OS already on the 320GB drive that came with the laptop, was incase there wasn’t sufficient driver support for the Vaio and I had to use Windows 7. I wanted to avoid the latter since I don’t regard Windows as a suitable development environment for server-side development, which is what I specialize in. Kudos to Sony when it comes to their recovery process, I tested Windows 7 recovery on the SSD, just to be sure that it would work, and it was all effortless.

In any case, having tested the laptop without linux, I got round to creating a bootable Fedora 16 USB key and installed onto the SDD. The first attempt failed, I do not know why, so I just repeated the process. Second time round it worked just fine.

The first challenge was getting used to Gnome 3 and also inconsistent boot behaviour that may be related to the next generation InsydeH20 UEFI BIOS and GRUB2. On the inconsistent boot behaviour, that may have been caused by me leaving on the “boot from external device” option in InsydeH20, I am uncertain. With regards to Gnome 3, so far I’m just getting used to it, and I like it, in any case, I am not too concerned with such details right now, its driver support that I’m concerned with, I just want the laptop to work in terms of the basics. Overall, right now I’d say I’m enjoying the experience, and given that all I’ve done to date is to “yum update”, the existing driver support is sufficient to get to work. So I’m generally happy. I’ll update this post in a couple of weeks time, once the laptop has seen more use.

Update 28 Nov 2011

Installed the latest official ATI Catalyst driver (11.11), and Gnome 3 immediately reverted to “fallback mode”, which in terms of usability seems a fairly serious regression. Rather the vent online, contacted AMD via their web form for support, this is the request:

Hi there,

I have purchased a Sony Vaio VPCYB35AG with an AMD E-450 APU (by the way your web form only gives an option for the E-350) and installed Fedora 16 with comes with Gnome 3.

I then installed the Catalyst ATI driver (ati-driver-installer-11-11-x86.x86_64.run). Rather than improving matters, it made it worse and so I researched what might be going wrong.

In any case, as far as I can tell (please see http://ati.cchtml.com/show_bug.cgi?id=99), AMD is aware of a Graphical corruption issues pertaining to the gnome-shell, but has not done anything about it.

Please can you let me know whether AMD is attending to this issue. I am sure there are thousands of affected linux users.

Regards,
Nico

As a parting comment, I wish I could just pay Sony, or whoever else, to give me a glitch free system. In any case, lets see what AMD says.

Update 3 Dec 2011

Given that I had little confidence in getting a satisfactory response from AMD, I reloaded Windows 7 and have been using it for the last few days. I’m now back to 4.5 hours battery life, instead of the 2.5 on Fedora 16. So, this brings, sadly, an end to my attempt to get any linux distribution going on my Vaio.

I did receive the following response from AMD 2 Dec 2011, which does not inspire confidence, as it does not help me. I would have been willing to pay for a working driver.

We do not officially support GNOME3, since none of our supported distributions use it by default. Unbuntu 11.10 is the first one to ship with this product, but it does not use Gnome3 by default.

Our OpenGL team is currently aware of the issue, plans may be in place to support it later on but there is no official word as of yet.

 a naive belief in the emancipatory nature of online communication that rests on a stubborn refusal to acknowledge its downside

and Internet-centrism

a philosophy of action that informs how decisions, including those that deal with democracy promotion, are made and how long-term strategies are crafted.

Even if you have no interest in liberating the world and promoting democratization, Morozov’s concepts of cyber-utopianism and Internet-centrism are equally applicable to business and personal dealings and worth reading for this reason alone. In addition, Morozov raises valid concerns regarding the dominance and power of US service providers, especially since they are not immune to US government interference and can act with impunity when it comes to a large portion of the worlds population’s sensitive personal data.

Finally, Morozov warns against the “digital visionaries” that are seemingly ever present nowadays in all spheres of life, with entire consultancies based on, and by definition biased towards, the virtues of tweeting, Facebooking and advertising online. Such online social visionaries bring back memories of the Dot-com bubble, except this time its the Dot-social bubble. A memorable quote in this regard:

..most digital visionaries see the Web as a Swiss army knife ready for any job at hand. They rarely alert us to the information black-holes creates by the Internet, from the sprawling surveillance apparatus facilitated by the public nature of social neworking to the persistence of myth making and propaganda, which is much easier to produce and distribute in a world where every fringe movement blogs, tweets, and Facebooks.

Personally, I would give the book 9/10 and recommend it as a worthy read along-side with Naomi Klein’s The Shock Doctrine and No Logo.

This post consists of a briefly outlined set of Java Exception rules, or best practices, with an accompanying look at rule compliance using specific transient network and database layer Exceptions.

The rules are based on the relevant rules from Joshua Bloch’s lauded and highly recommended Effective Java, 2nd Edition. Bloch is arguably the authority on the subject, and his legacy includes being listed as author of the Sun JDK Throwable implementation (see @author in the source code).

RULE BOOK

The author has violated these rules hundreds if not thousands of times over the last decade. As a mitigating factor it can be argued that the rules in themselves represent exception utopia, and so, it is highly unlikely that they will all be consistently followed in any given code base, or put differently, that even with the best of intentions any software engineer will follow all of them due to say project timeline pressures.

Such pressure may however be a symptom of not asserting one’s own standards when a unit of work or project commences, to alleviate pressure one can always clearly communicate one’s own non negotiable engineering standards at the start of a project.

Rule 1: Never use exceptions for ordinary control flow

import java.util.ArrayList;
import java.util.Iterator;

/**
* Do not, use Exceptions for flow control, this is an example of what not to do.
*
* @author nico
*/
public class DontUseExceptionsForFlowControl {

 public static void main(String[] args) {

   ArrayList list = new ArrayList();

   list.add("hello world");

   // Let's to the wrong thing, and jump out of this loop with an iterator related
   // Exception...

   Iterator iter = list.iterator();

   while(true) {

     try {

       System.out.println(iter.next());

     } catch (java.util.NoSuchElementException e) {

        // Using Exception for flow control, so can safely ignore this one.
        // TODO Stop using Exceptions for flow control.
     }

   }

  }

}

Using Exceptions for ordinary control flow violates the Principle of Least Astonishment which states “the result of performing some operation should be obvious, consistent, and predictable, based upon the name of the operation and other clues”.

Rule 2: Never write APIs that force others to use Exceptions for ordinary control flow

/**
* Database layer API, implementation detail agnostic.
*/
public interface EmailDatabaseHelper {

 // TODO refactor, this forces the user to catch checked exception EmailDoesNotExistException, with an email
 // address not existing being in no way exceptional, and hence in ordinary control flow
 public void doesEmailExist(String email) throws EmailDoesNotExistException;
}

Rule 3: Use runtime exceptions for programmer errors and checked exceptions where recovery is possible

Note that this rule does not state, as you may expect, that you must use unchecked exceptions for programmer errors, since that casts too wide a net. Unchecked throwables include runtime exceptions and errors, with the latter conventionally reserved for JVM error reporting under conditions where continued execution is impossible.

Rule 4: When uncertain as to whether a condition is recoverable or not, use an unchecked exception

The reasoning behind this is simple, if you do not know how an API user will recover from the checked exception, do not place the burden on the API user in terms of trying to figure out how, and potentially wasting time concluding that its not possible.

Rule 5: Only use checked exceptions if the API user can take action to recover from the said exception

If the only course of action, that you could take, when confronted with your own checked exception, is a variation of the below example then chances are good that you should not be using a checked exception. The checked exception adds no value, so, either attempt to refactor as per Rule 6, or use an unchecked exception.

} catch (CheckedExceptionWithNoUsefulActionPossible e) {
  logger.error("an error occurred");
  e.printStackTrace();
  System.exit(1); // or stopping the current thread
}

Rule 6: Refactor, where possible, checked exceptions that violate rule 5 into a state-checking method and unchecked exception

Before.

try {
  ball.kick(HARD);
} catch (BallCannotBeKickedException e) {
  // recover from exceptional conditions
}

After. State-checking method and unchecked exception has been introduced.

// ball will not be accessed concurrently, and so the calling sequence is safe
if (ball.isKickeable()) {
  ball.kick(HARD);
} else {
  // recover from exceptional condition
}

Rule 7: Clearly document if the unrecoverability of an unchecked exception is likely to be transient in nature

Certain conditions are unrecoverable at a particular instant but not permanently, and a prime example is an exception related to a lock being held on a database table on which say an update is being attempted. Methods that throw unchecked exceptions where the exception relates to a condition that may be transient in nature should document this fact, that is that the condition may be transient, and suggest a retry in the Javadoc comment associated with the unchecked exception.

Rule 8: Use the standard Java platform library unchecked exceptions where appropriate, do not re-invent the wheel

Reuse the standard Java platform library unchecked exceptions whereever possible, whilst honouring their documented semantics. A prime example is IllegalArgumentException. See the subclasses of RuntimeException for further candidates.

Rule 9: When dealing with lower-level exceptions inappropriate to the higher-level abstraction, perform either exception translation or exception chaining

Exception translation.

try {
     // lower level method invocation e.g. JPA call
} catch(LowerLevelMethodInvocationException e) {
     // now translate the lower level exception into an exception that matches
     // the higher level abstraction in our current context
     throw new HigherLevelException(...);
}

Exception chaining with chaining-aware contructor.

class HigherLevelAbstractionException extends Exception {
    HigherLevelAbstractionException(Throwable cause) {
         super(cause);
    }
}
try {
     // lower level method invocation e.g. JPA call
} catch(LowerLevelMethodInvocationException e) {
     // now translate the lower level exception into an exception that matches
     // the higher level abstraction in our current context
     throw new HigherLevelAbstractionException(e); // use chaining-aware constructor
}

Rule 10: You MUST document all exceptions, checked and unchecked, thrown by your methods

Excuse the all-caps and repetition will all exceptions being defined, but proper documentation is in no way negotiable and is every software engineers professional responsibility. The Javadoc @throws tag must be used to document both checked and unchecked exceptions in terms of the conditions under which they will be thrown. The only difference between checked and unchecked exceptions is that you must only define checked exceptions with the throws keyword, do not include unchecked exceptions here.

Rule 11: Force including the values of all parameters and fields that comprise the cause of an exception in its detail message

Support personnel or fellow programmers, when faced with a stack trace in say a log file, require pertinent data in order to ascertain exactly what caused an exception. Without the values of all parameters and fields that comprised the exception, it may be impossible to reproduce an exception.

In terms of forcing including pertinent parameter and field data in the detail message of exception, simply do not provide a constructor that has a string parameter as detail message, rather force the user to specify the said data in the constructor.

Consider the following checked exception, which has accessor methods since as per Rule 5 such exceptions should be used for recoverable exceptions.

/**
* @author Nico
*/
public class ServiceOperationException extends Exception {

private String suppliedApiKey;

/**
* Construct an ServiceOperationException.
*
* @param suppliedApiKey    the API key supplied to the service user upon successful registration
*/
public ServiceOperationException(String suppliedApiKey) {

// detail message
super("Supplied API Key: " + suppliedApiKey);

// capture for recovery purposes
this.suppliedApiKey = suppliedApiKey;
}

public String getSuppliedApiKey() {
return suppliedApiKey;
}

public void setSuppliedApiKey(String suppliedApiKey) {
this.suppliedApiKey = suppliedApiKey;
}
}

Rule 12: Ensure that your methods are failure atomic and if not document this fact in your API

Methods that are failure atomic leave an object in the state it was prior to the method invocation in the event of failure. Either ensure parameters have their validity checked before proceeding to to the actual work (and modification) in a method invoked on a mutable object, or ensure the relevant class is modified to be immutable.

Rule 13: Never ignore exceptions

From time to time you may see empty catch blocks, and in the worst case, catch blocks that catch java.lang.Exception (as listed in Tim McCune’s Exception-Handling Antipatterns) or java.lang.Throwable. This is a cardinal sin, and should never be done. At the very least, the exception should be logged (that is the entire stack trace should be logged) with an appropriate log level. In some cases, it may be justifiable to take no action, but in such cases, comments must justify why no action is taken.

RULE COMPLIANCE – RECOVERABLE TRANSIENT CONDITIONS

Some exceptions are associated with conditions that are possibly but not necessarily transient in nature, and so, when faced with them, the appropriate course of action is to automatically retry the operation. The Spring Batch Retry mechanism is geared for exactly such exceptions.

In terms of the rules, Rule 3, 4, 5, 6 and 7 are applicable, given our definition of the conditions being transient, but not with absolute certainty. In other words, given the lack of certainty as to whether the condition is recoverable, an unchecked exception should be used, as per Rule 3, 4 and Rule 5. If we choose not adhere to this rule, and feel the condition is indeed recoverable, and use a checked exception, as per Rule 5, then as per Rule 6 one should refactor into an unchecked exception with an accompanying state-checking method.

So, in short, we should use:

• unchecked exception (if uncertain if recoverable) or if unrecoverability is a certainty

• checked exception if recoverable

• even better, unchecked exception with a state-checking method if recoverable

Database Layer

Consider the following exceptions, that one may see with a Spring / JPA / Hibernate stack:

1. UnexpectedRollbackException (Spring)
2. OptimisticLockException (JPA)
3. LockAcquisitionException (Hibernate)

The decision to make all of these unchecked exceptions complies with the rules, given that within the context of a single transaction, the underlying condition is not recoverable. Within the context of retries, and so multiple transactions, the condition may indeed be recoverable due to the transient nature of the underlying conditions (a lock on a table will most likely not be permanently held). So, methods that throw these exceptions should firstly document that they throw these exceptions with @throws Javasdoc (as per Rule 10) and then also document the fact that the user may wish to attempt retries (as per Rule 7).

Network Layer

Another example of an exception that may point to a transient condition is a SocketException, especially when considering its subclasses, BindException, ConnectException, NoRouteToHostException and PortUnreachableException. These exceptions are all checked exceptions, and this is incorrect since at the instant an associated method was called, recovery would not necessarily be possible, that is, recovery is not a certainty, so Rule 3 is violated. Rather, as per Rule 4, the exceptions should be unchecked and the transient nature of the exceptions should be documented as per Rule 7.

Key References

1. Chapter 9 of Joshua Bloch’s (the author of java.lang.Throwable) Effective Java, Second Edition. If you don’t own a copy, buy one, you won’t regret it.
2. Tim McCune’s Exception-Handling Antipatterns

When using the static Java code analysis tool PMD, one of the basic rules that you can violate is the empty if statement rule, which has a critical severity level by default. Why is there such a rule in the first place and is the critical severity level warranted? As an avid user, or abuser in terms of PMD, of empty if statements, with no clear answer, I went and trawled the web for answers.

To start off with, PMD does offer the following advise, in the Best Practices page

Generally, pick the ones you like, and ignore or suppress the warnings you don’t like. It’s just a tool.

In the context of the subject matter of this post, that may be a hint to buy the official book, PMD Applied, which is fair enough. In any case, lets get onto the first obvious example of why the rule is warranted and motivate why it should be a critical violation:

if (firstCode != null && firstCode.getCode() != null && firstCode.getCode().equals("101")) {
    doSomething();
} else {
    // TODO: process code "102"
}

Another version of the above is of course the version without the TODO comment:

if (firstCode != null && firstCode.getCode() != null && firstCode.getCode().equals("101")) {
    doSomething();
} else {

}

Both cases are clear problem areas, as the code is blatantly incomplete, and if your unit tests don’t pick it up, you certainly want your static code analyzer doing so. But what about the following:

if (firstCode != null && firstCode.getCode() != null && firstCode.getCode().equals("101")) {
    doSomething();
} else {
    // only supporting 101 in this release, 102 onwards to follow
}

In this example, some value is being added in terms of comments, and I have regularly been taking this approach, until PMD forced me to think about it. I took the approach in part because from what I can remember from compiler implementation theory any given compiler, such as a Java byte code compiler, would be clever enough to detect and remove the dead code.

As it turns out, from some limited research, this is not necessarily the case, since if it was, then shrinking tools such as ProGuard would surely not list “Remove unnecessary branches” as a byte code optimisation feature.

I managed to find very few opinions on this online, although the following was of interest. In the end, I have concluded that the gain provided in the documentation in the final example, does not add sufficient value to justify the risk of not completing a branch,  and also, it bloat the code base. So, I have resolved to do away with the practise and moving such comments either above the if statement or into the javadoc where appropriate.

Measurable Engineering Excellence Should Matter To Your Product Owner - Not Simplistic Perceptions of Hard Work

In a software project,  the product owner is responsible for representing the interests of stakeholders and the business. The importance of this role cannot be overstated, since put in a more matter of fact way, the product owner is responsible for the success of the product. In this post, key candidate measurement criteria, garnered from the experiences of the author, are presented. These will help you avoid the nightmare scenario where vasts sums are paid devoid of any prior measures whatsoever, with purely subjective motivations such as “the guys have been working really hard” or “I have seen the user interface demo“.

Before proceeding to the key measurement criteria, we briefly address who the product owner may be and what the interests of the stakeholders and business may be.

Who Is The Product Owner?

The product owner, an individual, can either literally be the product owner or an appointed agent in a software development project using, as an example, a Scrum management framework. In a small to medium sized enterprise, the product owner may be an individual that has additional responsibilities, and in a startup, it is likely that a founder takes on the role, in which case, it would be investors that would in effect be ‘hiring’ their product owner.

Regardless of the structuring in the enterprise, as with any, if the individual with the responsibility is not held accountable for failure, or on the flip side sufficiently rewarded for success, then in the absence of extreme luck, you are doomed, if not in the short run, then most probably in the long run. Naturally, with accountability comes authority, and likewise, if your product owner does not have sufficient authority, formally, then in the absence of extreme luck…

What Are The Interests Of The StakeHolders and Business?

The interests of stakeholders and the business are naturally variable, but we can at the very least presume that the business has a short term or long term goal of profitability. In other words, the success of the product can generally be measured at the very least in terms of growth in profitability. It is worth noting, and this is by no means piercing insight, that without formal project parameters presented as directives by the stakeholders and the business, in the absence of extreme luck…

Key Measurement Criteria

The following criteria are in no way negotiable, and admittedly, the first, and most important, is difficult to measure.

1. Passion For Both Software Engineering and Your Business Domain

Although passion is subjective, there are ways to measure at the very least interest levels when it comes to both software engineering and your business domain. In a general sense, a person without passion, especially in a key position, is likely to demotivate the rest of the team.

2. Commercial Software Development Experience

Elementary Filtering

If the candidate does not have any commercial experience whatsoever, not matter how good they look, whether on paper, physically or in terms of reputation, by hiring them into this key senior position you are taking a risk that is not worth taking. It may be repetitive, but again, if the candidate matches either of the following, do not hire them as your software product owner:

• No commercial experience whatsoever – please note that working at a foundation or not for profit organization does not count as commercial experience.
• No commercial software development experience – please note that university projects simply do not count, and again, developing software at a foundation or not for profit organization does not count as commercial experience.

Secondary Filtering

The candidate should ideally have software engineering experience in an environment with mature software engineering processes, and in the first instance, the candidate should have some feel for what immature and mature processes are. It should be remembered that the product owner must look after the interests of all stakeholders, and if for example quality and ease of maintenance is an objective, you do not want an individual who has no idea how to measure the many different facets of software quality, and in the worst case, motivates for or authorises the payment for a project based on a variation of how hard he/she believes the team has worked or a simple user interface demonstration.

Although the following set of concepts are by no means all-encompassing, the candidate should understand and have at least some knowledge of:

• Either explicitly, or in principle, Capability Maturity Model Integration (CMMI)
• Technical debt [1][2] and the measurement thereof
• Continuous integration
• Usability measures
• Various sofware development methodologies and their strengths and weaknesses

You will notice that there is a focus on measures above, and this is key. Software development can very quickly degrade into a subjective discipline if left devoid of measures of success, and an entirely subjective process is not engineering, its flying by the seat of your pants. In short, there is simply no way a product owner can do their job without a strong software engineering background.

3. Suitable Personality Traits

Meticulous And Streetwise Leader With Some Charisma

You are unlikely to see this as a bullet point in a job specification requirement as it sounds a bit ridiculous, so lets cull the ‘Some Charisma’ requirement, and we are left with ‘meticulous, streetwise leader’. It still doesn’t sound kosher enough, but lets get to the semantics regardless. When it comes to the leader portion, you can look at the candidates CV for a past history in this regard. So we are left with the meticulous and streetwise requirements. When we say streetwise, it again comes down to experience, on the software development and product development streets, if someone tries to pull a fast one (e.g.  try to leave an intellectual property clause out of a contract), your product manager should know the move.

Respectful To Specialist Engineers (And All Stakeholders)

Although the candidate should have a strong software engineering background, over time it is likely that there will be a widening gulf between the expertise of specialist software engineers and the generalist product owner.

You do not want someone who will belittle what they do not understand, and it happens time and time again, especially if the person does not have the required software engineering qualifications and experience to begin with. In the worst case scenario, your product owner will openly show contempt for, and blame failures on, technical team members and in particular developers, rather than investigate the root causes of problems and potential remedies (e.g. seeking the counsel of an independent engineering consultant). In this worst case scenario, your engineers will leave, and the better ones will go first.

Likely To Assume Responsibility For Failure

You want to avoid hiring the type of person who is likely to hide failure and not assume responsibility for it. Here we are entering the murky waters of professional integrity, and the potential for this post to degrade, ad nauseum, into a  lecture on ethics. But on a serious note, how does one avoid hiring the kind of person who is likely to be dishonest, or in a different form, only report on successes, but not known failures in order to protect their own interests?

When it comes to this topic, while one can rely on one’s gut feelings, industrial psyhcologists and psychometrists are best placed to advise. Costs might become a consideration here, but one can apply testing on the short list and the money spent here may be some of the best dollars you have ever spent. Based on our own basic research we have determined that role play exercises, rather than questionairres (e.g. Myers-Briggs) are the best placed tools, but again, it is best that you consult with the experts in this domain.

If you’re a fan of Geocaching, or GPS Cache hunting, then you may also be interested Sightseeking.com that was launched during the course of last week. Rather than hunt for a cache, you try to hunt for the GPS location where the picture was taken.

Personally, I think its a great concept and I’ve given it a whirl by uploading sight #9, now I just hope someone finds it. I ended up having to find the site online myself since I forgot to use the GPS on my phone to tag the location. I used Google Maps to find it and then used the ‘What’s here?’ option on the right-click menu. I’m quite a co-ordinate ignoramus, so was not really sure what to enter in the boxes in Sightseeking.com. In terms of an enhancement to the sight, I would make the default co-ordinate entry format match what is  found on Google maps.

I tried to find one of the sites on the site, and happen to know exactly where it is, but think I got unstuck with the Google Maps presumably decimal co-ordinates to degrees, minutes, seconds convertion. In any case, I’ll try again some time, especially since I’m short on bling and the site is offering an ounce of gold as a lucky draw prize.

The article makes an important point in that providing a highly reliable service is a significantly greater challenge in the FBWA space than in the cellular mobile telephony service (CMTS) space. It does this by reminding the reader that reliability requirements in terms of backhaul links are significantly more stringent in FBWA networks than in CMTS networks, since with the former, backhual link downtime generally results on consumer downtime since one has a single point of failure, whilst in the latter, service degradation is the result, which is generally preferable to having no service at all.

In a nutshell, the article suggests, in my opinion, that you better know what you are doing if you are going to provide a high quality, highly reliable FBWA network. In my mind, if you are operating a commercial prepaid FBWA network, the demands are even greater and potentially commercial WiFi hotspot operations present the greatest challenge if you are serious about your service levels (and if you are not, thankfully in South Africa there is the Consumer Protection Act or the old fashioned way, consumers voting with their feet).

But first a definition, when I say WiFi hotspot I mean in the traditional sense, that is predominantly serving the hospitality industry with the network controlled by hotspot management software (i.e. a basic WiFi router with open access does not qualify). Secondly, when I say operator I mean the company in question largely, but not necessarily exclusively, owns and operates the access points that comprise their network. Lastly, saying that these operators are the most prominent is a bit vague, and so as qualifying criteria I add number of access points being operated by any company as being in the hundreds.

Here is my listing of the my perception of the top four in alpabetical order:

• AlwaysOn
• RedButton
• Skyrove
• Wireless G