Tag: computing

Book Review: Grace Hopper – Admiral of the Cyber Sea by Kathleen Broome Williams

After reading Broad Band by Claire L. Evans, about women in computing, I realised Grace Hopper was important, so I thought I’d hunt out a biography. I found Grace Hopper: Admiral of the Cyber Sea by Kathleen Broome Williams. Unusually I bought it second hand – my copy came from the Richard Stockton College of New Jersey Library Pomona, and has an austere, maroon cover.

Grace Hopper was born in New York City in 1906, she died in 1992. An undergraduate in mathematics she started a career in teaching at Vassar College but joined the Navy after the US joined the Second World War. She was posted to work on the Mark I computer at Harvard. She subsequently wrote the first software compiler, and was instrumental in the creation of the COBOL programming language. After “retiring” she then had a long career in the US Navy working on standardising their computing systems. After finally retiring from the Navy she worked for DEC for a few years until her death at the age of 86. She finished her career a rear admiral in the US Navy and has a battleship named for her (the USS Hopper) amongst numerous other rewards.

Grace Hopper gives some feel as to how it was to grow up in a relatively wealthy New York City family. The Hopper family had a holiday home in Wolfeboro, New Hampshire which, when she was small, was a day and a half travel to reach from New York City. She was brought up to be self-sufficient and trained in mathematics. Her father worked in insurance and was a double amputee – he wanted to make sure his children could fend for themselves should he die although he survived to a fair age.

Hopper studied mathematics first at Vasser College before going to Yale for a PhD in mathematics. She married Vincent Hopper in 1930, they bought a summer home of their own in Wolfeboro for $450 – part of a wedding gift. They were divorced in 1941 although it was not something she talked about, despite giving numerous interviews later in her live. Grace Hopper does not indicate the grounds for her divorce. After gaining her degree she became a lecturer in Vasser College where she was an excellent and committed teacher.

When America joined the war she was keen to serve in the US Navy which she achieved following some struggle. Fundamentally they were not keen to employ women, furthermore she was older than the Navy typically recruited, technically underweight and in a reserved occupation (as a lecturer in mathematics). Eventually she joined in 1942, and finally entered service in 1944, after training. She was proud to work in the Navy throughout her life and even whilst employed in industry she continued in the reserve service. In her Navy service she found a link with the dignitaries, including royalty, she met in later life.

Her naval placement was with the Mark I computer at Harvard, invented by Howard Aiken and built by IBM. It was the first programmable electromechanical computer in the world. Based on the slightly older relay technology rather than valves found in successors it was used principally for ballistic calculations as well as calculations of various function tables. Aiken was pretty tough to work with but Hopper clearly knew how to handle him and held him in high regard. She worked on many of the Mark I’s smaller programming jobs as well as doing more than her share of documentation and report writing.

One issue with the Mark I was that it was programmed with paper tape, the programs and data are stored as a pattern of holes 3-4mm across punched out the tape. There was a lot of paper around, as well as the disks of paper punched out from the tape. Sometimes one of the punched out disks was re-united with a hole causing an error, as Hopper pointed out “a hole getting back into a hole”!

After the war it was clear she would not be able to continue at Harvard, so she let to work on the UNIVAC at the Eckert–Mauchly Computer Corporation, later bought by the Rand Corporation and then IBM. Through Hopper’s life we see the birth and maturing of the new computing industry.

Hopper realised there was a need for standardisation in programming languages. There were an increasing number of different types of computer around, and the maintenance and programming of such computers was a bigger job than had initially been realised. Standardisation reduces this problem because a program written for one computer can be run on another. This is how COBOL was born, the Navy sponsored the Committee on Data Systems Languages (CODASYL) which created the COBOL programming language which was derived from Hopper’s FLOW-MATIC language developed for the UNIVAC.

As a scientist and software developer for 30 years I was scarcely aware of COBOL, yet it comprised approximately 80% of running code in the late nineties, according to Gartner. I imagine that figure has not dropped greatly. There is clearly a huge body of COBOL “dark matter” that software developers don’t talk about. The reason for COBOL’s obscurity seems to be the disdain of the academic computer science community, FORTRAN – born at the same time – suffers a similar disdain.

During her time working on UNIVAC Hopper maintained her Navy connection through a reserve position, and in 1966 – at the age of 60 – she retired from the reserve to work full time for the Navy at the Pentagon. She continued to work in the Navy until 1986 when she left to join DEC, at the age of 80!

In this book Grace Hopper comes out as an exceptional character. Her great skills were rooted in teaching, the drive to build a compiler was partly making her own life easier but also democratising the process of programming. She also saw the importance of raising a generation of programmers. She was very personable but seemed to have virtually no personal life. She drank moderately and smoked heavily for most of her life, and clearly had a bit of a hording problem towards the end. She was a life-long Republican and saw little value in the women’s rights movement – her own enormous success giving her the impression that there was no inequality to address.

Throughout her life, well into the period others might consider retiring, she was was engaged in a full schedule of public speaking. She gained many rewards, and a great deal of recognition in her lifetime.

I really enjoyed this book, the only place my interest lessened slightly was in the chapter describing administrative reorganisations of the US Navy. I am in awe of the achievements of Grace Hopper.

Book review: Broad Band by Claire L. Evans

Broad Band by Claire L. Evans book cover. Cream background with a silhouette of a woman made from circuit boards

This review is of Broad Band by Claire L. Evans, subtitled The Untold Story of the Women Who Made the Internet. It is arranged thematically with each chapter focusing on a couple of women moving in time from the first chapter, about Ada Lovelace in the 19th century, through to the early years of the 21st century. The first part of the book covers the early period of computing up to the mid-sixties, the second part the growth of networked computing through the seventies and eighties with the final part covering the rise of the World Wide Web and services devoted to women.

The first chapter introduces us to Ada Lovelace, sometimes heralded as the first programmer which is a somewhat disputable claim. More importantly she was clearly a competent mathematician and excelled in democratising and explaining the potential of the mechanical computing engines that Charles Babbage was trying, and largely failing, to build. More broadly this chapter covers the work of the early human “computers”, who were often women, employed to carry out calculations for astronomical or military applications. Following on from this role, by 1946 250,000 women were working in telephone exchanges (presumably in the US).

Women gained this role as “computers” for a range of reasons. In the 19th century it was seen as acceptable work for educated women whose options were severely limited – as they would be for many years to come, excepting war time. The lack of alternatives meant they were very cheap to employ. Under the cover of this apparently administrative role of “computer” women made useful, original contributions to science albeit they were not recognised as such. Women were seen as good at this type of meticulous, routine work.

When the first electronic computers were developed in the later years of the Second World War it was unsurprising that women were heavily involved in their operation partly because of their previous roles, and partly because men had been sent to fight. There appears to have been an attitude that the design and construction of such machines was men’s work and their actual use, the physical act of programming was women’s work – often neglected by those men that built the machines.

It was in this environment that the now renowned Grace Hopper worked. She started writing what we would now describe as compilers to make the task of programming computers easier. She was also instrumental in creating the COBOL programming language, reviled by computer scientist in subsequent years but comprising 80% of the world’s code by the end of the 20th century. The process that Hopper used to create the language, a committee involving multiple companies working towards a common useful goal, looks surprisingly modern.

In the sixties there was a sea-change for women in computing, it was perceived that there was a shortage of programmers and the solution was to change programming into an engineering science which had the effect of gradually pushing women out of computing through the seventies. It was at this time that the power of computer networks started to be realised.

The next part of the book covers networking via a brief diversion into mapping the Mammoth Cave system in Kentucky which became the basis of the first network computer game: Colossal Cave Adventure. I was particularly impressed by Project One, a San Francisco commune which housed a mainframe computer (a Scientific Data Systems 940) which had been blagged from a company by Pam Hardt-English. In the early seventies it became the first bulletin board system (BBS) – a type of system which was to persist all the way through to the creation of the World Wide Web (and beyond). Broad Band also covers some of the later bulletin board systems founded by women which evolved into women’s places on the Web, BBS were majority male spaces for a long time. In the meantime Resource One also became the core of the San Francisco Social Services Referral Directory which persisted through until 2009, this was a radical innovation at the time – computers used for a social purpose outside of scientific or military applications.

The internet as we know it started with ARPANET in 1969. Broad Band covers two women involved in the early internet – Elizabeth (Jake) Feinler who was responsible for the Resource Handbook – a manually compiled directory of computers, and their handlers, on ARPANET. This evolved, under her guidance, to become the WHOIS service and host.domain naming convention for internet addresses. The second woman was Radia Perlman, who invented the Spanning Tree Protocol for ethernet whilst at DEC in 1984.

This brings us, in time, to the beginning of the World Wide Web. The World Wide Web grew out of the internet. Hypertext systems had been mooted since the end of the Second World War but it wasn’t until the eighties that they became technically feasible on widely available hardware. Broad Band cites British Wendy Hall and Cathy Marshall at Rank Xerox as contributors to the development of hypertext systems. These were to be largely swept away by Tim Berners-Lee’s HTML format which had the key feature of hyperlinking across different computers even if this made the handling of those links prone to decay – something handled better by other non-networked hypertext systems. The World Wide Web grew ridiculously quickly in the early nineties. Berners-Lee demonstrated a rather uninspiring version at HyperText ’91 and by HyperText ’94 he was keynote speaker.

There is a a brief chapter devoted to women in gaming. Apparently Barbie Fashion Designer sold 600,000 units in 1996 more than Doom and Quake! There was a brief period when games were made very explicitly for girls – led to a degree by Brenda Laurel who had done extensive research showing boys strive for mastery in games, whilst girls were looking for a collaborator to complete a task. These ideas held sway for a while before a more diverse gaming market took hold which didn’t divide games so much by gender.

It is tempting for me to say that where women have made their mark in computing and the internet is in forming communities, communicating the benefits of technology and making them easier to use – in a reprise of the early pioneering women in science – because that is what women are good at. However, this is the space in which women have been allowed by men – it is not a question of innate ability alone.

I found this book really interesting, it is more an entry point into the topic of women in computing than a comprehensive history. It has made me nostalgic for my computing experiences of the eighties and nineties, and I have added a biography of Grace Hopper to my reading list.

Book review: The Mythical Man-month by Frederick Brooks Jr.

mythical-man-monthNext up The Mythical Man-Month: Essays on Software Engineering by Frederick Brooks Jr.

This is a classic in software engineering which I’ve not previously read, I guess because it is more about software project management rather than programming itself. That said it contains the best description I have seen as to why we love to program, it is a page long so I won’t quote it in full but essentially it divides into 5 parts.

  1. the joy of making things;
  2. the joy of making things which other people find useful;
  3. the joy of solving puzzles;
  4. the joy of learning;
  5. the joy of working in such a malleable medium;

The majority of the book was written in the mid-seventies, following the author’s experiences in the previous decade, delivering the IBM OS/360 system. This means it reads like Asimov’s Foundation in places, dated technology, dated prose, but at the same time insightful. This is the 20th anniversary edition, published in 1995 which includes 4 new chapters tacked on the end of the original book. Two of these – No Silver Bullet and No silver Bullet – refired are a couple of essays from the eighties around the idea that there are no silver bullets to making software production greatly more efficient – this is in the context of hardware improvements which were progressing at unimaginable speed – Brooks was looking for routes to similar evolution in software development.

The other two new chapters are a bullet point summary of the original book and a retrospective on the first publication. The bullet point summary chapter removes the need for my usual style of review!

The core of the book is the observation that large software projects frequently fail to be delivered as scheduled. There then follow some chapters on addressing this issue. The Mythical Man-Month chapter is the most famous of these, it essentially says the enticing idea of throwing more people at a problem will speed up delivery is wrong. In some cases this is trivially true – you may have seen the example from the book that two women do not produce a baby in 4.5 months rather than 9 months for a single woman. The reason increasing team numbers for software development similarly fails is the cost in time of effective communication between more people, and the cost in time of onboarding new people. Despite our knowledge we still routinely under-estimate programming tasks, largely through mis-placed optimism.

As mentioned above, The Mythical Man-Month is quite dated. The anachronisms come in several forms, there is the excitement over computer text-editing systems – a revelation at the time of OS/360 was being developed. There is a whole chapter devoted to memory/storage usage which I am pretty sure is no longer a concern except in a few niche cases. There is quite a lot of discussion of batch versus time share systems, from a time when there were one or maybe two computers in a building rather than one on every desk, even one in every pocket. There are role anachronisms, where a team has two secretaries and a "Program Clerk" whose role it is to type stuff into the computer!

There are some places where Brooks describes practices which sound quite modern but differ slightly differently to the current sense. So "architecture" in his parlance is more about interface design than "architecture" as we would describe it now. There is some pair-like programming but it has a leader and a follower rather than equals. Agile is mentioned but not in the modern sense.

I was interested to read Brooks disdain of flowcharts. I remember learning about these – including proper stencils from my father – a programmer trained in the early sixties. Brooks argument is that the flowchart is useful for programming in low-level languages like assembler but not useful for high level languages – particularly those using the "structured programming" approach which was new at the time. Structured programming replaces the GOTO statements found in earlier languages with blocks of code executed on if – then – else conditions and similar.

In a chapter entitled Plan to throw one away Brooks talks about the inevitability of the first iteration of a product being thrown away to be replaced by a better thought out version although he caveats this a little by allowing for progressive replacement. He notes that maintenance costs can be 40% of original cost and each new version fixing bugs has a 20% chance of introducing new bugs. This means the progressive replacement approach is a losing game.

In some ways this book is depressing, nearly 50 years after it was written software projects are still being delivered late with great regularity. On a more positive note I believe that the widespread availability of web APIs and online module libraries (such as PyPI for Python) can produce the sort of large uptick in programmer productivity that Brooks’ felt was out of reach. Perhaps this will not be seen as a productivity boost since it simply means the systems we aim to build are more complex and the number of lines of code measure of code does not capture the complexity of external libraries. The consistent user interfaces provided by Mac OS and Windows are also something Brooks was looking for in his original publication.

Is The Mythical-Man Month still worth reading? I’d say a qualified "yes", the issues it describes are still pertinent and it draws on quantitative research about teams of software developers which I believe will still be broadly relevant. It is a relatively short, easy to read, book. It gives a glimpse into the history of computing. On the downside, much of the incidental detail is so far out of date to be distracting.

Book review: Masterminds of Programming by Federico Biancuzzi and Shane Warden

mastermindsThe next review in my work related books thread is of Masterminds of Programming by Federico Biancuzzi and Shane Warden. The subtitle, Conversations with the creators of major programming languages, is a good summary of the contents. The book is an edited transcript of interviews with the creators of major programming languages.

Frequently the conversation is with a single person but in a couple of cases two or even three people are interviewed. This is one small failing of the book because particularly where they interview three people the resulting chapter is very long and a bit repetitive.

There is a valid question to ask as to whether languages can be so closely tied to single individuals, and in the afterword the authors touch on this saying that one of the recurring themes was that the people they interviewed succeeded because they surrounded themselves with brilliant people. Some of these languages started off as one-man exercises but most grow from collective academic or corporate efforts, and even the one-man band languages developed a fairly formal community.

The languages covered are object-oriented languages (C++, Objective-C, Java, C# and Eiffel), functional languages (ML, Haskell, APL), glue languages originally designed to occupy the space between Unix and C (Awk, Lua, Python, Perl), languages designed for embedding (Forth and PostScript). Dartmouth Basic, SQL and UML are basically their own things. To be honest UML does not really fit into the book in my view since it is a formal design description language rather than an executable programming language. The languages were created between 1964 (Dartmouth BASIC) or maybe 1957 (for APL) and 2000 (C#).

I was sad to note the absence of a chapter on FORTRAN but John Backus, the inventor of FORTRAN died in 2007 – a couple of years before the book was written. Also there are no women interviewed in this book, a quick search reveals there are a number of programming languages invented or co-invented by women. COBOL, invented by Grace Hopper would be a prime candidate here but she died in 1992. Small Talk which inspired a lot of object-oriented languages was co-invented by Adele Goldberg and LOGO co-invented by Cynthia Solomon would fit rather well into the book.

The interviewers clearly had a set of questions which they asked each interviewee and the varying results indicate which questions chimed with the interests of the interviewee. The topics included concurrency, how to manage feature requests for languages, working in teams, debugging, software engineering and teaching.

The authors of the object-oriented languages (C++, Objective-C, Java, C# and Eiffel) are somewhat at each others throats. However, they are all pretty clear that object-orientation is the way forward for large software projects although they see encapsulation rather than inheritance or reuse as the key benefits it brings. There is a degree of condescension towards those languages that they perceived to have been successful as a result of marketing.

The authors of the functional programming languages are more interested in formal specification, I feel I should learn more about type theory. I have looked at Haskell in the past, and found it a bit challenging, however ideas from Haskell and other functional programming languages have made it into Python, my preferred language. The chapter on APL was entertaining, it was conceived and developed as a coherent formalised system for describing algebra the authors did not touch a computer for a number of years after “development” started in the mid-fifties. It is written as symbols which are challenging to enter on a conventional keyboard, you can see it in action here.

Tedd Codd’s relational database design was core to the success of SQL, and is largely why it has not been replaced. SQL was designed alongside IBM’s System R but Oracle produced the first commercial SQL engine.

I learnt a few random facts from the book which I can’t write as a coherent story:

  • Charles H. Moore – author of Forth: “Legacy code may be the downfall of our civilisation”;
  • Awk is an acronym of its authors names, Alfred Aho, Peter Weinberger and Brian Kernighan;
  • Tom Love – co-author of Objective-C – “100,000 lines of code fills a box of paper and requires 2 people to maintain it. Test cases should be another two or three boxes.”!

The book would have really benefited from some sample code in each language, perhaps in the manner of Exercises in Programming Style which implements the same algorithm in different programming styles. I picked up Beautiful Code by Andy Oram and Greg Wilson, interviews with programmers, for my reading list. As well as The Mythical Man-month by Frederick P. Brooks, Jr which I probably should have read years ago.

I found this book really interesting, in part as a way of understanding how the programming languages I use every day of my working life came into being but also to understand the mindset of highly skilled programmers.

Book review: Software Design Decoded by Marian Petre and André van der Hoek

66-ways-expertsSoftware Design Decoded: 66 Ways Experts Think by Marian Petre and André van der Hoek is my next read.

I picked it up as a recommendation from The Programmer’s Brain by Felienne Hermans. It is an odd little book, something like A6 format with 66 pages containing a short paragraph or two on the behaviours of experts in software design. Each page dedicated to a single thought. There are sketches scattered liberally though the book by Yen Quach who is credited in the author biographies.

Although it does not have a contents page or index, Software Design Decoded is divided into "chapters":

  • Experts keep it simple
  • Experts collaborate
  • Expers borrow
  • Experts break rules
  • Experts sketch
  • Experts work with uncertainty
  • Experts are not afraid
  • Experts iterate
  • Experts test
  • Experts reflect
  • Experts keep going

I found this book reassuring as much as anything, and it also gave me some things to think about. Reassuring because it turns out I share habits with expert in software design, which must be a start to being an expert! I write quite a lot of software (for data analysis and data builds) but design tends to come as an afterthought.

I think the things I already do are to build something even if it isn’t the final form, I was interested in the comment about avoiding over-generalisation. The element I am missing here is to learn from this initial form and build something better (potentially discarding what I’ve already done). I also do a fair bit of testing, although in this book testing is wider than just software unit tests or even integration tests, it is about testing preconceptions and testing with the user.

I also liked the comment on focusing on the needs of the key stakeholders where the key stakeholders are the end users, this is a recurring theme – that the end users are the key focus, and them using the product/software are when the job is done.

Always learning gets a recommendation as well as not being afraid to use things in manners other than that intended.

I was interested to note the comments on experts forever sketching since it is something I scarcely do, sometimes a write sequences of tricky bits of code with the odd arrow. I remember learning how to draw flow charts in the late seventies but rarely use the skill (certainly not with all the proper symbols). Software Design Decoded is slightly contradictory on this, in one place experts sketch abstractly as an aid to thought with the sketches meaningless beyond the moment, and in another the sketches are kept for reference later and hence clear and well-labelled.

Notation also gets a couple of mentioned, I take this as a formalised system for naming things – something popular with physicists where the right notation is the difference between a page of formulae and a single line. I’m not really aware of using this in my own practice. Despite repeated attempts at object-oriented design I still tend to be quite "procedural".

I’m still in the "learning" phase of collaboration, for the first time in a while I’m working on code with other people (and it is a bit of a shock for all concerned), I still can’t abide by meetings but the experts can’t abide some of them (the ones with no direction).

I found this a bit of a "feel good" book, I share at least some of the habits of software design experts! I probably wouldn’t buy it for a personal read but if you have a coffee table in your software company this book would fit right in.