SPLASH 2012 Conference, Tucson AZ
Thursday October 25, 2012, 10:30-12:00
Panel members:
Ruth Lennon, Letterkenny Institute of Technology (Ireland)
Diomidis Spinellis, Athens University of Economics and Business (Greece)
Giancarlo Succi, Free University of Bolzano-Bozen (Italy)
Jim Coplien, Gertrud & Cope (Denmark)
Junilu Lacar, Cisco Systems (USA)
Kendra Cooper, University of Texas - Dallas (USA)
(Note: This report is a summary of the panel dialog,
I have done a lot of paraphrasing of the responses.
Each question is marked with a "Q", and the responses are marked
with the first name of the panelist.
Every response summarizes the content of the panelist's response,
frequently capturing the key words and phrases that they used.]
(This transcript was created by Dennis Mancl (dennis.mancl@alcatel-lucent.com) – (c) Alcatel-Lucent 2012.)
Opening Statements.
Ruth Lennon. I am very much an advocate of tools. I use tools, and I find it easier to teach students about concepts using tools. We are using a combination of cloud technology and Bring Your Own Device policies to increase the learners' access to tools.
Our learners have a wide range of ages and experience, and most of the younger learners are very comfortable with tools — they expect to be taught using tools.
Diomidis Spinellis. I have experience as a software tool developer. Let me talk about two of my open source tools. I developed CScout, www.spinellis.gr/cscout, a refactoring browser for C and UMLGraph, www.umlgraph.org, a tool for creating UML Class, Object, and Sequence Diagrams from a text-based description.
CScout was moderately successful (40,000 downloads). UMLGraph was extremely successful (almost 200,000 downloads), but the tool was hijacked by others to do something that is definitely a mistake — automatically generating UML diagrams for large Java-based systems.
On one hand, the development of new software development tools is becoming more complex. Our languages and environments are a lot more complex than before — for example, the first C compiler was 40,000 lines of code, but today's GCC compiler is 1.5 million lines.
On the other hand, there are tools that make things easier for tools developers, such as github. It is easier to develop tools by building on the work of others, and it is easier to distribute tools and easier to make the source code for the tools available.
The important lesson for today's tool builders — build tools that work well with other tools, rather than building isolated monoliths.
Giancarlo Succi. We have done research in how tools are used in practice. People tend to use a small subset of the tools available to them. Most developers will use only about 8 to 12 tools, even if there are many more tools available. Also, people use a "chain" of tools to accomplish their goals: reading requirements in a document tool or email tool, code development in an IDE.
We need better integration between tools, so we can better manage the looping between tools. But we have found that people tend not to like using a heavy integrated tool. For example, when developers use Eclipse IDE, they don't like to use the Eclipse plug-in for loading requirements. When developers use Visual Studio, they don't like to use Team System for requirements.
Jim Coplien (Cope). We don't need research on tools, we need to get rid of tools.
There have been many good ideas for improving design and improving software process over the years, but there is a lot of evidence that tools just get in the way of the fundamental things that make software development effective — which is about human-to-human communications.
Three examples:
So we don't need research on tools, we need to get rid of tools.
Ruth. Wait a minute... While you are giving out on tools, you are looking at your laptop and using a tool.
Cope. But I'm not doing software development right now.
Giancarlo. Can you find a single article in the literature that studies how tools users use tools?
Cope. You can go to some of the things in my book (Organizational Patterns of Agile Software Development) as well as some articles in PLoP (the Pattern Languages of Programming conference). Brendan Cain and I also did an article for Annals of Software Engineering. But who cares?
The tools that I am doing today are *games*, with the goal of getting human communication going. See www.scrumknowsy.com for some of the games that our company ScrumTide is developing.
Junilu Lacar. I agree and disagree with Cope. I don't think we need to do away with tools research, we need to refocus. There was a talk earlier in the conference by Rob Pike about the design of the Go language and its environment. In developing tools, we should carry over some of the key ideas in the design of Go: cleanliness, clarity, and simplicity. And the Go language wasn't about language research, it was about how to make the development community better.
Kendra Cooper. We need tools to get our large-scale systems projects done. But the tools I have used ranged from somewhat awful to very awful in their functionality and performance.
Now that I am a university professor, my perspective on tools has changed. My graduate students need to build prototype tools in order to explore and prove concepts, so they build tools that are relatively small scale and scope. The academic community does this exploration pretty well. But what we don't do well is to scale up our work, to build hardened tools for commericial use.
I have seen trends come and go in development. The current agile trend is a lot of repackaging ideas. And it is abused a lot, where agile is interpreted as hacking.
Ruth. The problem about tools is that we are not analyzing how we are using the tools. It is all well and good to say "don't use tools", but why don't we look at how we use the tools, and actually get more efficient from the input we are getting?
Kendra gave a great paper yesterday on analyzing the communications tools. You said you were using games to help encourage communication. So one thing Kendra did was to look at how communications had an impact on the quality of the final software.
Cope. We are starting a research program to use game data from our ScrumKnowsy site to assess the agile understanding worldwide. That is the real purpose of this game. The marketing purpose is to help teams communicate — to get internal alignment and external alignment.
Q1. David Ungar, IBM Research In an object-oriented model, we want to put function with data, and this might reframe the way we do tools.
When we did Self (the Self language, first developed in 1986 by David Ungar and Randall B. Smith at Xerox PARC, see selflanguage.org), instead of having an inspector to look at an object, we just had the object appear on the screen as an outliner. It respected the object's identity, and we tried to make that functionality part of the environment: every bolt had a handle on it, instead of needing a wrench. When you think of a tool, you think of an isolated external function that operates on something else.
Diomidis. I think of the Unix philosophy of having tools that do one thing well and can be composed with other tools.
David Ungar. That is the opposite of what I said - but it has virtue to it. That's sort of the functional approach of composing functions. In my mind, it isn't the object oriented approach, where the function goes with the data. Imagine you could go to any Unix file and just ask it for its word count, instead of getting the word count tool.
Diomidis. I see the difference, and we probably have more work to do to get what you are asking for.
Q2. Kevin Lubick, Carthage College A key aspect of software engineering is learning: learning about other people's software, new tools, new languages, and new programming styles. Should we be considering learning approaches that use short videos instead of documents and books — like Minute Physics or Khan Academy?
Cope. W. Edwards Deming said there is no substitute for a system of profound knowledge. We have to make sure that the tools are not disembodied from their context, because you will only learn isolated facts. Real learning is a change in behavior, and tools don't affect that. Tools allow you to *avoid* learning and *avoid* thinking.
Ruth. I completely disagree. We use a virtual learning environment. We have small learning nuggets that are 10 minutes long. When you are waiting for a bus or waiting for your taxi, you may have ten minutes to listen to a learning object. These learning objects are not isolated. They build onto a lifelong learning portfolio. And it is not that they just give you a piece of knowledge, they interest you in some topic. When you are interested, you start looking more.
Giancarlo. It is about how we use a tool. I love vi (old Unix visual editor). How many people here use vi? When I have anything serious to do, I use vi. However, when I have to train a young person in class, I use Eclipse. I don't use emacs, I use Eclipse. Because a person becomes productive faster using Eclipse.
Cope. It's not the tool, it's how you use it. The National Rifle Association's slogan is "Guns don't kill people, people kill people."
Junilu. I'm going to agree and disagree with Jim. I think that what is important is the way you use the tool. RallyDev can lock you into waterfall, if you misuse it. In the design of the Go language, Rob Pike tried to make it easier to use the tools properly. I don't know if you can idiot-proof them.
Kendra. In engineering education and education in general, "e-learning" and the "gameification" of applications are trends. I've been working on games for a while, serious educational games, and I see that they are trying to "engage people" and "getting people more involved with what they are working with". Gameification is integrating the "fun/engagement" and the "educational aspects". I think this is an area to keep an eye on.
Diomidis. I can't accept the premise that tools are not useful when we are building software. Software systems are the most complex artifacts humankind has ever developed, so we need all of the help we can get.
Q3. Bill Opdyke, JPMorgan Chase Mastering a job role versus mastering its tools: When developers are moved into requirements work, they often think that they only need to master a requirements tool. The same goes for testing — becoming a master tester is thought of by developers as just a matter of mastering the testing tools. There is a confusion between tool mastery, which feels like a coding exercise, and the real functions of a job role. When in a person's career do they start to see that there is a big difference between becoming an expert in a function versus becoming an expert in some tools? Does it happen early in a person's career, in the middle, or never?
Junilu. We start out in our careers that way. But later we learn it is all about people and interactions.
Cope. The way managers manage people is through adherence to the tools. It isn't the tools "guiding the way", it is "tools enforcing the manager's will" to implement work flows conceived of ten years ahead of the time they are used (and ten years out of date with prevailing knowledge and maturity).
Tools are the enforcer of the management prisons, they are the guards at the gates of the prisons, to keep the developers from being innovative.
Giancarlo. This is indeed true. Managers and developers need to focus on value. We want tools that are practical, instead of having them developed by theoreticians who want to have a clever way to implement a Sudoku game.
Our tools should be designed to give people feedback — a daily profile of how they used the tools. Every day you could automatically get a report of how much you use tool A, tool B, and so on. It is valuable to realize how much time you spend in one tool versus another.
Diomidis. I will agree with Jim. Tools have created a cargo cult. The fact that we have a tool that creates nice diagrams makes me think that I am a designer. Students think they can be designers and architects after leaving high school.
Cope. No, makes the students *not* think.
Diomidis. We need to instill in our students that they should first learn how to design. The fact that you can create a UML diagram doesn't mean you can design.
Kendra. When we teach software engineering, we see students who think "If I can draw a pretty diagram, then my design must be just superb." I think it takes experience and maturity — to distinguish between my ability to use the tool effectively, versus my ability to design effectively.
Ruth. Is this not a case of a bad workman blaming the tools? If we teach the students how to use the tools properly, then it shouldn't be a problem.
Cope. I've been a student of Alexander for some time. Alexander has been design things like houses, and things like hammers and saws never come up. Those are just commodities.
If tools are commodities, that's fine. We just *use* commoditized stuff, and we don't need to do research on commodities.
Real design insight is hard. For example, Dick Gabriel, Christopher Alexander, and I worked for years to develop a tool to help design a gate in a fence leading into a house. We spend two or three years of dialog just figuring out just what the tool should do. There have been a number of people working on this for the past 15 years, and we are nowhere close to understanding how to get a tool that expresses this design domain.
UML makes us think we can design. But design is hard, and most of software is about design. And it is *not* a tools questions.
Q4. Toby Schachtman I don't agree that a tool is just in how you use it. But I want to discuss the difference between a manipulative tool versus a convivial tool.
Most "standards" are manipulative tools. You force everyone to follow a certain process or fill out a certain form. The standard manipulates people into having to use it. But there are more flexible standards, such as the USB interface standard. It isn't as limiting, and it encourages variations and a creative ecosystem. How can we make tools that encourage conviviality rather than manipulate people?
Giancarlo. Tools should not be too prescriptive to have people follow a specific process. People don't have time to waste time. We need to organize tools to they create value, and there needs to be integration between tools.
Q5. David Lee If you are interested in researching tools, don't just leave it to the software people. You have to bring in cognitive psychologists, experts in industrial design, interaction design — a very multi-disciplinary approach is needed. Unfortunately, we don't have enough of those other personalities at this conference.
Cope. In our research we did at Bell Labs, I hired a Ph.D. in anthropology, we had two user experience experts in the department — I'm totally with you here.
David Lee. Manipulating people is just an essential part of what we do — to exercise our will and help to scale larger. I can get a little bit done, but if I manipulate a thousand people to help me, I can get a lot more done. Manipulation has gotten a bad rap, but it is just what we do.
Cope. Disagree.
Q6. Ed Seidewitz, Model-Driven Software It seems we haven't defined what a software tool is. A programming language is a tool, a compiler is a tool, and we are always totally dependent on tools. Therefore, we need software tools research.
If you are launching a software development project, which tools would and wouldn't you use and why? What would you like to see done better to allow our industry to do better? Why do you think our current tools are not as good as they should be?
Cope. I actually brought a slide that defines "tool". There is a specific definition for computing: A piece of software that carries out a particular function, typically creating or modifying another program. And that is consistently the way I am using the word "tool". So a compiler would count.
The kind of tools that will help me are commodity tools. A language, according to this definition, is not a tool. Tools that directly support a language are commodity tools, and I am fine with having and using them. It is like a low-level protocol like USB, a standard that doesn't limit me but enables me. Anything else is a power play that constrains self-organization.
In Japan, when they build temples, the people first build all of their own tools. I have no problem with that. Where I have problems with tools is when they are used to enforce culture, to constrain culture's ability to self-organize and learn.
Ed Seidewitz. Are you saying that everyone should build their own compiler before they write software?
Cope. I'll largely agree with that. Was it P. J. Plauger who said that the only effective way of learning a new programming language was by writing a compiler in it? There is a lot of truth to that.
Ed Seidewitz. I like writing my own compilers, but what you would end up with would be a lot of Japanese temples. You would not end up with skyscrapers or the systems that we need. In the area of modern tools, we have specialized people who create the tools.
Would you consider Eclipse to be a commodity tool?
Cope. No. I think it constrains the way in which you do development.
Ed. That's the definition of commodity? I thought that commodity has to do more with availability and specialists and ability to get...
Giancarlo. I do think that tools can be manipulative. For instance, if you use XCode to write code, you are forced to use a syntax which is much more problem to write and check than Objective C.
But I think Eclipse is a great tool. Whenever I code for Android and I am asked which tool to use, I *do* use Eclipse.
Ruth. I wanted to go back and talk with Cope and Kendra about games. You were creating these games for what?
Kendra and Cope. Communications.
Ruth. Right. Is that not manipulating somebody to encourage them to communicate or to communicate in a better way? You are still manipulating people, no matter what way you are looking at it.
Cope. I think manipulating is the wrong word. I am not encouraging any particular direction. I'm giving them an opportunity.
Software design and development is an "infinite game", and one of the properties of an infinite game is the ability to learn and change the rules of the game.
Q7. Assaf Marron, Weizmann Institute If you could ask for a research paper to be presented here in two or three years, what thing would you find most exciting to know about?
Giancarlo. A topic we have already been discussing here - is Eclipse a commodity or not? I would like to see a paper three years down the road with a comparison of teams using Eclipse versus teams using vi - to see which teams are more productive.
Diomidis. I would like to see tools that manipulate programs to extract information in a meaningful way. Today, the only tools we have are very low level (such as grep) or uncontrollable (such as the refactoring functionality in Eclipse). I would like to see research on tools that put us back in control.
Q8. David Ungar So, we build the tools, and then they build us.
When I was involved in Self, creativity was a real goal. How do you want to shape the users of your tools? To what extent are you conscious of that? Can you give me an answer at a nice high level, as opposed to solving this particular problem better?
Giancarlo. Tool users need some feedback mechanism — something that tells them how much time they have spent in their tools and what problems it has helped them solve. This feedback can change the way that developers will use tools, to help them focus more on value.
Diomidis. The design of our software tools provides an affordance to be used or misused. But if we design our tools with the affordances that we think are important, we advance how the tools are used.
David Ungar. Think about how bad our tools are. Do our users have to type in passwords one character at a time and get them right to be automotons, are they free to do things in any order, are they creative, or how are you trying to change people with the tools?
Cope. I'm very conscious of this. Instead of taking tools out there, I am taking... let's call them moral imperatives, social structures, social mandates. How do you come up with your tools? Get a bunch of people together and let them decide what the tools are that they are going to use.
I'm not in the tool pusher business. But we do have pushers out there.
It isn't about building tools. It's about building the cultures that, like the temple builders in Japan, are allowed to select their own tools and to be able to adapt them to their needs over time.
Ruth. There is an old quote, and I can't remember who it was who said: "See a need and fill it." Find the need first and then write the tool that will enable us to do that exact task. It is not focusing on the tool itself, it's about focusing on why we need the tool and where we are going to use it.
Kendra. I think that the more successful tools have flexibility for tailoring built into them. I think the concept of having composition and plug ins — I need this and this, and I need them to plug together — that has a lot of benefit to it as well.
Q9. Vikram Jumwal, TCS Integration Labs, India We sometimes talk about "scaling" the use of tools. Is the focus on extending the capabilities of the tool (to satisfy many different tool users)? Or is the focus reusing product ideas, where a tool might help developers to carry successful design ideas from one project to another?
Cope. Academics and "scale and scope" are things you don't often see in the same sentence.
Steve Fraser. Most tools research is done on a very limited set of projects. When you study only 5 or 10 case studies, you never really address industrial scope.
Giancarlo. The tools research community and the tool users should try to work together.
Q10. Dennis Mancl, Alcatel-Lucent In open source tools, many successful tools are "forked" — new spin-offs or variations of the tool are created. Is this a good thing or a bad thing?
Diomidis. Forking is good. Sites like github make forking easier — as a tool developer, you can get back results from forks that you can integrate back into your original product.
Junilu. In industry, I think forking can cause a lot of confusion. For example, the fork of Hudson and Jenkins (continuous integration build management tools) has caused many teams to ask "OK, what do we do now? Which way do we go?"
On the other hand, competition and variety does make the environment richer.
Cope. I think it only creates confusion among those who want to be told what to do. The other way is twisting Dennis's perspective a bit, I don't think it is forking so much as the opportunity for human intervention.
There is a line between what automation should do and what humans should do. Toyota tries to use a combined approach called "autonomation", where the responsibility of computers is to detect the problem, but solving the problem is for humans.
There is a great book by Steve Johnson called Where Good Ideas Come From that talks about progress and innovation as a result of loose, low-context things interacting in large numbers by large numbers of people. Society invents, not individuals or tools.
Ruth. Kendra mentioned earlier that she manipulated tools to do what she wanted to do. What is very important is the evolution of tools to fulfill the need.
Giancarlo. Forking is indeed good. But openness and compatibility are important. We have seen throughout history that compatibility is a key ingredient of success of any software tool. And compatibility does not always work well together with tools.
Kendra. Students benefit from open source projects and the ability to build an exploratory fork on top of an existing system. If for example a student is investigating a tailored version of UML to support some paradigm (aspects, agents, or whatever), the amount of time it will take the student to redevelop a modeling tool would be tremendous.
Cope. I think it was Frank Lloyd Wright who talked about tools, and he said the most valuable tool on construction is the hammer to break things, and in the drawing room is the eraser.
Computer tools are not the answer. We always have a tendency to jump to a computer solution when a cards on the table would be just fine. I think graduates have plenty of time to do an analysis tool to support their needs. Just keep them away from the computer. This is about thinking, not about computing.
Summations:
Cope. Tools suck.
Steve Fraser. And tools research?
Cope. Irrelevant.
Junilu. As a guy who mainly uses tools, I don't think tools suck. They help me do my job. But I hope than any research will focus more not on the individual tool but on the team, the people, the community that needs to build things.
Kendra. I think tools are cool, and I think we need interdisciplinary studies of tools, their usage, and design. I also think that open source tools are rapidly replacing commercial tools, except for very specialized cases. Turning what we traditionally call tools into more of a game-like application has a lot of potential.
Ruth. In the area of software tools research, I think we need more trust between industry and academics. If you (industry) don't trust, we can't get in and do the research. If you don't trust us to keep your data confidential and still do the analysis, we'll never get there.
So I want to end with a plea to industry to say "Work more with the the academics, so you don't have to continue speaking them down."
Giancarlo. We need our tools to allow developers to reflect more on how they use tools.
Diomidis. I think we should seize upon this opportunity to build tools, and to build tools that are bricks that others can use to build on top of that — and not monoliths that stand isolated and impose their view on others.