Wednesday, 12 October 2011

Strain your Resources, Ruin your Software.

One of my daily frustrations around here is the amount of work which relies on such tenuous back history.  A good example, which has I've been reminded of today, is the smart card (chip & pin) system used in one of the main products of my employer.

I wrote the current incarnation of this system, and to be frank, my employer needs to kiss my boots for doing so, because writing it was pretty much done in the worst circumstances, with no design, no idea what was even expected, from an in complete software development kit (SDK) purchased years before; for a member of staff no longer in their employ.

The fact that they have working chip & pin functionality is a miracle.

I mooted this scenario to a friend of mine, he expressed similar concerns at his employ, it seems the common story is that someone higher up decides a piece of kit or tech is needed, and they turn to a randomly picked, or the first available, technie type person and they set them a challenge to get things done.

The trouble with all this of course is that it leads to stress, the person doing is stressed, especially when there is no formal back, no training and no resource in which to carry out the task at hand.  The person asking for results is stressed, as without that back ground the task takes longer than it is perceived to take.  And then at the end of the day, one is stressed, the product is stressed, as testing it might reveal unknown results.
   
The moral of the story is, if you want to get good software, kit or tech, out the door let it mature.  Get the resources, get trained, get research carried out, and get to know the end product required.

It seems the current economic slump has taken a bad situation and made it far worse, as before managers and higher expected tech results from the veneer thin surface of training or resource they'd give.  But now it seems that tiny resource has been done away with.

Leaving people to produce substandard, strained, flaky software, and worse still they then point blame not at their own miss-management but at the developer working on the product.
   

No comments:

Post a Comment