Digbyswift is based in Leeds, West Yorkshire offering web and digital solutions. With over a decade of experience in corporate and agency web development, Digbyswift can meet and support your requirements, whether it be MVC or web forms development, Umbraco, bespoke CMS build and maintenance, ecommerce, SEO and Google analytics or even client training. Read more ...

Defensive Code #1 – Input Validation

By Digbyswift at July 26, 2010 08:52

Firstly, these “defensive code” articles are not meant to be a definitive, just practices I feel are important to the way I code. The reason I’m compiling this list is partly so that I can have a reference for myself, but also because I wanted to present something to the team I work in.

Input validation

There are two types of input validation:

  • Input from an external source; and
  • Input from within the application.

An external input may be a user submitting a form or it may be the stream from a file you are importing. Input from within your application may simply be the passing of variables as parameters from on method to the next.

In both cases I choose to take the stance that input is almost always likely to be invalid or just plain wrong.

External input

Regardless of the input, it is imperative that you check:

  • The input exists

    There is no point further validating a null string or stream. This should be the first step in ANY input validation.

  • The data should be of the correct format

    If a user inputs a value into a decimal field, it should be validated to ensure that the decimal has the correct point accuracy, e.g. 2 decimal places for a monetary value. This can be done without the need to cast the value.

  • The input data is of the same type that is expected

    If a user inputs a value into a decimal field, the value should be validated to ensure that it is a decimal and not a string.

  • The input data is within the correct boundaries

Obviously, there are scenarios where this is overkill. For example, you wouldn’t need to check that a textual input is of a string type! But regardless of the input method, these can all be applied to ensure that the data collected is valid.

Internal input

I think controlling internal input is easier, just more time consuming. Essentially, for any method, you should check that the values passed or pulled in are valid. Again, there are scenarios where this is not required but my personal rule is to assume that input is invalid.

You will hardly ever have to validate parameterized input is of a specific type as this can be defined by the parameter type. However, all the guidelines from above can be applied.

  • Data exists;
  • Data is in the expected format;
  • Data is within the correct boundaries.

With values that are pulled in, i.e. not parameterized but maybe from a global variable, it is even more important that the guidelines from above are adhered to. This is because otherwise there is an assumption that some other process is validating the data pulled in, which of course you cannot rely on.

Consider the case that a class has a username property which is used in a method but not passed in via a parameter. In this case, it is worth having a separate, global method for handling the validation of the username, i.e. IsUsernameValid(). This way, other routines can make use of the same validation method.

Handling the impossible project

By Digbyswift at June 24, 2010 05:56

I’m currently finishing the first phase of a project that has caused a few sleepless nights. The causes I can comfortably lay at the door of my boss:

  • He agreed a fixed fee up front with the client without any analysis of requirements;
  • He agreed a go-live date up front, again without analysis of requirements.

You might say that this is actually not an issue. This happens all the time, right? How many projects have you worked on when you’ve actually known the budget? Or when the specification for the project has been written after the horse has bolted?

Sure, this probably isn’t an issue if the project is relatively small and one that you can boilerplate from another project. However, in this case, the client wanted us to build an e-commerce/auction application, that once spec’d out required approximately 1050 man hours – that’s around 30 weeks, one developer working flat-out. This also making the assumption that I had captured all the tasks – which inevitably I hadn’t.

My boss promised up front that the client could have it in 12 weeks.

Every developer knows that given any week of development, he will not get 100% development time one one project. Maybe, 75-80%? The rest will be meetings, helping colleagues etc. So, to me, the task was ludicrous. Even with two developers working flat out, the timings still did not add up.

I’ve done my math and the fixed fee agreed with the client, before any specification was written, requirements analysed etc. was a hefty 5-figure value short of just the development cost. Add to this the cost of design, planning, project management costs and then contingency, and you can see that this is simply ludicrous.

This is what we did

So in a nutshell, this is what we did:

  • Myself and another developer worked flat out for the 12 weeks;
  • We hired a contractor to do a independent chunk of the project;
  • We drafted in a third colleague at times to pick up certain tasks;

The 4 weeks testing originally scoped, became 1 week and then the site went live.

The result

It was not my intention to go live after such a short testing period. In fact, no internal was done at all and barely one week of client testing. But the client wanted it live and we weren’t in a place to argue. The result was that a sub-standard site was released to the public:

  • There was missing functionality;
  • There was buggy functionality;
  • There was functionality that just didn’t work;
  • The work the contractor had done was untested and error strewn;
  • The client required changes that were difficult to incorporate due to the buggy nature of the site;
  • The client required changes that they hadn’t realised they wanted till they saw a complete, functioning version of the site.

In addition to this, because the testing phase was cut short and, as it turns out, the client didn’t sign off the specification, the issue-fixing stage will be ongoing for quite some time.

Lessons learnt?

Its easy to say, but don’t let your boss promise anything to the client until a project brief has passed your or the lead developer’s eyes.

How can a project be costed if there is no analysis of what the project will actually entail?

You may upset your boss by insisting on being involved as it will be seen that you are overcomplicating a process that he/she needs control over. But the benefits out-weigh the additional time spent, even if this is 30 minutes doing a high-level analysis of your bosses interpretation vs. the clients brief.

I’m actually very happy how the project has turned out. I’m less happy about the stress that it has caused. But it has up-skilled members of the team, given colleagues the encouragement that larger projects, when handled in a certain way needn’t be difficult and shown core weaknesses in the company’s project delivery process that we can improve upon for next time.