Archive

Archive for December, 2007

Show Me

December 18th, 2007

In an online discussion about why there are so few women in computer science, one student wrote that he thought it was because there are fundamental differences between the sexes. When asked what data he was basing that opinion on, he replied:

It’s more of an unrefuted hypothesis based on personal observation.

More recently, in a comment on an earlier post asking what data there was to back up the claim that Erlang and Haskell made parallel programming easier, Neil Bartlett said:

As a working programmer I favour my own personal experiences and experimentation over academic studies…

Put that way, it sounds very pragmatic, but what if you replace “academic studies” with the phrase “careful observation and analysis of a large number of people followed by critical peer review of the claims”? Or, if you like shorter sentences, “science”. I wouldn’t believe a drug company’s claims about a new headache remedy unless they’d been subjected to independent scrutiny—in fact, while the rules are bent all the time, the drug company wouldn’t actually be able to make any claims publicly until they were able to prove them. “My Uncle Vlad used it, and his migraines went away” isn’t good enough—there could be a thousand other reasons why Uncle Vlad’s headaches went away, and there’s no way of knowing whether the effects on one (self-selected) subject are representative of the population as a whole. “It’s made from mushrooms, which contain lots of mitochlorians, which are an effective vasodilator” isn’t good enough either—there are at least three leaps of logic in that particular “just so” story, any one of which could be invalidated by some factor not included in the argument.

Unfortunately, most of the claims about programming and related topics that I read online or hear in pubs are equally broken. Having worked with scientists and engineers for much of the last 25 years, though, I’ve learned that the good ones don’t believe or disbelieve something until there is evidence—not just anecdote, personal experience, or a plausible chain of reasoning, but evidence—to back it up. As a profession, we are finally starting to accumulate that kind of evidence: see Glass’s Facts and Fallacies of Software Engineering for an easy-to-read summary, or the journal Empirical Software Engineering

for more recent results. It’s hard work, but I suspect the real challenge will lie in persuading working programmers to say “evidence, please” more often.

Uncategorized

Will It Fly?

December 17th, 2007
Comments Off

Via David Crow, a useful article on evaluating new product ideas. I’m not as focused on startups as most other DemoCampers, but this is a very useful checklist, and I’ll be asking my students next term to answer these questions.

Uncategorized

Reputation Management

December 17th, 2007
Comments Off

Andy Oram just finished a nice series of posts on online reputations (concatenated here). It’s a fascinating topic, particularly when one starts to think about reputation “micropayments”.

Uncategorized

Summer Is Almost Over

December 17th, 2007
Comments Off

Count ‘Em

December 16th, 2007

The solstice is approaching, so it’s time to count ‘em. Do you remember how it felt the first time you:

  • implemented a for loop to find the length of a string, in assembly, and finally understood how computers actually worked?
  • read Software Tools in Pascal, and discovered that there was more to programming than writing legal code?
  • realized that 1+1/2+1/4+1/8… converges, but 1+1/2+1/3+1/4… doesn’t?
  • read Neuromancer, Wyrd Sisters, The Dark Knight, or an Elmore Leonard novel?
  • saw Star Wars (back before they ruined it with Return of the Jedi), Grosse Pointe Blank, The Mummy, or Casablanca?
  • listened to The Clash, Talking Heads, The The, Peter Gabriel, Mary Margaret O’Hara, Ike Quebec, Thelonius Monk, or Ali Farka Toure?
  • laughed until your belly hurt because the only other thing to do was cry?
  • woke up at home in a foreign country?
  • had a really good idea that actually worked?
  • saw someone you didn’t know reading a newspaper article you had written?
  • played liars’ dice with friends until closing time?
  • threw a frisbee right to someone fifty meters away?
  • received spam?
  • said exactly the right thing at exactly the right time and made a hundred people laugh?
  • watched your opponent’s ion frigates plow into the minefield you’d spent half an hour laying down?
  • saw someone you didn’t know using software you had written?
  • had someone thank you for talking them out of dropping out of school?
  • held your firstborn?

Uncategorized

IEEE Computer Society Needs Beta Testers

December 16th, 2007
Comments Off

I received this a couple of days ago—regardless of whether some form of licensure would be a good idea or not, I think it’s bound to happen eventually, and the IEEE will be a major player.


The IEEE Computer Society—the world’s leading provider of technical information and services to the world’s computing professionals—is developing a program to certify entry-level software developers and engineers. Called the Certified Software Development Associate Program, this program will provide formal recognition of entry-level professionals who have achieved a level of proficiency commonly accepted and valued by the industry and will complement our certification program for mid-level software developers and engineers, the Certified Software Development Professional. To recruit beta testers of the certification exam, we are waiving the test fee for the first 200 qualified candidates. For the beta test only, the Computer Society seeks students in their final year of a program leading to a baccalaureate or equivalent degree and entry-level software developers and engineers who have graduated with a baccalaureate or equivalent degree since November of 2004.

We need at least 200 beta testers to validate content and establish a pass/fail rate. Candidates who pass the beta test will receive the CSDA credential and receive recognition in Computer Society publications and on its Website. We plan to promote the value of the CSDA credential to industry worldwide.

We’re accepting applications through December 28. The exam may be taken through January 31. Click here for an application to participate in the beta test, or visit http://www.computer.org/ce rtification/csda for additional information about the program, including the content outline of the exam. Please forward this to your entry-level colleagues, students, and anyone else you feel might benefit from this opportunity. For questions, contact certification@computer.org. Thank you for supporting this program.

Steve Tockey
Chair
CSDP Certification Committee and
CSDA Examination Development Committee
Construx Software


  1. Software Requirements (6-8% questions)
    1. Software Requirements Fundamentals
    2. Requirements Process
    3. Requirements Elicitation
    4. Requirements Analysis
    5. Requirements Specification
    6. Requirements Validation
    7. Practical Considerations
  2. Software Design (7-9% questions)
    1. Software Design Fundamentals
    2. Key Issues in Software Design
    3. Software Structure and Architecture
    4. Human computer Interface Design
    5. Software Design Quality Analysis and Evaluation
    6. Software Design Notations
    7. Software Design Strategies and Methods
  3. Software Construction (8-10% questions)
    1. Software Construction Fundamentals
    2. Managing Construction
    3. Practical Considerations
    4. Construction Tools
    5. Construction Technologies
    6. Product Documentation
  4. Software Testing (6-8% questions)
    1. Software Testing Fundamentals
    2. Test Levels
    3. Test Techniques
    4. Human Computer User Interface Testing and Evaluation
    5. Test-Related Measures
    6. Test Process
  5. Software Maintenance (6-8% questions)
    1. Software Maintenance Fundamentals
    2. Key Issues in Software Maintenance
    3. Maintenance Process
    4. Techniques for Maintenance
  6. Software Configuration Management (2-4% questions)
    1. Management of the SCM Process
    2. Software Configuration Identification
    3. Software Configuration Control
    4. Software Configuration Status Accounting
    5. Software Configuration Auditing
    6. Software Release Management and Delivery
    7. Software Configuration Management Tools
  7. Software Engineering Management (2-4% questions)
    1. Initiation and Scope Definition
    2. Software Project Planning
    3. Software Project Enactment
    4. Review and Evaluation
    5. Closure
    6. Software Engineering Measurement
    7. Software Management Tools
  8. Software Engineering Process (4-6% questions)
    1. Process Implementation and Change
    2. Process Definition
    3. Process Assessment
    4. Measurement
    5. Software Process Tools
  9. Software Engineering Methods (4-6% questions)
    1. Modeling
    2. Types of Models
    3. Analysis
    4. Development Methods
  10. Software Quality (4-6% questions)
    1. Software Quality Fundamentals
    2. Software Quality Management Processes
    3. Software Quality Practical Considerations
  11. Software Engineering Professional Practice (5-7% questions)
    1. Professionalism
    2. Codes of Ethics
    3. Group Dynamics / Psychology
    4. Communications Skills
    5. Intellectual Property, Confidentiality, Security
  12. Software Engineering Economics (3-5% questions)
    1. Software Engineering Economy Fundamentals
    2. For-profit Decision-making
    3. Non For-profit Decision-making
    4. Present Economy
    5. Estimation, Risk, and Uncertainty
    6. Multiple Attribute Decisions
  13. Computing Foundations (8-10% questions)
    1. Programming Fundamentals
    2. Algorithms, Data Structures/Representation (static & dynamic) and Complexity
    3. Problem solving techniques
    4. Abstraction — use and support for (encapsulation, hierarchy, and so on)
    5. Computer organization
    6. Basic concept of a system
    7. Basic user human factors (I/O, error messages, robustness)
    8. Basic developer human factors (comments, structure, readability)
    9. Operating system basics
    10. Database Basics and Data Management
    11. Network communication basics
    12. Distributed and Parallel Computing
    13. Concepts of programming languages
    14. Debugging Tools and Techniques
    15. Secure Coding
  14. Mathematical Foundations (8-10% questions)
    1. Functions, Relations and Sets
    2. Basic Logic (prepositional and predicate)
    3. Proof Techniques (direct, contradiction, inductive)
    4. Basic Counting
    5. Graphs and Trees
    6. Discrete Probability
    7. Finite State Machines, regular expressions
    8. Grammars
    9. Numerical precision, accuracy, and errors
    10. Number Theory
    11. Algebraic Structures
  15. Engineering Foundations (8-10% questions)
    1. Empirical methods and experimental techniques (such as computer-related measuring techniques for CPU and memory usage)
    2. Statistical analysis (including simple hypothesis testing, estimating, regression, and correlation)
    3. Measurement
    4. Systems development (security, safety, performance, effects of scaling, feature interaction, and so on)
    5. Engineering design (problem formulation, alternative solutions, feasibility, and so on)
    6. Theory of measurement (for example, criteria for valid measurement)
    7. Simulation, Modeling and Conceptual Prototyping
    8. GQM Paradigm
    9. Standards (identify, evaluate, select and adapt)
    10. Tool and platform selection
    11. Root cause analysis

Teaching

CAST’08 in Toronto

December 16th, 2007
Comments Off

Via Adam Goucher: the Third Annual Conference of the Association for Software Testing (CAST) will be held in Toronto on July 14-16, 2008.  The keynote speaker is Gerry Weinberg; the theme is “Beyond the Boundaries: Interdisciplinary Approaches to Software Testing”.  Coming as it does on the heels of the announcement that Agile’08 will be here next August, it’s shaping up to be quite a summer.

Announcements

Prepping for Next Term

December 15th, 2007
Comments Off

I’m teaching two courses next term: CSC301 (Intro to Software Engineering) and a combination of CSC490 (undergraduate capstone project) and CSC2125 (graduate “topics in software engineering”). I’m hoping to do a better job with the former than I did this term, so I’ve started working on lectures. So far, the topics include:

  • what the data actually says about software engineering (drawn from Glass’s Facts and Fallacies of Software Engineering and Endres & Rombach’s Handbook of Software and Systems Engineering)
  • software process and lifecycles (agile vs. sturdy, with emphasis on the former)
  • design patterns: mostly from Head First Design Patterns—the format is condescending, but the content is excellent
  • refactoring: drawn in part from Martin Fowler’s Refactoring, but also from Mike Feathers’ excellent Working Effectively With Legacy Code
  • software quality: both heuristics and metrics, with some discussion of empirical studies in software engineering—my main reference is Spinellis’ Code Quality
  • UML (I’m not a believer, but it is part of the standard curriculum
  • testing: I’m assuming students are comfortable with JUnit, so these lectures cover both how to make code testable (Feathers again) and the framework in Meszaros’ xUnit Test Patterns. I will also cover the nine rules from Agans’ Debugging, and borrow liberally from Whittaker’s three books.
  • tooling: some intermediate topics in version control (branching and merging), build systems (especially ways of supporting different configurations in a single build file), and ticketing
  • the last ten yards (i.e., creating installers, deploying software, and making it work in production environments): my only reference so far is Nygard’s Release It!—lots of other books wave their hands about these issues, or provide tutorials on how to use some vendor or other’s installer creator, but I’m looking for something in between)
  • security: I think Smith and Marchesini’s Craft of System Security is at the right level, but I’m going to borrow from many others.
  • ethical issues, particularly liability and licensure.

It’s a lot to cram into 26 lectures, some tutorials (which will probably consist of guest speakers from industry), and four assignments, but with help from Colin and Roy at Refresh Partners (makers of fine Facebook plugins), I think it’ll work.

The combined capstone/graduate course doesn’t have a well-defined syllabus yet. Students will work in pairs on real projects with real customers; the current list of proposals includes open source organizations, non-profits, academics from other departments on campus, and a few local companies. After the first class (in which I’ll present the projects Ignite-style, and students will decide what to work on), the course will be held upstairs at Molly Bloom’s (a local pub).  I figure this will facilitate free and frank discussion ;-)

And of course, my grad students will be starting their thesis work. Samira wants to apply machine learning techniques to requirements management (see for example the work of Jane Huffman Hayes, or Anvik, Hew, and Murphy’s “Who Should Fix This Bug?“), and Jeremy is interested in software project visualization (or “dashboards on steroids”), while Carolyn and Jon are still trying to nail down specific topics. It’s going to be a lot of work, but I’m looking forward to it.

Teaching

A Meme I’d Like To Crush

December 15th, 2007

Over on O’Reilly Radar, Nat Torkington recently posted:

According to a blog post by (update: a friend of) one of the developers, Amazon’s SimpleDB is built on Erlang. Cool! Another datapoint for the trend we see towards parallel-capable languages like Erlang and Haskell.

“Parallel-capable”? I know the arguments—values in pure functional languages (PFLs) are immutable once created, so there can’t be race conditions, so parallel programming is easier, and parallel programs will scale better—but I have yet to see any data to substantiate that oft-repeated meme. I wrote a book about parallel programming in the early 90s, and have maintained a more-than-casual interest in the topic ever since (mostly through work with computational scientists). I don’t believe that PFLs make non-trivial parallel programs easier to write. I don’t believe they make parallel programming harder, either, and the reason I don’t is that I haven’t seen any empirical studies of real programmers writing real programs that point either way. I hereby offer a very nice bottle of wine and/or all seven seasons of Buffy the Vampire Slayer to the first person to conduct a study rigorous enough to be accepted as a senior undergraduate project in psychology—a standard which, sadly, most discussion of the merits of various programming languages, tools, and paradigms signally fails to meet.

Note: if you’d like to know what those standards are—i.e., what kind of evidence you should require someone who’s pushing the software equivalent of a cure for baldness to give you—please have a look at:
B.A. Kitchenham, S.L. Pfleeger, L.M. Pickard, P.W. Jones, D.C. Hoaglin, K. El Emam, and J. Rosenberg: “Preliminary guidelines for empirical research in software engineering?. IEEE Transactions on Software Engineering, 28(8), August 2002.

Barbara A. Kitchenham, Tore Dyba, and Magne Jorgensen: “Evidence-Based Software Engineering”. Proc. 26th International Conference on Software Engineering (ICSE’04), 2004.

Research

ICSE Workshop List

December 14th, 2007
Comments Off