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.