ASWEC 2009

Due to other commitments, I attended only the final day of ASWEC 2009 on the Gold Coast having accepted an invitation to participate in a panel discussion on The Future of ASWEC. One highlight for me was catching up with old friends and making a few new ones.

Another was hearing Neville Holmes innervating keynote talk about The Prehistory and the Future of Agility, where he raised a number of issues and recommendations about elevating software engineering from its current state of practice to that similar to other professional engineering disciplines.

Neville Holmes has a long and distinguished record in the computer industry in Australia but I happen to know him from his remarkably lucid and insightful column written for Computer. I am grateful for the many clarifications and additional references that Neville has provided so I can improve this article. (Remaining errors are, of course, my own.) He started off by saying that he didn't know much about agile and found the Agile Manifesto of interest but "it was the Values that got me; they were the values we (IBM systems engineers) held back in the '50s and '60s."

Neville told several anecdotes (and had to restrain himself from telling several more) including about IBM Melbourne which had a service bureau of punch card machinery some years ago, all hardware programming by plug panels. There was a secret one in Defence Signals that being parallel and fast was used through the 70s. They later moved to Fitzroy Street, St Kilda when they got stored program computers that for the first time has separation between program and hardware reflected in a physical separation between programmers and operators.

Programming is a talent thing, some people can do it, some people can't. Ford Motor company ran courses to teach people to program and found that a program aptitude test was a very reliable indicator. They hired B-/A people, not A+ because they tend to disrupt. The A+ were reported to be poor team workers; I guess they'd be the best extreme programmers in today's terminology.

This was run by personnel "before management became inhuman." A chap from Personnel went around Ford setting the test. He sat the test himself and was one of the people selected. [My comment there was a jibe at the renaming of Personnel as Human Resources which seems to me to have authorised the treatment of people as resources rather than people.]

Management, "stupid idiots" put programmers and analysts in separate rooms; system analysts talk to users, programmers only to analysts. Much as mechanical engineers learn about bulldozers and other equipment, and when I did electrical engineering I experienced electrical and mechanical, eg. boilers, to gain enough awareness to be able to supervise technicians who carry out detailed design tasks.

We should put programmers in technical college and technical school. Salesmen dealt with management but the problem was managers didn't know what they wanted; managers didn't know what everyone else was doing. Using butcher paper and texta pens, carry out workshops with managers to work out what they do, over two days.

They work in isolated departments in hierarchical organisations where managers don't know what workers do. Wrote a program to produce a 6-12 month delivery schedule for ordering sheet metal, subassemblies and parts at Broadmeadows. The workers wanted to check the calculations! Instead they should have been interacting with suppliers.

Big projects don't work because they take a long time and may be out-of-date by the time they are delivered. The problem with projects is that they focus on software instead of data which is more important, "the data doughnut in the software hole," to enable adding components, interfaces to data.(*)

Embedded systems are "pretty damn hopeless, really" - for example, modern sewing machine has an "absolutely bloody shocking" user interface. The human machine interface, cognitive science and how people work, is more important than how machines work.

Professionals and the secondary profession; we have to understand data ("technician") from other professions, eg. medicine. Do combined/dual degrees in profession, and data or information engineering. Universities need to plan, probably easiest in the Melbourne model, because programmers "cannot hop around from field to field and expect to be successful" in each one.

The traditional staff, line and service model has been reincarnated as minders, grinders and finders. The "weird things that happen in government departments" because data processing departments became empires and centres of power. In Canberra, Malcolm Fraser split Treasury, who got the computing equipment, from Finance, who had the right to use it.

(*) Neville tells me (in private correspondence),

My reference was to an old popular song "As you go through life make this your goal: watch the donut and not the hole" (e.g. see www.skypilotclub.com/interview.html) from "Sometimes a Great Notion" (see en.wikipedia.org/wiki/Sometimes_a_Great_Notion_(novel)) and I guess I assumed that readers and the ASWEC audience would make the connection of the title of my original essay (see eprints.utas.edu.au/1130).

Neville taught the chap how to use spreadsheets to support his work arranging the Premiers Conference using a spreadsheet for planning on typewriter terminals (before spreadsheets were supposedly invented).

We used to have a saying in IBM: "If you solve problems you breed albatrosses" (referring to Coleridge's "The Rime of the Ancient Mariner").

Neville says he was "banned from three departments for trying to enable users" and they reduced the dispatching priority to below that of batch whereby the slow response time meant it could only be used on weekends or after hours. [The ban was not directly related to my work at the Department of Finance, and it was not an official ban; local IBM management was asked to take me off those accounts by the DP sections of those departments. - Neville]

The tragedy of the recent walk in Blue Mountains where information from David Iredale about his position was ignored and not passed onto rescuers and police because it didn't match the computer program and training. People aren't thinking and want the computers to do this for them.(**)

Small business machines from IBM System 32, 36 and finally the wonderful System 38 had RPG (Report Program Generator) that used template programming. A sheet for each file; input/output files and processing files, "much easier than Cobol. Cobol, as you might know, is not very good at all."

Macro systems were very good in the 60s, stealthy development in IBM to develop assembly code for testing before the hardware was ready. A macro system so user to "write programs" and professionals added macros and kept them up to date.

The presentation is written in HTML because "I can control it instead of it controlling me" (i.e. PowerPoint). Empower users, "to hell with management" because management is interested in strategies and this is tactical.

The challenge: using technicians "focus on this language (eg. Java)" course called Professional Computing, learn five different languages (interpreters, eg, python, SQL). For programming, go to technical college; for data engineering, work in partnership with other professions. Look to enable users, not to take it away from them.

(**) My main point at this stage was that computers are used to avoid responsibility (eprints.utas.edu.au/2765).

A question was asked about teaching web development, concurrency, etc; the answer was better frameworks. To a question about analysis, design and coding activities; the answer is looking for close teamwork between engineers and technicians, "love agile iterations." Question about enabling the users but not ceding too much control as to "bring down the system"; answer is teamwork, not to isolate the users in spite of "mad dogs and other kinds of weirdos."

Responsibilities of engineers in data not software; look at users, community, code of ethics. Raise the stakes for software engineering, "should be much higher." To a question about what to teach in university degree; answer was content is not that important so long as you get the right mindset, the first job does a lot more in determining career.

After a break, the panel members spoke about the future of ASWEC, questions were asked of the audience, discussion ensued and the consensus was that ASWEC is basically alright the way it is. Overall ASWEC has a very good structure, albeit there are aspects that I would change, and any change could have unintended consequences. However the landscape is changing so there may not be any other choice than to accommodate some change in order for ASWEC to prosper.

My preamble to discussion:

Rugby first - I am happy to be in Queensland and pleased to say the Western Force beat the Queensland Reds a fortnight ago; I am not happy the Hurricanes beat us a week later.

The greatest strength of ASWEC is the co-location of academics involved in research and teaching with industry practitioners. However, for an engineering discipline which relies upon industrial practice for its existence there is too little 'meeting of minds.'

Software engineering practice must be informed by strong scientific underpinnings, including computer science and mathematics. Dijkstra and Parnas among others provided the foundations of this discipline decades ago but industry practice is lax and even academic memories are short.

Our assessments of planned, formal and agile methods are a case in point. The agile approach is fine for programming in the small but large-scale engineering projects in defence, utilities and government, enterprises and resource industries cannot be served by a simplistic approach.

With cheerful conceit we collectively forget lessons learned and continue to reinvent the same 'innovations' - as David Parnas reminded us in his keynote address at ASWEC in Brisbane four years ago.

At ASWEC in Sydney three years, Julian Edwards of Object Consulting remarked in his keynote that after inadequate requirements, the absence of architecture is the biggest cause of project failure. However I see scant attention being paid to architectural frameworks.

I believe that with appropriate analysis, any complex set of requirements can be partitioned into systems and subsystems; the software components then can be developed in an agile fashion.

Julie Blake from Object Mentor, in her ASWEC industry award paper, 'Gathering the Right Requirements,' two years ago in Melbourne advised 'matching the process to the project.' Too many practitioners dismiss the reality that requirements engineering, architecture and test frameworks are vital to the success of non-trivial projects and complex systems.

The report Challenges of Complex IT Projects by the British Computer Society and The Royal Academy of Engineering goes straight to the point of the many problems that beset complex IT projects:

"There is a broad reluctance to accept that complex IT projects have many similarities with major engineering projects and would benefit from greater application of well established engineering and project management procedures. For example, the importance of risk management is poorly understood and the significance of systems architecture is not appreciated."

There are bundles of issues in industry that need to be resolved to enable the success of large-scale distributed and concurrent computing.

As Ian Sommerville pointed out in his keynote at last years ASWEC in Perth, construction by configuration and integration of third-party and legacy systems pose significant, open research questions. He suggested that Australia could take leadership in this area and why not?

Such a research program would by necessity be of a longer time frame than industry desires for project delivery. However, strategic IT initiatives include programs of work that span several years so a realignment of expectations may not be out of the question.

The greatest weakness of ASWEC is lack of strong engagement with a cross section of industry. Our challenge is to attract their sustained participation in future conferences by becoming more relevant to the problems they face.

The future of ASWEC will reflect the future of software engineering in this country. If we blur our focus towards programming then ASWEC will flounder without a clear audience. If stakeholders in ASWEC build a vision for software engineering then industry will benefit and the conference will flourish.

Comments from the panel members covered a range of opinions and perceptions about ASWEC in relation to their own priorities:

• How does Agile fit into the complex systems development life-cycle.
• Interdisciplinary teams, eg. safety and security; professionalisation, including conferences.
• Better value for DMO to have co-location.
• ASWEC is a serious research conference in SE - not only that, it's more.
• It's a broad conference, SE is a broad discipline, SWEBOK has broad knowledge areas.
• Academics and industry - must be serious research to bring academics out of "ivory tower."
• ASWEC is increasingly international.
• Lack of students - not selling benefits of SE adequately.
• Agile is good but please, please don't allow it/use it as an excuse for lack of discipline.
• ASWEC covers whole range of activities, the breadth of engineering.
• ERA (Excellence in Research Australia) - journals and conference ranked in international standing; ASWEC and other Australian conferences ranked B but unis only fund A or A+ ranking.
• "Love, passion and time" in terms of organisation.
• Caution changing and impact of changes.
• "ASWEC, it's better than nothing." Where would we be?
• Venue for Australasian scholars; nursery for new researchers.
• SE journals and funding? Engineering has difficulty in general with funding (eg. ARC) compared to science disciplines.
  

The DMO (Defence Materiel Organisation) which has a vision to "become the leading engineering and project management organisation," is sponsoring the formation of the Improving Software and Systems Engineering Conference (ISSEC) . The vision of ISSEC is a "commitment to the advancement of integrating and improving systems and software engineering best practice for the engineering profession and industry."

Gas water pipeline

It has been suggested to me that I should do the hard yards to research and write up a proposal for a combined gas-water pipeline from the Kimberley-Pilbara to the south west of Western Australia, to complement the existing Dampier to Bunbury natural gas pipeline and at the same time to realise the long-held dream of piping water from the Kimberley to Perth.

Some cursory research has demonstrated to me that the engineering aspects of such a venture are certainly surmountable because pipeline engineers have accumulated enormous experience in pumping solid-liquid slurry and multi-phase gas and fluids through pipelines over long distances.

Slurry pumps and pipelines are often used to transport minerals and other solids from a mine to a processing site. Flow assurance and flow optimisation in multiphase oil-gas-water tie lines and export pipelines are important issues in offshore oil and gas, especially subsea processing. In either case, technical issues to do with basic metallurgy, fabrication and corrosion protection are significant but not insurmountable.

Ongoing interest in a water pipeline and recently escalated interest in gas pipeline security stemming from the Apache gas explosion on Varanus Island support the development of a business case. This would lead to funding of a design study in order to establish the feasibility and cost of a combined gas-water pipeline as a solution to gas energy and water security in this state.