The Third Bit

Between October 2005 and January 2006, the ACM polled its professional members, asking them to nominate and then vote for books they considered classics. The final list is:

1. The Elements of Programming Style
2. Classics in Software Engineering
3. Theory of Parsing, Translation and Compiling
4. Pascal User Manual and Report
5. Computer and the Brain
6. Selected Writings on Computing
7. Smalltalk-80: The Language and Its Implementation
8. Compiler Construction
9. The Relational Model for Database Management: Version 2
10. A Programming Language
11. Formal Languages and Their Relation to Automata
12. Writing Efficient Programs
13. Computation: Finite and Infinite Machines
14. The Multics System
15. Operating System Principles
16. IBM System/360 Principles of Operation
17. Mindstorms
18. The Architecture of Concurrent Programs
19. Structured Programming
20. 201 Principles of Software Development
21. Artificial Intelligence
22. MacIntosh Human Interface Guidelines
23. Cryptography and Data Security
24. Essays in Computing Science
25. Anatomy of LISP

Of these, I’ve heard of seven, and read five.

Books

Several 49X alumni and former members of the DrProject team have graduated from the University of Toronto in the past two weeks — congratulations to you all. I’d especially like to congratulate Sean Dawson, who received the Silver Medal from St. Michael’s College today — well done, Sean.

DrProject, Learning

Back in the day, there were bumper stickers saying, “It’ll be a great day when education gets all the money it wants and the Air Force has to hold a bake sale to buy bombers.” Well, the web might move us a little closer to that. DonorsChoose matches teachers who need resources, experience opportunities, and other support with public-spirited individuals willing to make micro-donations. How long until something like this allows taxpayers to hypothecate their contributions to their nation’s finances?

(via Aetiology)

Uncategorized

Pat Smith and Greg Lapouchnian (both former 49X project students) have written a two-part article on the Spring framework for Red Hat Magazine. The first part is now up on the web—congrats, guys.

Uncategorized

Most modern desktop and web applications are based on a three-part design pattern called Model-View-Controller, or MVC. As their names suggest, the two books reviewed here tackle the first and second parts of this paradigm, leaving the third—the business logic—to others.

Ambler and Sadalage’s Refactoring Databases delivers exactly what you’d expect: a catalog of things you can do to clean up the organization of a database. The first five chapters focus on the “how”, and cover such things as regression testing, bundling refactorings together to minimize the impact on running systems, and how to negotiate with other parts of the development team. Some of the points the authors make, such as “keep everything under version control”, are fairly general, but others, such as “prefer triggers over views or batch synchronization”, are clearly the fruit of bitter experience.

Chapters 6-11 then present dozens of refactorings grouped under the headings “Structural”, “Data Quality”, “Referential Integrity”, “Architectural”, “Method”, and “Transformations”. The format is similar to that used in other books on patterns and refactorings: after a discussion of motivation and tradeoffs, each section analyzes the mechanics of both both schema update and data migration. There are lots of code samples and diagrams, and plenty of cross-references.

Refactoring Databases is cleanly written and well indexed. My only complaints are very minor: I would have liked to have seen more discussion of how to cleanse data before starting to refactor (although I’ll admit that probably deserves a book on its own), and—well, does any book really need four forewords? Those are very small nits, though; I think the book is very useful, and I’m grateful to Pramod and Scott for writing it.

I’m also grateful to Stephen Few for Information Dashboard Design. If you’ve been following the DrProject saga, we added a progress dashboard last summer, only to take it out when it came time to deploy. The major reason was the difficulties we were having getting libraries installed on the university’s servers, but we were also unsatisfied with the kind and volume of information being displayed.

Judging from Few’s book, a lot of other people are unsatisfied with their at-a-glance information displays too. In this understated yet effective book, he presents guidelines for creating “eloquence through simplicity”. Some of the principles apply to any kind of GUI; others are specific to the problem of drawing people’s attention to things that need attention. Like his designs, Few’s writing is unadorned, but not plain—if he was a furniture maker, each chapter would be a Shaker chair or side table. When the time comes to put the dashboard back in DrProject, this book will be our starting point.

Now, if only I could persuade the authors to pool their talents, and write a book about refactoring GUIs…

---

Scott W. Ambler and Pramod J. Sadalage: Refactoring Databases: Evolutionary Database Design. Addison-Wesley, 2006, 384 pages, 0321293533.Stephen Few: Information Dashboard Design. O’Reilly, 2006, 223 pages, 0596100167.

Books

…here’s a belated photo of the DrProject team from last summer. One is in grad school, two are headed to Microsoft, one and a half are in England, and the last is working for me again this summer.

DrProject

According to Wikipedia, Romanticism was “…a secular and intellectual movement in the history of ideas that originated in late 18th century Western Europe. It…was in part inspired by a revolt against aristocratic social and political norms of the previous period, as well as a reaction against the rationalization of nature by the Enlightenment…It stressed strong emotion…, legitimized the individual imagination as a critical authority…, and overturned some previous social conventions.”

That’s one view, anyway. Another is that Romanticism was not so much a reaction against the Enlightenment as a counter-strike by those who couldn’t keep up with it. Before the birth of quantitative experimental science, people could organize their world-view based on whatever patterns or similarities struck their fancy; anyone could have an opinion on the nature of motion or the origin of lightning.

Newton, Lavoisier, and others changed that: if you wanted your opinions taken seriously in 1800, you had to be intelligent enough to master calculus, and patient enough to measure foul-smelling gases a gram at a time. Most of the fine young things of the time were neither, so they did what fine young things always do when they’re losing an argument: they moved the goalposts. “Numbers? Equations? Pfah! My dear sir, they’re so cold. And this ‘utility’ you’re so obsessed with—that’s really a matter for tradesmen, isn’t it? A true gentleman relies on intuition and courage to comprehend the universe!”
Now, I’m not suggesting that the early Romantics gathered some foggy night in a smoke-filled cellar in Paris to plot the defeat of Reason over a bottle of absinthe. Instead, natural selection acted on memes to produce the same result. Any fine young thing of the early 1800s who took on the Enlightenment on its own terms almost certainly lost; only those who adopted a “move the goalposts” strategy were rewarded with a chuckle at the college high table, attracted the interest of the FYT of opposite gender, got their work published, and so on.
I think that something similar to the rise of Romanticism lies behind the popularity of agile software development methods today. Everyone wants to be “agile” these days: even Doug Rosenberg, co-author of Extreme Programming Refactored: The Case Against XP, has given it a nod in his latest book. I don’t think it’s a coincidence that this is happening at the same time as an increasing number of development jobs are moving offshore to India and China. Two of agility’s distinguishing features are being intimate with customers, and not leaving much behind you in the way of transferable documentation; neither works when you’re eight or ten timezones away from the people who are paying for your work. People who can convince their customers that agile practices are the way to go are therefore more offshore-proof that people who stick to higher-ceremony processes. It’s neither a conspiracy nor the “right” way to do things; it’s just a survival strategy that happens to work.
And it’s not necessarily a bad thing. As Jorge Aranda pointed out, the quantitative experimental approaches that characterized the Enlightenment weren’t appropriate for tackling problems in psychology, sociology, and related fields. It was therefore only natural for Romantics to react negatively to people who thought that everything could and should be explained quantitatively, just as it is perfectly defensible for agilistas to rebel against processes that seem to emphasize red tape over creativity.
Jorge’s other observation was interesting as well:

In science as in software development, you’re differentiating between methods that are process- and number-heavy, and those that are people-oriented and unstructured, and you’re putting the “Romantics” with the second group. But the “Romantics” should be seen as a separate entity: a third group that doesn’t really care about building functional systems, or their users or implications of their work, but about their “art”, in the most selfish and capricious sense of the word. The thing is, they hide more easily in an agile environment, and that’s why you’ll find them there. They ignore most of the precepts of agile development, but since these precepts are harder to track than the process-heavy ones, they get away with it; just as it’s easier for a mediocre scientist to get away with qualitative than with quantitative studies.

Uncategorized

TUCOWS is holding a job fair this Saturday (June 24) at their Toronto office.  Cool company doing cool things, looking for talented developers at all levels — what’s not to like?

Uncategorized

DemoCamp7 will be held on Tuesday, July 4, rather than June 27. The venue has yet to be determined, but Perl hacker extraordinaire Damian Conway will be there. Damian will also be speaking in Room 1180 of U of T’s Bahen Centre for Information Technology the following evening (July 5) starting at 6:30 p.m. Hope to see a good turnout at both!

DemoCamp

Regular readers will know how disappointed I am that the gender imbalance in open source is even worse than it is in computing as a whole. I’m therefore very pleased that GNOME has announced a Women’s Summer Outreach Program: three women will be given US$3000 to work on two-month projects. As their announcement says:

The recent FLOSSPOLS report describes many opportunities that women miss out on when getting involved with computing and free software, ranging from being introduced to computers at a later age, being less encouraged to specialise in computing, having few female role models, having less free time to spend programming than men do, and being on the receiving end of sexism when they do try to get involved. We think it’s this imbalance that’s unfair, and we’re trying to help fix it.

Applications close on July 1; please help spread the word.

Equity