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.

• 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 Carlyle 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. 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 was 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.