Describe Working Practices - Chris Hogan here.

My working practices have been formed by interest in Software Engineering (I said interest in, not belief in), agile methods (even before the term "agile" was applied to software development) and an awfully long time enhancing and supporting our APL-based dealing system 4xtra.

My aim is to be both productive and "lazy" - I don't want to keep on reinventing the wheel, not do I wish to have to do anything which distracts me from solving the particular problem I'm working on.

To this end I'm used to deploying a "framework" within which I try to do most of my development. 4xtra grew to have a considerable number of tools & I've become comfortable using their more modern descendants, but even in my early days I used the "RX Skeleton" (a framework development by Phil Gray, Stan Wilkinson & others) & then tools used by Allan D'Morias & Associates (where Stan, Marc Griffiths & I worked together for a good number of years).

So what did I pick up?

• Timesharing - now that may seem a daft thing to say, but the way that one had to develop timesharing systems has influenced the way I design systems. It's obviously a very thin client, but the Sharps environment was, in a sense, Personal Computing. One had a pure APL environment isolated from the considerations of the hardware. Having said that, most of the systems I worked on at that time were intended for use by a physically dispersed set of users. Coupled with the erratic nature of telephone lines in those days, it instilled good habits with regard to recovery, restartability & general interaction in real time between users of the systems.

• PCs - the immediacy of user interaction with a PC was a shift from the "block mode validation" of screens & printer terminals used for Timesharing systems. It took a while to get used to, but I hate it if I have to go back to the "old style", which influences the way I design web-based systems, which do have more than a hint of blocking up communications.

• Function Files - I still use a great-grandson of the function filing system we originally developed for ADM. I reproduced the functionality for 4xtra & PhilLast rewrote the whole thing for Dyalog, where it grew into Maya our code management system. I know Phil has now gone on to produce Acre for the Carlisle group, but that solves a different set of problems. Our development group is loosely scattered around London, sometimes our clients have been in London too, but have also been in Stockholm, Portcawl, Buenos Aires - in fact if you go back to the Rank Xerox days practically all over the world. The point here is not to share development over a dispersed team, but deliver updates to remote clients (although a lesser ability to develop code remotely is a side effect). We don't use the internet in the same way as Acre (Maya pre-dates the appearance of the high upload speeds which make these features of Acre practical).

• Incremental Delivery
• Software Quality - the concept of ISO9000 has always fascinated me - the idea that production quality is controlled in such a way as to make it simple to keep turning out the same widget to a standard specification. Not that I see a lot of direct application to software development. We _don't_ churn out dozens of replicas of the same program every time we start a new project. But even the "pattern development" beloved of many developers is an attempt to ensure the reproducable quality of a piece of software.

CategoryWorkingPractices