Stephan Schwab

Software development and farm life

Archive for March 2011

Water is essential for new pasture during dry season

leave a comment »

For the horses we need a new place to stay. So far I had rented pasture but as most subsistence farmers do not invest in any kind of irrigation system, all the available pastures have fallen dry and there is nothing to eat. Where the horses currently stay is a nice place with easy access but we had to cut and carry the food for them.

Now an opportunity to acquire some land has shown up and we used last week to clean some of it to turn it into a new pasture. As everywhere else the land has been fallen completely dry despite the fact that there is water coming out of the ground in several places.

We followed one of the little creeks to find the source and built a small retaining wall.

DSC 0041

Then we dug a larger hole so that the water can accumulate and build up pressure for the irrigation system.

DSC 0062

Currently water levels of all these little creeks are at a minimum as we are at the height of the dry season. The good news is that a creek that still has water at this time of the year is one that has water every single day of the year. So it simply becomes a matter of distributing the water to where it is needed. Further down it will join the creek again but before that the grass on the pasture will be irrigated.

DSC 0072

So yesterday we tried for the first time with a hose and a garden sprinkler. The pressure is very low at the moment but that may be because the water level behind the wall is not that high yet and we had leaves clogging the pipe. We need to install some kind of a net to prevent stuff from entering the pipe.

The very same creek – just a few meters below the pasture – has formed a deep pond and a little waterfall. I’m thinking about using a hydraulic ram pump to use the kinetic energy of the water to move it up. That pump may provide enough pressure for larger sprinklers that can throw water over a significant distance.

DSC 0084

Another idea is to use a low pressure system and irrigate drop by drop using one of these hoses with many little holes in them. These get buried into the ground and water simply flows out of the hose over its full length – drop by drop. That may work very well as the pasture is sloped.

I guess we will have to experiment a bit. At the very least we now have some irrigation system to start with and I expect the grass to become green and start growing over the next few days.

PS: For those who have been reading my stories about the rainforest farm before… No, the issues are still ongoing. I plan to tell the story when there is a result. At present nothing gets decided because the competent authority is being dismantled and is without leadership until the replacement authority has started to take over. It’s a political thing.

Written by Stephan Schwab

March 30, 2011 at 11:10 pm

Posted in Farm Life

Validation rules for form input in Acceptance Test Driven Development

leave a comment »

A lot of business applications present forms to the user and there is always the need to validate user input into these forms. Should we test validation of form input in a Cucumber feature when practicing Acceptance Test Driven Development?

To me Acceptance Test Driven Development is not about testing. Based on that testing validation rules is doing the wrong thing for the right reason. Of course you need to specify your validation rules somewhere and test them. However, there are many different tools in a team’s toolbox. Some are for a very similar purpose but as in the physical world there is a reason why you keep all of them in your toolbox and not rely on a single tool for every job.

Unit testing a validator class

Regardless of the programming language you are using you can probably create something like a validator class – basically some piece of code where you keep all the validation rules. It should be easy to test drive that and then you just have to make sure you reuse it in all the places where you need validation of input.

Tell a good story and still show that input is being validated

In your Cucumber features you should always tell a good story based on what your customers tell you. You should use their language and not say that a first name in a form cannot have special characters like $%^& or similar. Real end users don’t care about that kind of detail. They care about that the application works and doesn’t crash.

Still there may be a need to prohibit the input of those special characters for some valid reason. If that is the case, then it becomes part of your acceptance criteria and it should be shown in a Cucumber feature. After all Cucumber features are our primary means of communication and these .feature files are also documentation that may be required for regulatory reasons.

On the other hand you should not repeat in your Cucumber feature what the unit tests are already doing. Keep it short and keep it to the point. You may tell a good story in the happy path scenario and then show that input gets validated in another scenario. I think it is enough to say that “invalid input will be rejected” in most cases. If you are required to show explicitly what “invalid input” is, then you may show an example in a “When” step.

Written by Stephan Schwab

March 21, 2011 at 12:06 pm

Acceptance Test Driven Development changes how you organize your project

leave a comment »

Anyone who sets out to develop software does so with a specific motivation. Common motivations are to reduce the cost of some business process, to increase revenue by being able to serve more customers or to create something to sell in the case where the software itself is the product.

Software development is expensive and it takes quite some time to create something meaningful. Some people see how fast you can use software to solve a problem, but rarely have an opportunity to see what it takes to build that software in the first place. That frequently leads to wrong expectations.

Risk, Return on Investment

Because of the cost and time it takes to develop software it seems a good idea to look at the risk involved and understand when there is a return on the investment being made. Whenever some activity takes a long time the risk increases because more and more things can change. If something takes just two weeks, then you will likely be done before something changes. If it takes four months or a year, then almost everything can change. It is simply more likely, because people have new ideas, competitors are not standing still, new things get discovered, etc.

That means the earlier your investment into software provides something in return, the less risk you have. You may also have covered potential losses to some extend, if you need to stop unexpectedly.

At least that’s the theory. Let’s see what we as software developers can do to make it work.

Take on first: High Risk, High Value

Let’s assume you want to build an application that is a provider of data for an established backend system. Let’s further assume that your main motivation for building said application is to provide end users a better experience than what they are used to.

Where would you start?

Would you start to work on the user experience, as this is why you are starting the project in the first place?

Or would you start with the integration to the existing backend system?

To answer the question we need to look at risk and value. The motivation we have for doing the work and spending money may not be our best guide here.

If we were starting our project with the user interface, we would certainly be working on the item with the highest value to our stakeholders. After all our stakeholders are paying for precisely that and we want to please them and provide as fast as possible something they can use.

But then if we were starting our project with the user interface, we would incur the risk that we will get to the integration to the existing backend system very late in the project and it may not work very well or not at all, because we assumed a few things that led to a certain design in code – and then it may turn out that these assumptions were wrong. If that happens, there would be the user interface our stakeholders had be waiting for but the application cannot be put into production until the integration to the backend system has been fixed.

So the item with the highest risk is clearly the integration to the backend system. There will be no return on investment at all, if that part does not work. After a 6 months project that produced the perfect user interface the pressure on the team will be extreme and probably the same stakeholders who have been very happy so far will be extremely upset once it turns out that the whole investment is likely to be a total loss unless the integration gets fixed.

What about the value?

After considering the all or nothing nature of the integration to an existing system the value of the integration story is probably much higher than the story about the user interface.

How Acceptance Test Driven Development helps

Whenever you start a software project the first question should be:

What is the criteria used by the stakeholders to accept the result of the project?

In my example that leads to a generic Given/When/Then like this:

Scenario: Our ultimate goal for the project
	Given an application with a well designed user interface
	When the end user enters all the data needed by the backend system
	Then the backend system will receive all the data

As we want our Given/When/Then steps to be executable, we now have to find out what is the smallest thing that could possibly work and allow the application to pass the test.

For the Given this is relatively easy. We just need an application with some user interface. It does not matter at this point that we do not really build something specific.

For the When we can start out with a simple form with just one element (say a text field) so that we can enter some data and trigger some simplistic code that creates a file, calls a web service, opens up a TCP/IP socket or whatever the interface to the backend system happens to be. At this point we are not interested in completing the work but instead we want to figure out the details. Instead of relying on guesses - as educated they may be - we write some real code and run it.

For the Then we use the backend system to find out about the data that we sent to it during execution of the When step. Maybe there is a user interface we can access using some automation tool. Maybe there is a database we can connect to and run a query. There might be a web service or something else.

So to complete our very first story we need to do as much as is needed to get some data from our application into the backend system and be able to verify the successful reception of that data.

Make it richer

Now that we have a "walking skeleton" we can work on making the application do more and more and become more feature complete. Each step of the way we want to prioritize our work based on value and risk. Always think about which story enhances the application's usefulness more when you have to decide which one of two stories is more valuable.

In the case of the application that captures data and provides it to a backend system your nice to have stories are clearly those that enhance the user experience. At least as long as you have gaps in the data you send to the backend system. It does not really matter how your stakeholders perceive this. As a development team you need to educate and explain how you use their money in a responsible and goal oriented way. Everybody needs to understand that we will get to everything - some day - but we need to work based on the real acceptance criteria. The one and only criteria that really counts at the end of the day is working software.

So in the example there is nothing wrong in building a front end application that is nothing more than a bunch of text fields but does send the right data in the right format to the backend system. Next iterations the team can enhance the user experience by using drop-down lists to choose from a range of valid inputs instead of typing in the value and so on.

Dependencies and interaction in the user interface

In many applications the user gets asked a few things and the answers determine what he will see on some screens later on. A web site to buy car insurance may want to ask details about the spouse, if the customer has indicated that he is married. Such behavior is simply an enhancement to some other story and it does not prevent the team from building a "working skeleton" that works from end to end.

Backend systems that want all or nothing

Say your existing backend system absolutely needs a lot of data and will not accept the input from the "walking skeleton" until it is complete. Instead of going to all the trouble to build all the stuff you need to provide that data, you can simply fake it.

There is nothing wrong in picking one example of valid data and another example of invalid data and simply hardcode whatever is needed to pass it along. Just make sure you have stories for the real thing and put them into your backlog so you won't forget.

Written by Stephan Schwab

March 19, 2011 at 4:03 pm


Get every new post delivered to your Inbox.

Join 259 other followers