Whether you work on your own idea or on a project for a client, it is essential to internalize the idea into your mind. It is important to visualize the end product. As a knowledge worker it is easy to spend a long time and not much progress. This happens because we do not understand what is necessary for knowledge workers to get things done – a clearly defined end product. To be able to see in your mind’s eye what the interface will look like is extremely crucial. I have found that I am able to work with far less stress and am able to make much more progress in far less time when I have a clear internal structural understanding of how my application is going to work.  

Write Test Cases First!

Whether or not you have the luxury of having your work tested by a tester it is essential to write test cases for the code you are about to write before starting to write it. Writing tests first yourself dramatically changes the way a implementation approached. When I say tests, I do not mean unit tests. Unit tests define the API interfaces that will be defined and the expected results from each programming construct. Tests are clear definitions of what is expected for a range of inputs, what behavior should not happen, and what should happen if the application is used in invalid ways. An example test case for a registration form:

Action: The user does not fill out the password twice in the password fields. The user then clicks on the Register button Result:  The registration form field loads again  with a error message indicating that the password field should be filled in twice. All the other fields are pre-populated with their original data with the exception of the CAPTCHA field.

Unit tests are not enough for defining the outcome of an application. Unit tests are limited in their ability to test actual functionality as they will be used by the end-user.

Defining Tests First Avoids Cognitive Bias

After you have spent dozens of hours building an application a programmer is usually blinded to the inputs and possible usages of his application which can cause it to break. This is not a character flaw in people. By design us humans cannot effectively attempt to break what we just created because we have a tendency to fall in love with our creation. We will end up owning the code personally in a subconscious level. It is psychologically impossible to want to break something you put a great deal of effort in making. You are naturally inclined to take the routes that are likely to show that the application you built is working. You are cognitively blinded from finding ways to break the software you made.

Defining Tests First Saves Time and Money

When you start writing an application without the full understanding of the application you tend to design as you code. This is a very bad practice and should be avoided. You may even get more ideas on implementation of that tiny little feature. This scope creep is a addictive test-develop viscious loop that is going to cost a lot of time.