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).

• Agile Methodologies - Agile methods used to be called Lightweight (which probably smacked too much of frippery & friviolity) and before that Rapid Application Development. We (APLers) were "agile" even before RAD. The basic principles common to all agile/lightweight/RAD approaches (Incremental Delivery, Direct communication or co-location with the end user, small teams, prototyping, etc.) were all fundamental to the way we developed APL systems from the very first day I started using it. I've often wondered which particular elements (the language itself, the timesharing environment, the isolation from hardware) drove the adoption of this approach, but I'm jolly glad they did.

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

OK, enough background. What to I actually do?

• As I've said, my code sits in a function file. The workspace is built dynamically on loading by a single resident function. I then develop as you would expect in the interactive session. Periodically I make sure the function file is updated with my changes and reload the workspace. Why? Because I don't want all my changes saved automatically to file (some, perhaps many, are failed experiments), but I do want to perform an "integration test", making sure that the changes I've made don't trip up the system & that I have included all the relevant alterations I've made. Now it might seem tedious to keep on reloading, but I find that because I do it this way I keep focused on fast loading times & very concise paths through the GUI (unlike, say PhilLast, just about everything I do has a major GUI element). This benefits the user in the long run, they have a system which is very easy to navigate, with no long complex interactions - all because I'm too lazy to keep working through a GUI to get back to the point at which I was working.

• Separating different different aspects of functionality - I said my code is very focused on the interface, by I don't like interlacing the GUI elements with the "deeper" system functionality. This means I use my framework to establish a standardized GUI and generate the GUI in a distinct function (or group of functions). The framework handles the interaction with the user & gives a very simple interface to the callback functions. This often means that there appear to be major stylistic differences between the parts of the code which I write: The GUI builder has a script like appearance, calling utilities to generate the GUI elements; The major control logic often uses IF or SELECT constructs to capture all of the calls to different elements of the system in a single easy to read function; but the "deeper" functionality is coded using computational logic & a heavy dose of dfns. I don't use dfns for the major logic, I find that it's too difficult to step through them at this higher level: once I'm down to smaller functions which can be called directly to debug them, then the power of dfns comes into its own. Or maybe I'm just schizo.

• I'm not a great fan of "Object Orientation" - now before I draw too much opprobrium from OO fans, I do think encapsulation (I use namespaces to isolate elements of my code & don't "reach into" a namespace from outside), polymorphism (after all, if one is going to seal up one's code in something like a namespace, then a robust interface is essential) & inheritance (consistency is always a good idea) are all things I can agree with, but I find the whole OO thing yet another cult, which introduces another layer of jargon between the developer and those who use the developed code. It was bad enough when working with "domain experts" in large organizations, but recently I'm bee working with small groups of people, often with an educational background (non-technical) & they wouldn't know a "class" or a "method" if it bit them on the bum.

CategoryWorkingPractices