Friday, May 27, 2011

Phones ringing in events annoy everyone: Suggestion for flash reminders

At conferences I attend, there will always be somebody whose phone rings loudly. The same happens in meetings and in class. It has probably happened to you. It happens to me every few months. Very embarrassing.

Sometimes organizers remind people, don't forget to turn off your phones. But how many times have you reached for your phone when somebody else's phone rings, just to check if yours is off?

Here's the idea: All people need is a quick 'flash' reminder to check their phone. It need only take a couple of seconds. When introducing a session, the organizer could flash a slide for a few seconds with: "remember to check your phone is on vibrate!" The speaker doesn't have to say anything. Everybody knows what to do; hardly anybody wants their phone to ring.

Of course the better answer is to have calendar applications build in vibrate mode automatically, as I discussed in my previous blog post, but we may have to wait a while for that.

Live Blog from ICSE: Peer review in open source projects

This is my final live blog from ICSE. See recent posts for others.

The presenter, Peter Rigby discussed 460 instances of peer review in open source projects, including interviews with 9top reviewers.
They examined scalability of the peer review process, techniques for finding patches to review, motivation, patch structure and norms, as well as the effect of too many opinions and ignored reviews.

The presenter discussed the fact that large projects can receive hundreds of peer review messages a day. One lead developer received over 2000 emails in a day, only two of which were personal emails.

Motivations include intrinsic interest and a sense of responsibility. People are invested in a particular code base; if they don't review changes, then the code quality will deteriorate.

They filtered messages from people and subsystems. This helps developers to not feel overwhelmed. However many messages are posted to multiple lists.

One developer said that when reviewing potential patches, "a good and descriptive subject line draws immediate attention". A change log in the message gives conceptual understanding.

The developer snips out excess detail in replies; this seems to help considerably to streamline the process. My opinion is that this should be the case in general email etiquette.
 Another practice is that in a back-and-forth email conversation, people tend to reply to individuals as well as the list, and gradually more cc recipients get added.

Some review discussions are purely technical (whether it works); others focus on scope, politics, necessity etc. There are thus often too many trivial opinions (Parkinson's law of triviality); people with trivial information tend to drown out more serious discussion. They measured outsider involvement and influence.

One problem they examined is that there are too few developers in open source development. Lack of time tends to result in postponement of reviewing; this puts the onus on the author of the patch to ensure it is eventually included.

Takeaway mssages:
  • Reviewers are invested in doing reviews
  • They tend to postpone rather than rush
  • Asynchronous review processes facilitate discussion
  • Politicized discussion is infrequent
  • Scaling in large systems can occur through multiple mailing lists for different subssytems (other methods are discussed in the paper)
The presenter discussed the threats to the credibility of his work, and how these are mitigated. For example, the data is public.

An audience member asked about how this compares to traditional inspection. The presenter said there are many similarities and that the open source process seems to work as well as inspections. Key is early reviewing, and reviewing in small chunks. An audience asked about 'review then commit' and 'commit then review'; the presenter said that the processes were mostly the same. Another audience member asked a related question about status-quo bias: He said that patches that are committed first have a higher necessity for review.

An audience said that email for this is terrible and there should be better tools. The presenter said that the flexibility of email is underestimated. Several projects, however, have started to use tools, with more traceability. Forcing people to use tools has some drawbacks though. "You have to be careful to say that email is bad ... if you understand the norms of the community then it is really very efficient".

Thursday, May 26, 2011

ICSE second main conference day: General observations

I have been at the International Conference on Software Engineering in Hawaii since last Friday. Today is the second-last day of the event, and the second day of the 'main' conference. You can look back at my recent posts to see some sessions I have blogged about.

Here are some general thoughts. Some of these thoughts might help other conference organizers.
  • Attendance has been excellent (over 1000), although as usual mostly from academics. It is too bad that in our field the main conference doesn't also have a large contingent of software practitioners, with practical 'how to do it' sessions for them. Surely we could grow the event to encompass both types of software engineers.
  • The paper acceptance rate was on the order of 15%. This is far too low for the central conference in the field. It strongly suggests that they should explicitly plan to increase the capacity of the conference in terms of paper presentations, so they can accept more. Combined with my last comment, I would have thought that ICSE might be able to double or triple in size, reflecting the importance of software engineering in today's world. Other scientific fields have many thousands of people at their conferences.
  • The WiFi has been the best of any ICSE. Historically, all the high-tech software engineers have swamped the WiFi networks of the ICSE venue. Any organizer of a CS conference should put emphasis on good WiFi. Yes, it means some people check their email rather than paying attention, but it also allows for social media, blogging, checking references speakers reference, etc. etc.
  • The organizers seem to think that nobody wants coffee in the afternoon. No idea why.Also, when catering a conference breakfast, please provide lower glycemic-index options, such as bagels with cream cheese. Sweet stuff is not so healthy.
  • Keynote speakers need to be dynamic, not just interesting. Today's keynote certainly was both.
  • At ICSE, it is great to have keynotes on peripheral areas, like this year's two keynotes so far. I particularly liked today's talk, which I blogged about in detail. However, keynotes from companies that do software engineering, or radical new core SE ideas, would be very valued. In fact the non-keynote session from the sponsors, which I also blogged about, was better attended than the keynotes.

Live Blog from ICSE: Exciting New Trends in Design Thinking

The keynote this morning was called Exciting New Trends in Design Thinking by Bill Dresselhaus.

He started by giving a little background about himself, pointing out that he discovered that he was not so interested in Chemical Engineering, in which he had a Masters degree, but really liked drawing, so we went back to do another masters, in Industrial Design. He taught design in South Korea for a year and  settled in Silicon Valley as a consultant. He became the design lead at Apple, working on the Apple Lisa ("Mother of the Mac"). He later worked for InDesign, and wrote a well-known book "Return on Innovation". He is now back teaching design thinking in Korea.

He addressed the question, what is design: It is not only fashion, styling, etc. he said. He cited Victor Papenek who said "All that we do, almost all the time, is design, for design is basic to all human activity".

He distilled the concept of design to "Giving form and order to things (plus more)."

He stated that design objectives are: Utility, usability, emotion and innovation.

He discussed several people who have criticized industrial design, or design thinking, stating that it has failed or is dead, or is a commodity (e.g. China has Industrial Design parks where they have thousands of people working on products.)

He contrasted small design from big design, the latter being of systems that have lasting value.

He pointed out that there are many categories of design including, educational, UI, software, etc.

Design thinking is a kind or way of thinking and seeing and perceiving things. He drew an analogy with business thinking.

Attributes of design thinking he gave were: Process, tools, results, human-centred and visual.

He cited the book Blue Ocean Strategy, which states that innovations come from putting existing things together in new ways: Innovation from within.

He cited the Stanford, in which several academic units collaborate in the area of design.

He suggested that engineers need to get back to the 19th century attitude towards design thinking and product design, where engineers used to do wonderful drawings.

His current passion is "design education for everyone". If everyone knows how to design, then everything will be designed better.

He teaches at Hongik University in Seoul, and IDAS.

He discussed with enthusiasm the courses he teaches. For example, teams work on designing guitars. They have to learn about guitars in general, in addition to design issues surrounding guitars.

He says you can teach everyone to draw well enough to design. He says, however, that making mockups is particularly easy for people.

He teaches courses in the law school: Masters of Intellectual Property.

He does design thinking corporate workshops: Participants go into the surrounding city to 'find problems' and then come back to solve them. People in his courses are so excited that they actually come early.

He thinks that design should be taught in all schools, not just specialized schools, "just like we teach personal finance". Actually, I wish we did do the latter everywhere too.

He talked about convergence: Design + Business + Innovation.

He talked about "medical experience design" where a doctor has combined a clinic with a café in a relaxing context, so people's blood pressure readings are real, among other benefits.

He discussed the fear professional designers may have if everybody learns how to do good design. He actually thinks that the more expansive design is, the more work there will be for these people.

If everybody does design, there will both be schlock and value. He showed examples of ordinary people and small companies doing innovative design and prototyping. You can go to and buy a relatively cheap rapid prototyping tool. He suggests that such devices may become available everywhere in stores that now offer photocopying services.

He discussed social design: For example has a project to do design to help developing countries.

He gave an example of how a group of students studied then improved the design of the workflow of cleaning staff in a building.

He suggested that AutoDesk software for digital sketching is excellent.

He said that better software is needed from software engineers for various types of design, such as user inspired and generated design in 2D and 3D that is easy to use and  highly accessible. He also suggested there is a need for tools for design for the environment (DFE); these tools require integration of scientific knowledge.

Wednesday, May 25, 2011

Live Blog from ICSE: The view of ICSE's supporters

This is my fifth live blog post from ICSE, this time from the session giving the perspectives of ICSE supporters.

I will be updating this post as the speakers talk (which is what I have done with the others). I fix spelling at the end.

The first talk in this session is The Grand Challenges of Software Engineering - A Perspective from the Trenches, by T.S. Mohan of Infosys Technologies Ltd.

The presenter first discussed a little of the history of 'grand challenges', for example NFS grand challenges in computational engineering,  putting the man on the moon in the 1960's, curing cancer (failed so far), solving Fermat's last theorem (accomplished), etc.

He also talked about grand challenges in Computer Science, such as proving that P is not equal to NP, the Turing test, and automatic translation.

He discussed Hoare's criteria for what constitutes a grand challenge. For example, it arises from scientific curiosity, has enthusiastic  support, has international scope, is a comprehensible problem, captures the imagination of the public and the esteem of scientists, was formulated long ago, still stands, goes beyond what is initially possible and requires development of new techniques. In particular, it should be rather obvious when it is achieved and should lead to a radical paradigm shift, and is not likely to be met by market forces.

He discussed a supposed grand challenge of trusted components that was set in 2003, but doesn't count since it didn't 'take off'.

When he gets to his list of challenges I will comment on each a little. I hope he includes the concept of merging modeling and programming so we can generate systems very quickly and easily.

Right now he is talking about a model that is very similar to the spiral model; he calls it the new lifecycle, but it isn't very new.

He commented about acceptance rates in ICSE, and suggested that key topics like design did not have very many accepted papers, what he said "really needs to be done". He pointed out that Mobile computing had 0 papers, I note that HCI got 0 papers too; however both these areas have specialist conferences.

Here come his grand challenges:

1. Cruising Scale: From birthing centre to hospice: A medical management system that can handle the entire medical system

2. Consistent and uniform programming tools for heterogeneous systems. This is the one I was looking for.

3. Validated trust: Verifying tools: Compilers, model checkers, configuration and deployment validators.

4. Dynamic compositionality: A global trusted marketplace for compositional software components and services

5. Simplifying complexity: Automated tools and environments for enhancing non-functional requirements

An audience member pointed out that many o these do not meet the Hoare criteria: In particular, will we know when they have been achieved? Are they long-standing?  Fair comment

The second talk is Connect and Collaborate by Judith Bishop of Microsoft Research.

The presenter presented a slide with a huge number of research areas in which MSR is involved. She discussed the group she is invovled with, Microsoft Research Connections; this links researchers to Microsoft. She pointed out that this group doesn't just do computing (e.g. it is working on the worldwide telescope), but SE is number one.

Her group gives awards to universities such as CRA Researc Awards, Faculty Fellows and conference sponsorship. She said the Jewel in the crown is the SE Innovation Foundation. The 2012 foundation awards will be in the area of mobile computing.

She discussed Pex4Fun, which she said has gone viral and The ICSE contest at . She also talked about the Kinectt SDK, Debugger Canvas.

Finally a colleague gave a cool demo of TouchStudio beta, a tool for writing a program easily on a phone. The tool was able to use a touch interface to put together the program. See below:

This environment sounds extremely promising. It has access to all the standard capabilities of the Windows Phone 7, including the GPS, camera, accelerometer, etc. The following, is the code that has been visually created. I know it is not legible, but it gives you a sense of what Microsoft expects end-users to be able to create. This relates to the Mary Shaw's keynote at CSEE&T that I blogged about yesterday.

It puts the pressure on Google and Apple to come up with something similar.

The final talk is How Software is Engineered at Google, by Marija Mikic-Rakic of Google.

This sounds very exciting. The room is packed.

She started by discussing how the Google search system is composed of many subsystems that all work together. She said that every Google application is growing in many dimensions: More users, more data and better quality (e.g. more relevant and faster results). She attributed many of Google's improvements to dramatic improvements in speed and capacity of hardware.

She said they need to balance simplicity, features, scalability, performance and reliability (note that simplicity is first).

She highlighted some skills needed in employees: Statistics, machine learning and production software engineering.

The design stages are: Brainstorming, investigating, discussing, prototyping, documenting (not formal, no UML), reviewing (designs available to everyone in the organization), coding and reassessing. I note that this doesn't sound very agile!

How do they deal with compexity? They ...
  • Build simple
  • Reuse existing components.
  • Consider latency and throughput
  • Parallelize when possible
  • Consider resource constraints
  • Design with scalability in mind
  • Design for reliability (assume machines will fail)
  • Do back-of-the-envelope calculations
  • Understand how data is accessed
Interesting list; seems rather ad hoc though.

She gave a list of numbers that every engineer shoudl no, such as the number of ms to send a packet from California to the Netherlands and back.

Basic truths:
  • Every new line of coe is a liability
  • No large functions of classes
  • Refactor code that has gone crufty
  • Make sure not to break the build
  • Documentation matters
  • Code needs to be localized
  • People spend more time reading code than writing it
  • Make sufficient and clear comments (update with each change)
  • Latency is a deal breaker (profile your code, then improve)
Tools Google engineers use

  • Source control
  • Bug tracking
  • An editor
  • One touch build
  • Tons of documentation
  • Standard libraries
  • Unit and other tests
  • Code reviews
Google has more than 5k developers in 50 offices; more than 2000 projects under development, more than 50000 builds every day, more than 50 million tests run a day. There are 20 code changes a minute; half the files in the codebase are changed every month.

There is one source repository and they use Perforce for source control.

Goals: Speed, high quality feedback and simplicity (there it is again).

They use a caching system to distribute source code to developers. A full checkout would take 10s of minutes. Developers change less than 10% of the code they check out.

They have done a lot of work on their build system; compilation is done in the cloud. Compiles are cached, so people who build the same things don't re-do it. The presenter commented that they need peope with strong CS skills to make this work. The cache for the build system has more than 10000 cores using > 50TB of memory. This saves 600 person years in wait time. Build outputs are not sent to user workstations until they are needed, to avoid overloading the network.

The continuous integration system analyses every check-in and runs all relevant tests (from 1 to 150000 tests). They have a storage system called Sponge that stores all the test results.