CAREER

Education: B.Sc. (Physics, 1962), M.Sc. (Physics, 1964) at the University of Bombay; Post-Graduate Diploma in Electronics at Welsh College of Advanced Technology (1965), Cardiff; Ph.D. at the University of Cambridge, U.K. (1968).

Academic: Fellow, Senior Research Scientist at Tata Institute of Fundamental Research, Mumbai (1968-1985); Professor of Computer Science at University of Warwick, U.K. (1985-1997).

Visiting Appointments: Visiting Professor, Carnegie-Mellon University (1980-81); Visiting Professor, Eindhoven University of Technology, Netherlands (1990-92); Visiting Professor, University of Warwick (1997-98); Visiting Professor, University of York, U.K. (2001-2004).

Industry: Executive Director at Tata Research Development and Design Centre, Pune and Executive Vice-President at Tata Consultancy Services (1997-2007).

SELECTED PUBLICATIONS

M. Joseph, N. Natarajan, V.R. Prasad, A multiprocessor operating system, Prentice-Hall International, 1984.
M. Joseph, P. Pandya, M. Joseph and P. Pandya, Finding response times in a real-time system, Computer Journal, vol. 29 A02, 390-395, Oct. 1986.
M. Joseph, A. Goswami, What's 'real' about real-time systems?, Proc. IEEE Real-Time Systems Symposium, 78-85, 1988.
P. Pandya, M. Joseph, P-A Logic a compositional proof system for distributed programs, Distributed Computing, 5(1), 37-54, 1991.
D. Peled, M. Joseph, A compositional framework for fault-tolerance by specification transformation, Theoretical Computer Science, 128(1&2), 99-125, 1995.
T. Janowski, M. Joseph, Scheduling and Fault-Tolerance: Specification and Verification, Real-Time Systems, 20(1), 51-81, 2001.
Z. Liu, M. Joseph, Specification and verification of fault-tolerance, timing and scheduling, ACM Transactions on Programming Languages and Systems, 21(1), 46-89, January 1999.
M. Joseph (Ed.), Real Time Systems, Specification, Verification and Analysis, revised 2001, full book downloadable at http://www.cs.york.ac.uk/rts/books/RTS-SVABook.html
M. Joseph, Formal aids for the growth of software systems, FM 2005, Newcastle, LNCS 3582, 1, 2005.
M. Joseph. Engineering the development of embedded systems, Proc. Formal Methods and Hybrid Real-time Systems, 391-398, 2007.

The first computer I saw was in 1963. It was the TIFRAC, built at the Tata Institute of Fundamental Research. I was studying for an M.Sc. in Physics with Electronics at the University of Bombay (now Mumbai) and a fellow student who worked at the TIFR invited two of us to see 'The Computer'. Getting into TIFR was easy: he had told us to nonchalantly get onto the TIFR bus at its first stop. The bus took us to the back of the building and we asked our way up to his office. He looked pleased, self-important and slightly embarrassed to have us in tow as we walked towards 'The Computer Hall'. I had expected to see something vastly complex but self-explicating, that announced its capabilities to those like us who enquired. And there would be scientists waiting to tell young postgraduates all we wanted to know about the computer. What we saw instead was a room full of open racks packed with circuit modules, wires hanging out here and there and a few people too busy to answer questions. 'You want to see computer? There it is', said one as he walked away urgently. I wanted to know more but there was not even a hint I could take away to think about. If he wasn't going to tell us about the computer, I needed to find out for myself.

One year later, when doing a postgraduate course in electronics in Cardiff, I was introduced to the Stantec Zebra, a vacuum tube computer with a rotary telephone dial for inputting addresses, designed by van der Poel in the Netherlands and made by Standard Telephones and Cables in the U.K. The lecturers encouraged us to study the marvels of the circuitry but I was overwhelmed by the idea of a machine that sequentially executed commands. It suggested that one could perform a task, perhaps any task, by composing the right order of small actions. (I still had a lot to learn about computability.) Programming a computer as complex as the Zebra was not a job for novices like us but eventually we managed to get it to do simple calculations, quite often by accident. Things became clearer a few months later when we were given a chance to write small programs for the much newer Elliott 803 computer which had an Algol compiler, designed and written by a soon-to-be-famous computer scientist. Clearer, perhaps, but not much easier as compiling and running an Algol program meant reading in two very large reels of paper tape for the two passes of the compiler, another for its run-time library and three smaller reels for your program, its intermediate output and its executable. Each reel was easily tangled and torn and any error meant starting again from the beginning. Still, my programming efforts got me used to the idea that writing a program loop was much simpler than a long string of instructions, even for the small problems I tried out.

It may have been partly on the strength of this shaky computing experience, perhaps more persuasively on my surer background in physics and mathematics, that in 1965 I was admitted to do a Ph.D. at the Mathematical Laboratory in Cambridge. Unlike Cardiff where we treated computers like mysterious and wonderful creations that had come our way thanks to the munificence of the haves of the real world, people in Cambridge had been building computers for 20 years. A large one called Titan, partly designed at the Mathematical Laboratory, was the main university computer that had replaced Edsac 2, also designed there. Titan was the first computer to use a 'slave store', the precursor of today's cache memories. Modelling the way a computer's memory hierarchy could be composed of small high-speed stores with large paged memories backed by extended memories became a major interest for me and it was later the subject of my Ph.D. thesis.

Nearby, but in far less space than the two floors needed for Titan, sat a small and elegant Digital PDP-7 mini-computer with large 340 display; probably one of the first to reach the U.K. This was almost as fascinating as Titan as it allowed one to experience writing a program as well as running, debugging it and seeing the output on a large display. I would have spent many more hours on this computer (especially playing noughts and crosses, and trying out its flight simulator program) had its use not been rationed into one-hour slots which had to be reserved in advance. Some of the same excitement took another form a year or so later when the Titan time-sharing system (designed and written by the clever people who sat one floor below me in the Mathematical Laboratory) was released for use. Once again there were sign-up slots for the use of each terminal, but it was possible to get a lot done in a half-hour slot. I not only wrote and tested all my simulation programs using a terminal, I typed in my whole thesis there and formatted it using an early pagination program. The final output came on paper tape which I quasi-legally printed out at the dead of night.

Working through several nights each week and going back to my room only to cook myself breakfast and have a bath, I was able to finish my thesis in three years, comfortably within the period of funding of my IBM Research Fellowship. A year before I finished, I had travelled around India looking at places where I might find a suitable job. I was fortunate to find a position, as a Visiting Member which I took to mean a sort of temporary appendage, at the Computer Group of the Tata Institute of Fundamental Research. I would be back in Mumbai, a city I knew and loved.

In July 1968, I moved out from the garret-like room in the Mathematical Laboratory that I shared with about 3 or 4 others. Two months later I was in a modern office at TIFR, overlooking the Arabian Sea. The rest of the Computer Group found my computing experiences with paper tape to be quaintly English. They had recently got an American-made CDC 3600 computer that used punched cards for input. The real programming heavies each had a magnetic tape with their own version of the operating system. I felt I had a chance to catch up with modern computing and never again need my skills in splicing torn paper tape and punching holes by hand. Three years later, I arranged to buy a new PDP-11 computer (also American-made) for a project. It was the first to come East of Suez and it used paper tape. My skills were in demand again.

I found all sorts of uses for my experience at Cambridge. Rather than existing on what I felt had been the periphery of things in Cambridge, hidden in a small room on the top floor of the Mathematical Laboratory and running simulations of make-believe computer memories on a computer, I was keen to get right into the centre of activity. In Cambridge, the shots had been called by the team that wrote the Titan time sharing system. In Mumbai I realized that, whether I would call the shots or not, there was much more to learn from writing software than in modelling computers that would never be built. I spent the next 12 years happily experimenting with new techniques for designing system programs: operating systems, real-time systems and compilers, many of them ingeniously constructed and some actually used by other people for their own work. I collaborated closely with a new Indian computer manufacturer and at one time was in the privileged position of buying more computers from them than anyone else (I had a generous grant to experiment with building a multiprocessor system).

Building things has its own rewards. Unfortunately, it's not the same as building up a long list of publications. My TIFR bosses were keen to have us build things they could show off to visitors. But when the time came for annual assessments, all they wanted to see was a long list of publications. An average experimental physicist or chemist would produce 10-15 short journal papers a year; a productive computer scientist will strain at just a few good ones. Research administrators don't easily fall for arguments about computer science being 'different', still less that its publication process is more 'rigorous'. Theoretical computer scientists shape up better in this numbers game but systems people like me had to spend years experimenting before they could write a few papers. You could solve the problem by building less software and writing more papers (which most people in academic research ended up doing), or you could move to an institution where you built more programs and wrote even fewer papers. I used my sabbatical leave at Carnegie-Mellon University at Pittsburgh (one of the earliest universities to have a computer science department) thinking about all this while I resisted offers from teams there to join them in writing mountains of code for impossibly ambitious software systems. Instead, acting on a suggestion from the afore-mentioned and by-now-famous computer scientist, I started to think about writing a book about our experiments with the multi-processor operating system that we had designed and built at TIFR. If I did not have enough research papers to impress my superiors, I would hit them with hundreds of pages of a book.

The book came out about two years of hard work after I got back to TIFR. When I saw the first copies, I was outraged that the publisher had shortened the title without consulting me and my two co-authors (who had worked with me on building the system). The smart look of the well-known red and white livery on the cover partly mollified me and spurred me on to the next step in my plan. I sought an appointment with the Director and dropped a copy on his desk.

'Ah', he said, sagaciously, looking around me at the Arabian Sea. 'A book.' He paused, making a tent of his fingers. 'Of course it's not research.' He paused again. 'I suppose it can be used as a college text somewhere.' I think he meant that a text book was probably a fitting end to my efforts but it was not what a scientist at an Institute of National Importance should be producing. Good scientists knew they didn't have the time to write books.

I had spent 16 years at TIFR and it was time to move on. I had learned a lot about science through reading and endless discussions with my physicist and biologist friends but my computer science had no future there. We were firmly hypothetico-deductive and had strong views about what experimental work qualified as science and what was mere knob twiddling and meter watching. Understanding this distinction was important to me because computer science was then veering between pure theory and more practical work that seemed to have a different life of its own. My own work fell somewhere in between. Which of these was 'science'?

I was far more interested in the physics and mathematics done by the others at TIFR than they were, or are, in computer science ("It's all Fortran programming, isn't it?", one of them asked me recently). They felt it was natural that people would be interested in their work, given the self-evident importance of their subjects; I felt quite outnumbered. Writing the book spurred me to write papers and my average went up to the heady level of one or two a year. I also stopped building things and found life much simpler and easier. It's a lot more interesting to tell people about a paper you have written than a system you have built. An early poem by Clive James published in Granta talks about the 'highs and lows of hand to mouth'. Well, there are highs and lows in nerd-dom too.

I moved on. A former colleague and friend from Cambridge had written to me about an open chair at Warwick University. I applied for and was offered the position, all rather quickly. My family reluctantly agreed to join me in the move which promised to disrupt our family life, school life and social life. I thought it would be for about five years after which we could pick up the pieces again. We would have regrets at what we left behind but I convinced myself we would begin to feel that the move, difficult in the first year or two, had been for the better. I think I was eventually right, but it's for them to say more about this, not me.

I learned to teach, large and small classes. My first lecture at Warwick was to teach introductory programming to a class of about 300 in a packed lecture room which even had people sitting in the passages. The crowd was not there to see the new professor of computer science; it was there because the course was listed in far too many different degree programs. I walked to the stage and turned around to face what seemed like a many-headed student ectoplasm. I grinned at it, it glared back at me. The ones at the back could just hear me but not read what I wrote on the board, unless it was in foot-high letters. My carefully prepared slides could be seen by only the lower half of the student mass. The class rumbled and groaned. There was little I could do except pretend that we should collectively overlook our minor misfortunes. They felt it was all my fault.

A major error was my assumption about the level of the students. Ignorance and a teaching experience limited to occasional classes to good postgraduate students had made me believe that a university class would be packed with well-informed, questioning and inquisitive people who would pounce on interesting exercises and come back with wonderful solutions at the next lecture. Instead, I found first year students who expected to be told what they would be taught and why, then taught it and finally told what they had been taught. There were revision classes for those who still did not get it. Examination questions were divided into parts with the credit for each clearly marked. There were no exploratory questions, none that expected anything other than one precisely defined answer.

I learned to be patient and think about how a student would learn new material. Over time, I learned that the first year adolescent of one year became the questioning student of the next year and the mature and well-rounded adult of the third year. I learned that students need a mentor, someone to talk to. A number of them had less than peaceful family lives, some were in more financial and emotional trouble than one could have thought possible for an eighteen or nineteen-year old. They liked talking to someone who would listen and not judge them, who occasionally actually helped them solve a problem. I was never as riotously successful as a colleague who was presented with a bottle of whiskey at the end of his first course but I learned to respect and like my students. Perhaps some of them shared the feeling.

I quickly became familiar with another important part of academic life: writing ambitious research proposals in ways that would make them successful, managing research grants so that there would be always enough results to show as preparatory research for the next proposal. Getting research money was important: it gave you the freedom to hire postgraduates, to buy equipment and to travel. The university overheads on the grants also bought you a small degree of respect from the administrators who were adept at playing an academic off against someone they claimed was far more successful and so more worthy of the crumbs from their table.

My research began to get clearer objectives: the use of formal techniques in real-time and fault-tolerant programs (later the title of a conference series I started at Warwick) was full of interesting problems with just a few research groups working on them. This meant there was time to try out different solutions and enough interested people at different universities across Europe and the United States to talk to. Some of the work I had done at TIFR was also beginning to be noticed so I could start to work with confidence on more ambitious problems. A number of postgraduates worked on these research projects and moved on, some with newly acquired Ph.D.'s. A few became friends and one and his family have been close family friends since the time he first came to work with me.

I learned to navigate through impenetrable university committees. At the first professorial board meeting I attended, my neighbour passed me a note which asked 'Are you an Oxford man?' I wrote 'NO' and passed it back to him, seeing no reason to volunteer any more information. He turned away sadly and never looked at me again. The people most successful in university committees were those who first made simple things sound extremely complicated and then allowed others to congratulate them on finding a solution. It was important to mimic them to get anything done. I learned one more life skill.

The planned five years at Warwick had become ten. Was I going to stay at Warwick until I retired at 67, still far away, or return to India? Return to what in India? I made one or two tentative approaches and was glad to not have to go much further with them. Then, thanks to the generous help of an old friend, things began to fall into place. There could be a position for me at Tata Consultancy Services, perhaps even in their research centre. It would mean moving out of academic research and into industrial research. They were prepared to wait for the year it would take me to wind up work at Warwick and for us to make sure our son and daughter were well settled at their respective universities.

When the time came, on a wonderfully bright and sunny autumn day, we left for Heathrow airport accompanied by our family cat who was partly sedated and groaned occasionally in an unfamiliar airline-approved box. I was filled with a sense of loss for everything we had worked hard to bring together, from running our large Victorian house and creating a passably attractive garden from what had looked like wasteland when we moved in, to finding a place for ourselves in England. I return frequently to England and each time feel the same sense of ease that comes from being in a country and among people that I know well and trust.

The assistance provided by TCS in making the move back to India helped enormously; they even thought of alerting the airline that we would be travelling with our cat. Starting to work at the TCS R&D centre was altogether less stressful than the move to Warwick had been. But as I settled down, I realised that there was a lot I had to learn and unlearn. In academic computer science there's a myth that people in industry do mundane jobs and are paid altogether too much for doing them (this especially rankles with poorly paid university teachers). I found that there were indeed mundane jobs and people happy to do them but across most of the company there were large teams of talented people building incredibly complex systems in quick time. These were not experiments they would write papers and books about, they were systems that had to work if the company was to be paid. And work they did, even if meant spending 18 hours a day to 'finish a deliverable'. People did not have the time to learn dinky little tricks from layabouts like us in R&D, they needed things that could be plugged in and forgotten. And they were happy to forget about us in R&D if that made their work any easier.

Over time, we in R&D became better at judging where our contributions were most likely to succeed. We were still wrong at times but we were also surprised with unexpected successes gained with very little effort. We discovered that the most effective way to gain a software developer's attention was by hearsay, from peers and most effectively from client companies. If the IT manager of a client company told a team about something they had heard from us, the team would complain: 'Why didn't you tell us before you talked to the client?' But they would begin to listen. And within R&D spirits rose when people discovered that their work had a place in the pantheon of software research, that they had been able to solve problems that others had not even attempted.

As part of the senior management team of the company, I had a wonderful vantage point. I learned about teams struggling with slippery tasks that kept being redefined by the client (this was called requirements creep, no reference to the client's IT manager). I learned about battles grimly fought and victories grudgingly conceded and won. I learned also about activity-based costing and economic value added, even that the most recent release of a major database management system did not cater for nested transactions.

My way of life changed dramatically. I was no longer an academic who came home every evening at seven and did gardening all weekend. My weekends merged into the week. There was a lot of travelling abroad, which meant early starts and late endings that sometimes overlapped. On one not unusual occasion I started the day with a pre-pre-breakfast meeting at 6:30am (a pre-breakfast and breakfast meeting were to follow) and ended at 11pm in a car park in Texas from where I was driven through the night for a brief halt before a pre-breakfast meeting in North Carolina. And wherever I may be and whatever else I may be doing, normal work in Pune had to continue. I became used to getting up at 4am to type my way through on-line approvals, to reply to e-mail messages ('No, you cannot see me today, I am in Sioux Falls') and have a sanity-restoring session in the hotel gym before starting the next day's work. Being at home in Pune was only slightly different since calls could start at 6am and continue well after 10pm. And this was just my slightly off-centred life. The CEO had a much, much harder time. So much for the mundane work that academics thought was all people did in industry.

TCS had 8000 employees when I joined and over 100,000 by the time I retired 10 years later. It was no longer a small company thinking big; it had acquired the manners and practices of a large company. TCS was the first Indian IT company and for it to stay the largest took hard work. It was a unique experience to watch how the company, and indeed the Indian IT industry, changed, even more so to have had a part in the change. On my retirement from this world of excitement, I consoled myself by remembering that the ripe age of 64 or 2⁶, was a well-rounded time for a computer scientist to lay down arms since getting to 2⁷ or 128, was beyond current medical science.

Time once again to learn new things, but now about architecture and construction. There is a large new TCS campus coming up on the outskirts of Pune and I have been working with the architects, engineers and consultants in planning what has now reached the first stages of construction. I have learned a little about inverted beams and rock anchors, about post-tensioned slabs and cantilevered floors, more about data centre design and air-conditioning. I am always ready to throw in a disparaging comment about honeycombing and bad finishes. And I have enjoyed thinking about landscape design on a Capability Brown sort of scale: far, far beyond the small garden plot I had planned, nurtured and loved in our house in England. And there's still so much more to learn.