Tag Archives: Development Cycles

The User Is the Beta Tester


One of the reasons why I got involved in supplying web-based information to the people in a manufacturing position was that no-one truly catered for their needs. Business analysts, and later Group Information Services (GIS) mostly concerned themselves with the higher levels of the organisation, and whilst Process Control did concern themselves with manufacturing, more often than not their development cycles were to slow for the manufacturing process.

In an environment where everything has to be delivered yesterday, anyone who needs months or in some cases even years to bring a product to market will find themselves at odds with those who need the information now, not a year from now. In my opinion, development teams at the local level often fail to appreciate that we’re not trying to develop the next Windows version, and as such development models like the waterfall model are too ponderous for something that moves at a far greater speed than the cycle time of your model.

That’s why I imbibed the philosophy of the Agile Manifesto before I had even heard of such a manifesto. The way I saw web-based development, the user was always an integral part of the development cycle, in that they knew better than most what it was they were looking for, and could test a partly developed system far better than any IT developer could. This is not to say that I would send out a new system totally untested, but I remained very much aware that I was not the best placed person to know all the ins and outs of what the system was supposed to encounter in real life.

Besides, having your customer as the beta tester is the best way to make sure that they remain interested in its use. If I have developed an entry system, and subsequently don’t get any feedback on it, my assumption by default is that the user is not properly using and testing the system. It’s always been my view that the user gets the system s/he deserves, and if they have not properly tested the system prior to its full launch that’s their loss, not mine.

The reverse side of the coin where the user is also the beta tester, is that developments following the initial launch are open-ended. This means that I’m willing to take on future suggestions for alterations or improvements, provided the initial system can be modified for the new requirements without breaking it. If it requires ripping up the old system and starting afresh, that’s the moment to then decide whether the new requirements are worth a complete rewrite.

However, throughout my 15-odd years as a developer I was always seen as a necessary evil by the IT professionals. Whilst they had to admit that what I did was useful and at times necessary, it was only because in the end they had to admit that they did not have to resources to do the same that I was allowed to continue in my role as cowboy web developer. It was a rare moment if anyone in that capacity was willing to admit that quick development times were at the root of my prodigious output, and that this could only be done by ditching the holy cow of official development patterns.

Advertisements

The Agile Manifesto


I only came across the agile manifesto long after I had been applying it to IT in my working life, and I still wholeheartedly agree with its concepts:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

It was one of the reasons why I started to get involved in web page development after I had joined the PEGS team in Llanwern: no-one supplied the production people with the information they wanted to have at their finger tips, and could provide them with this information at the speed of development that matched their needs. All the official IT had been outsourced to Cap Gemini a few years earlier, and they mostly dealt with mainframe screens. Not only did it cost you an arm and a leg, but it took months to get requests through the system, and after sitting in the queue for a further few months then got dealt with in a leisurely fashion.

Presumably that’s why Process Control started to have their SQL and web servers, but even then, their speed amounted to development times of weeks to months rather than days to weeks. Fortunately the fledgling PEGS team in its short existence became heavily involved in using mill computer data and extracting mainframe data into SQL, and that’s where I made my first steps into IT land.

From quite early on I made it a principle that the customer could never walk away from the work they had requested. After all, I might have known the IT side of things, but they had the in-depth knowledge of the systems they wanted developing. Of course it helped that I was also a metallurgist and had sufficient process knowledge to think along with them and try myself in their shoes, but in the end I made the development cycle of one where the customer always had to be on hand to make sure that was being built matched their expectations.

To be sure, documentation was one of my weaker points, although at a later stage I tended to produce user guides and expert guides in the wiki, where the user could always the necessary detail to hand over the knowledge to other users. It also helped that for most of the time, I acted as a development team of one, creating the databases, the means of filling those databases as well as the web pages to display and modify the content. Only in my last 6 months in Port Talbot, when I was bringing Theo Vardakis up to speed with my way of working did I have to deal with making sure that we didn’t get in each other’s way, and that what was developed by one person could also be maintained by the other.

I think the most important thing that I tried to instill in him was to make sure you fully understood the customer’s requirements before you started on your development, otherwise you could spend several days producing something that was of no use to man or beast. Presumably this comes in the end when you start becoming used to your environment and the people you’re dealing with, but there’s no better school than trying to do things and learning from trial-and-error.