Japanese

The 5th Installment
Looking Back on My Software Development Experience

Chuzo Akiguchi,
Professor, Master Program of Information Systems Architecture

 I made my entry into the world of software several years after micro processors became available, and about the time it became possible to build a computer in a university lab on your own. In the beginning, you input a program written in assembler language on a paper tape, and fed it into the computer together with a library program and executed it. It was a time when all the necessary tools for software development, assemblers, linkers, compilers, disc operating systems, and others had to be created on your own, as a research project in the lab. It was around the same time that Microsoft and Apple were born.

 When I started studying programming, source codes for various programs for microcomputers written in assembler began to circulate, and reading these codes was the best method for learning programming. One of the most impressive codes of those days was a Lisp interpreter for the Intel 8080 processor, written in about 500 lines. It read in an S-expression Lisp program in a read-eval-print loop and the program operated in a memory space of mere 4K bytes including a domain of 800 cells. Of course, it included garbage collection as well. It was good enough to play Towers of Hanoi but couldn’t actually handle any working programs, but its simple design and implementation amazed me, and I remember wishing that I could write such a kind of program someday. I believe this is one of the basic aspirations that an IT architect should have.

 I think having had the experience of reading such beautiful code in my infant days as a programmer influenced my concept of the value of programming immensely. Programs should not just work, they must work correctly, without any waste, and must be simple and clear. Pursuing this to the extreme will result in beautiful code. I think the seeds of this kind of thinking were embedded into my way of thinking. In those days, the computer use environment was quite restricted in terms of CPU time. This forced us to carefully design the data structure and the algorithm, and many hours had to be spent on desk top debugging and review. As a result, I have only experienced a few difficulties in debugging during actual computer use, and was able to respond to design change requirements quite flexibly. I also think this process trained me to shed waste and pursue clarity.

 After making software development my vocation, I became involved in R&D for a Computer Aided Software Engineering (CASE) system which assists R&D in the area of software production technology. In the initial years, I was able to experience upstream design, programming, test and user release, but as I went up the job ladder and the share of administration work increased, I became farther from actual programming. I was reluctant to take up a management position, but this was inevitable, being part of an organization. So I continued programming as a personal hobby. Most of them were prototyping of pending issues at work or development of programming support tools. They used a little bit of ingenuity and were aimed at improvements in issues of productivity or quality. I may have a chance to reveal them someday.

 When I heard that this school was looking for practicing educators able to provide education and training to educate highly qualified people in software development, on its inauguration three years ago, it sounded to me like a call from heaven. Rather than managing large projects in a company, I believed nurturing new IT workers would prove to be a bigger opportunity for making a contribution. Above all, this would provide me with an excuse for returning back to being an active programmer. I am able to fully utilize object oriented development methodology and development languages such as Java, ruby, UML, and implement agile development processes for R&D themed PBL education for an education software development environment. I wish to retain the youthful mentality I had 20 years ago, and to approach PBL education in software development as if I were speaking to myself 30 years ago, and hope to further improve its methodology.

PAGE TOP