“Keeping you up to date with everything software engineering!”

INTERVIEW: Dr. Peter Grogono

Interviews | October 11, 2004 | 1 comments

Every student has one teacher in university that sticks out in their mind more then any other when they look back onto their university career. Dr. Peter Grogono is mine.

Some of you will remember Dr. Grogono from CUSEC 2002 and 2003 where he was both the opening keynote presenter and the moderator for the round-table discussions.

I hope you enjoy the interview as much as I did.

---

I have known you since you were my teacher and advisor in university but for all the people out there who have not had the pleasure to meet you can you please introduce yourself?

I started off with a mathematics degree from Cambridge (UK). We did one course in “digital computation”, taught by Maurice Wilkes. We did our assignments on EDSAC 2.

My career in mathematics was short: within a few weeks of starting my first job, I was programming. Quite soon, I was addicted. For the next few years, I had various jobs in software development, including four years at Electronic Music Studios programming a couple of PDP8s. In 1973, I moved to Montreal, and worked as a consultant programmer. In 1976, I joined the Computer Centre (now IITS) at Concordia University. While working there, I obtained a masters and a PhD in Computer Science, and joined the Computer Science department in 1984 - which is where I am now.

You were instrumental in starting the software engineering program at Concordia University in Montreal - including being the first Director of the Software Engineering program. Why do you think software engineering is important, and what got you into it?

Dean Esmail initiated the Software Engineering program. At an early stage, I volunteered - always a mistake! - to assist with the curriculum design. The curriculum was developed by many members of the department. I coordinated the effort and ended up as program director. In Summer 2004, I passed the baton to Dr Sudhir Mudur.

I think that software engineering is important because we are all increasingly dependent on reliable software in our everyday lives. Whenever you go to the bank, drive a car, fly in a plane, use a health care facility, or any one of many seemingly mundane activities, you depend on software performing correctly. I suppose you could say that I “got into it” in 1968 - the year the term “software engineering” was invented - while working on the Geroge 3 operating system for ICL.

Do you think software engineering has gone far in the past 10 years or do you think that we have just been going around in circles - i.e. realizing what is wrong with the way we are doing things but just sticking to our old ways?

Both. Yes, there have been significant advances and, yes, we are just sticking to the same old ways.

It is easy to look back ten years - or twenty - and see the same programming languages, same techniques, and same mistakes. But this misses the point: we expect and achieve much more today. A single program running on a single computer with a keyboard and a screen is no longer a big deal; today’s software is distributed, multi-tasking, and interfaced to databases, networks, and web browsers. The fact that we can deal with these demands implies that software engineering has moved on.

Although much is made of rapid change, programmers are conservative beings who believe that, if it ain’t broke, you don’t fix it. Once they have found ways of getting their work done, they will not change unless they are totally convinced that the new method is better than the old - or they are ordered by management. This is why, although there are lots of new tools, programmers still spend most of their time editing, compiling, testing, and debugging.

Why do you think professional software development teams continue to work the way they do, knowing that only 34% of projects are considered a success?

Perhaps the assumption made in the question is wrong: people may be changing the ways in which they work. The constant failure rate could be due to the increasing complexity of software. The projects that are failing today are larger and more ambitious than the projects that were failing ten years ago.

Perhaps software companies are not impressed by the new techniques that are being offered. There is a lot of hype about new methods but there have been very few objective studies that clearly demonstrate the superiority of any particular method.

CASE tools, with a few exceptions, do not sell well, and those that are sold are often not used. We should find out why. What tools does the industry need? Can researchers provide them?

What do you think teams are missing that will help them go from a no-methodology methodology that has a very high failure rate and move towards proven software engineering methodologies and best practices?

What is missing are the “proven software engineering methodologies” and “best practices”. We have no shortage of methodologies and practices, but no proofs that they work or are the best.

Changing methodologies requires time and money. Tools have to be purchased, current staff have to be trained, and perhaps new staff have to be hired. Large companies with deep pockets can afford this; smaller companies may not be able to afford it, or may believe they are not able to afford it.

Do you think there is going to be a major breakthrough in software engineering over the next ten years? If so, what do you think it will be?

I think Fred Brooks got it right: there is no “silver bullet”. In ten years, software engineering will look quite different than it does today but this will not be due to a major breakthrough but rather to steady evolution of our understanding and use of processes and technologies.

What do you think the software engineering profession is currently missing that would help it be more successful?

There have been many software engineering successes. Where the quality of software is critical, as in the aircraft, vehicle, telecommunication, and banking industries, software works very well. We know how to develop high quality software, but it takes a lot of time and effort. For businesses, time and effort translate into money.

Aircraft manufacturers knows that a single software error could cost them tens of millions of dollars; they use whatever resources they need to get the software right.

In other cases, correctness is not critical and the objective is to balance quality and cost. The objective is to get something working quickly and start making money from it. The effort required is underestimated, important parts of the development process are cut short or omitted, and we see the familiar result: bugs at best, shelfware at worst.

What is missing is maturity. When you ask engineers to build a bridge and they tell you it will cost $20,000,000 and take two years, you do not tell them to try and build it for $5,000,000 in six months. If you did, they would refuse. But this seems to happen in software development all the time: the team asks for six months and the manager gives them three. It is unreasonable to expect software quality when budgets and schedules are unrealistic, programmers are working 50 hour weeks, and important process steps are abbreviated or omitted.

What do you think is preventing us from fixing our software processes and methodologies, once we’ve identified what is wrong with them?

There are many factors. Human nature resists novelty; the new methods are unproven; “fixing” may be expensive, as I’ve already mentioned; no one wants to be first.

Industry does adopt new methods, but it takes time. Many companies wait until a methodology is clearly a winner before they consider adopting it. When they do adopt it, they must train their staff. Some people don’t want to be trained; they resist C++ and carry on writing COBOL until they retire.

A company that does hit on a winning technique is not going to tell the world what they do to keep ahead. Sometimes, they do tell the world and the world doesn’t listen. In “Hackers and Painters”, Paul Graham explains how he built his company and kept ahead of the competition by using Common LISP, but the herd did not rush to adopt LISP.

One serious problem is that we ignore valuable knowledge that we do have. Dave Parnas defined information hiding in 1972; the sales guys told us that object oriented programs hide information; and now we have C# with its “getters” and “setters”. Why bother? Why just not go back to good old C structs?

Agile Methodologies are getting a lot of buzz as of late. What is your opinion on them? Do you think they are good for all types of projects or only specific types? If specific types what kind?

I don’t think any methodology is good for all kinds of project: I distrust the “U” word. Agile methods make a lot of sense to me. The projects I have been involved in, most of which are hardly large enough to qualify as software engineering, were all developed by agile methods, although we didn’t know it at the time.

Agile methods are good for small projects without precise requirements. There are many kinds of software that come out best when they are allowed to grow, like plants.

Incremental development was introduced in the early seventies by Harlan Mills and Niklaus Wirth; nowadays everyone is talking about it as if it had just been discovered. Agile methods and incremental development work well together. But agile methods and incremental development are not the same thing. There are applications for which the only way to go is through requirements, design, specify, code, and test. The difference between this and the waterfall model - which doesn’t work - is that you interleave phases and components.

But I don’t think that agile methods are appropriate for all applications. On a large project with hundreds of programs, it’s hard to be “agile”.

For a developer working as a member of a development team in the wild, how would you suggest going about trying to sell the rest of the team on implementing software development best practices?

That’s a hard question for me, because I’m not good at either telling people what to do or responding to what others tell me to do. That may sound strange coming from a teacher, but whereas a classroom is a social setting in which I am expected to impart such wisdom as I have, a development team is a social setting in which I am expected to do my job and let others do theirs.

If I did anything, it would probably be low key, along the lines of “Have you read anything by Kent Beck lately?” or “Do you think we would be completely crazy to switch from Visual Basic to Common LISP?”

What books should be on every software engineer’s reading list?

I wish I could name one! It’s sad and embarrassing that there are so few software engineering books.

“Large-scale C++ Software Design” by John Lakos (Amazon: Canada, US) is one of the few books that is actually about software engineering. It contains valuable information but it was written in 1996 and recent developments, in patterns, template libraries, and elsewhere have superseded parts of it.

There are big, fat, standard texts. They have a lot of words but you could read one from cover to cover and still have very little idea of how software actually gets developed. If you pick one of these books at random, it’s likely to have a chapter on design and that chapter will tell you the virtues of high cohesion and low coupling. But it will tell you nothing useful about how to obtain these desirable qualities. On your first job as a maintenance programmer, you are given a 100 KLOC and told that the coupling is too high and you have to reduce it: where do you start? Does the text book help you?

There are a few books that every software engineer should have, or at least have read. The following list consists of books that I possess; there are certainly many others that I don’t possess. First, the essentials:

“The Mythical Man-Month” by Fred Brooks (Amazon: Canada, US). The first part of this book, written in 1975, seems quaint today, but contains many valuable truths. The second part, added in 1995, reviews the earlier material and finds that much, but not all, of it remains valid.

“Software Fundamentals: Collected Papers by David L Parnas” edited by Danial Hoffnam and David Weiss (Amazon: Canada, US). A true treasure trove! This book contains not only Parnas’s classics on modules, information hiding, and specification but also many less-gems, all worth reading and re-reading.

“Essays in Computing Science” by C A R Hoare and C B Jones. Although the title suggests computer science rather than software engineering, this book contains much that is important to software engineers. Some of the papers are old - the quicksort paper was written in 1962 - and some of the terminology is dated, but there are many ideas here that to this day have not been properly absorbed into the practice.

“Software Requirements and Specifications” by Michael (not the singer) Jackson (Amazon: Canada, US). This short book, full of ideas and insights, has more useful information than most ponderous tomes on these topics.

“Facts and Fallacies of Software Engineering” by Robert Glass (Amazon: Canada, US). Although short and light - occasionally too light - Glass does a good job of emphasizing true beliefs and undermining false beliefs.

“The C++ Programming Languages” by Bjarne Stroustrup (Amazon: Canada, US). C++ is the language to love and to hate. But it’s there and it works. Stroustrup’s clear and detailed explanations are valuable, whether or not you acutally use C++.

“Extreme Programming” by Kent Beck (Amazon: Canada, US). This is definitely worth reading even if you don’t buy all of the features of XP.

Second, books that are nice to have but perhaps not essential:

“Hackers and Painters” by Paul Graham (Amazon: Canada, US). An easy and provocative read. I do not agree with Graham on all points, but almost everything he says about software development seems right on target.

“A Handbook of Software and Systems Engineering” by Albert Endres and Dieter Rombach (Amazon: Canada, US). This book states “laws” and “rules” formulated by the leaders of software engineering and evaluates them. It is unusual because it relates what ought to happen to what actually happens and whether it works.

“Generic Programming and the STL” by Matthew Austern (Amazon: Canada, US). In the long run, generics may turn out to be more important than inheritance. C++ is the only widely-used language with an established tradition of generic programming and industrial-strength dynamic libraries (STL, of course, but also boost, blitz++, and others).

These are books about aspects of software engineering. Every software engineer should also have a solid collection of computer science books covering discrete mathematics, data structures, algorithms, formal language theory, databases, operating systems, and so on. But a list of these books would be long and quickly dated, so I will not include it.

What do you think the next big topics in software engineering research are going to be?

It’s always a mistake to predict the future: prophets are almost always wrong. The most common mistake is to overestimate current trends and miss the big changes. But I’ll stick my neck out anyway. The big topics will be:

1. Process models specialized to types of application.
2. Big advances in generic programming.
3. Invisible and ubiquitous computation.

What areas of software engineering are you presently doing research in? Do you mind describing your research and research interests to us? What is it about these research topics that grabbed your interest?

I’m working with a PhD student on development processes for small companies. The student has eight years of experience in small companies and feels that the standard texts and courses do not address the problems of small-scale development. This seems to me to be a good subject for university research because a team of good students can simulate small company conditions fairly well.

Apart from that, I am not very active in software engineering research. More on that in my next answer.

Is academic research even a viable path for such a professional-oriented domain?

University research is important, provided that it is the right kind of research. There are many temptations in academia: one is to invent marginal improvements to an existing solution, independently of whether the solution is solving an important problem. Another is to create an artificial problem and then present a solution for it. A third is to develop a simple theory and then disguise its triviality with Greek symbols and quasi mathematics.

Good research consists of choosing a real problem - a well-defined obstacle to effective software development - and finding a solution that not only works and can be shown to work. Software engineers in the industry are justifiably fed up with academics who try to sell their methodology on the basis of a term project

• or less. One of the main problems for university researchers is to convince the industry that their solutions scale up without running into efficiency or resource problems.

Universities provide - or should provide - an environment suitable for fundamental research over long time periods. Universities should produce solutions to problems that the industry didn’t even know it had. Function libraries, microprogramming, virtual memory, concurrent processes and synchronization, version control, garbage collection, and exception handling all originated - as far as I remember - in universities. Arcane areas of mathematics, abandoned by most mathematicians, have been dusted off and put to use in cs and software engineering. Hamilton invented quaternions around 1840, but they were rarely used before 3D games. Other examples include lambda calculus, combinatory and modal logics, and category theory.

The current trend, at laest in much of Europe and North America, is discouraging: increasingly, university researchers are required to describe the practical and immediate benefits of their work if they want funding for it. This might seem like accountability for public spending but it’s really an attempt to pass on the cost of short-term industrial development to the taxpayer.

You were a keynote at the first two CUSEC’s as well as the moderator for the Panel Discussions. Is there a moment that you remember the most?

I don’t recall any particular moments but rather a general feeling during both conferences of “Wow, our students organized this!”. I was also very pleased to see that several of the keynote speakers - although not all of them - were happy to spend time with undergraduate students.

If you were to work on a software project from scratch for yourself, how would you organize yourself to minimize the risk of failure?

My approach is essentially risk-based, something like Barry Boehm’s spiral model. At each step, I first consider what is most likely to go wrong, and then write enough code to see if I can get it right. The code may be either prototype or production.

For the kind of projects that I have worked on, I have not found it necessary to have a detailed design before starting to code. But I have found it important to think through, very carefully, all aspects of the design to make sure there are no major flaws. Small mistakes can be fixed up as I go along, but a major design error would require starting over or, more probably, abandoning the project.

What are your three basic rules that you adhere too when developing software?

1. As simple as possible, but no simpler (Einstein).
2. Rules are my very humble, obedient servants (Haydn).
3. Correctness precedes efficiency (Hoare and others).

If you where to write a software engineering cookbook, what would it contain? A list of design patterns? Algorithms?

If I had an answer to that, I’d write one.

I am sure the radiation from your monitors drives you crazy after a while. What do you do to get your mind off computers?

I use LCD panels that do not radiate. However, I consider it very important to spend time away from the computer - the more the better. I have many activities that are not related to computers, including music, photography, reading, and snooker. But what maybe more relevant to this interview is that I do most of my software development - particularly design, coding, and debugging - away from the computer. It’s just too hard to think clearly with a screen in front of you

• and, in the old days, a blinking cursor entirely prevented mental processes.

---

If you have any questions for Dr. Peter Grogono please feel free to write them in the comments section and Dr. Grogono I am sure will be happy to respond to them.

Related Link:

• Homepage of Dr. Peter Grogono

Help Support Us By Visiting Our Sponsor

10% of our revenue from these ads go towards scholarships!

Comments

October 14, 2004 01:24 PM | Anonymous commented:

Very interesting..!!

Post Your Comments

Comments:

Name:

Email Address:
(note: not displayed)

URL:
(note: displayed with comment)