Feature's hierarchy of needs

So I watched Gojko's video Reinventing software quality where he talks about a software quality model that is based on Maslow's hierarchy of needs. He says that of course his model is wrong, as all models, but at least it  worked for the given problem context.

For each layer just enough work is invested to reach the next one. So if it is deployable and functionally ok, there is no need to make the deployment faster or redesign the code ... If the system is usable  the next step is to measure its usefulness; is anybody using it? If not, where is the point in maintaining it, etc. The last step is to verify if it is successful in terms of business value.

So, I found that approach very interesting and after reading 'Impact Mapping' I came up with a similar model (which is of course wrong), but just for a single feature.

Before the feature can be developed there needs to be a related business value or goal, the purpose of it's life. The customer formulates a problem he wants to be solved: 'increase sales by 10%' or 'being able to sell bundles'. After that  the feature is developed, is functionally ok, can be deployed, is performant and usable.
I removed 'useful' as in my opinion  for a feature this is part of being successful. However, it is successful if the business goal was reached; 'sale increased by 10%' or if the customer accepted it at the live demo.

You ain't gonna need it

Now it is time for self-actualization, meaning it is now time to invest in it. Within Maslow's pyramid it is possible to desire the next layer even if the current one is just fulfilled to 70%. And that should be the same for our feature. There was no need to have 100% test coverage or to even use TDD (of course it results in better quality, but costs 30% more time). No need  doing exploratory testing for several hours by 3 testers.

We'll get it “right” the third time.

But now as we have the certainty that this feature is worth the effort, we start to redesign it, invest in its quality, secure it etc. so we can decrease later maintenance costs. The last step is done if the defined quality level is reached and non functional requirements are met.

So, my point is, if there is a lot of uncertainty (there mostly is) get the feature out as fast as possible, to learn and to know if the feature is worth the effort and especially the money. If this is the case, invest in it immediately to reduce ongoing maintenance costs.

Assert Better Quality

In 1999, Andrew Hunt and David Thomas already suggested in "The Pragmatic Programmer" to Design with Contracts (TIP31) and to  use assertions (TIP33). They write about the benefits like concrete behavior  documentation or crashing early (TIP32). Furthermore, you tend to think more about the behavior itself and how you want to handle exceptions and failures.

In 2009, Janie Chang  found a relationship between Software Quality and assertions by conduct an empirical study on two Microsoft internal Software Components.

"The team observed a definite negative correlation: more assertions and code verifications means fewer bugs. Looking behind the straight statistical evidence, they also found a contextual variable: experience. Software engineers who were able to make productive use of assertions in their code base tended to be well-trained and experienced, a factor that contributed to the end results."

 So, time to take a look at the possibilities in Java :)

Assertions
Java has the reserved keyword assert  that can be used like

assert Expression1 ;
or
assert Expression1 : Expression2 ; 

The first expressions must result in a Boolean value, whereas the second  is used to specify the error message and must therefore return a value. Assertions are not enabled by default and must be activated using the JVM parameter -ea. Check the following code snippet for a concrete example:

public void doSomt(Integer i){
    assert i != null;
    assert i > 3 : "The first argument must be > 3";
}

A disadvantages of the Java assertions when enabled is the impact  on performance. However, in The Pragmatic Programmer it is suggested to leave the assertions turned on and remove only those assertions that really have an impact.
Furthermore, the possibility to turn them on or off can also be a disadvantage. If you are the only one in your team using assertions and other environments like daily or testing machines do not have assertions turned on, there is no benefit in using them.
Additionally, extra documentation is needed to carry these internal defined constraints to the outside world, e.g. interface method documentation.

Google Guava Preconditions
The guava-libraries include a class called Preconditions. It can be used to verify parameters in an easy and convenient way:

public void doSomt(Integer i) {
    checkArgument(checkNotNull(i) > 3,
                 "The first argument must be > 3");
}

If a constraint is a violated an standard RuntimeException is thrown: IllegalState, Nullpointer, IllegalArgument or IndexOutOfBounds. Therefore, the caller must be informed about these rules using documentation or tests. Thereby, the caller becomes responsible for passing the appropriate data (but not as strict as in Designing with Contracts).

 
So the question is how and when to use what!?

I think, a combination of both is more valuable than using just one subset. Use a library like guava-Preconditions or create your own classes for validating parameters. Add some documentation about the constraints and back them up with lots of unit tests.
Assertions on the other hand can be used for verifying internal states and post conditions, e.g. verifying that the last element is the lowest when the sorting algorithm is finished. During the local development phase assertions can be turned on and will definitely help to improve code quality.
The valuable part about it, is that you start thinking in more detail about the behavior and invalid states. Furthermore, you will save time as the program is going to crash early, meaning that you do not have to go through long stack traces just to find the real root cause.

In another entry I  will also write about Design by Contract and present some Java implementations.