What are the best elements of Agile, in
your opinion?
Among the best is the idea of developing in short iterations of two to six
weeks. This has profoundly transformed
the software industry for the better, and
no one develops software anymore by
assembling a few groups who tackle different parts of the program and will see
each other in six months.
Another example is what I call the
closed-window rule, an absolutely brilliant idea—that when you have an iteration, you schedule a certain number of
tasks, and absolutely no one, regardless
of rank, is permitted to add anything during that iteration. This rule has a number of benefits. It stabilizes the whole
process and prevents bosses and managers from interrupting the iteration. It
also has the benefit of weeding out bad
ideas, because many suggestions that
seem brilliant don’t look so good when
you wake up sober the next day.
And the worst?
In the opposite camp, you have the
general rejection of what’s derisively
called “big upfront anything”—big upfront requirements, big upfront design.
The Agile credo is that you should start
implementing part of the system right
away and not engage in long, early phases of architecture or investigation. The
Agile world has this phobia of not producing anything that’s not deliverable to
the customer. And as is so often the case
with Agile ideas, there’s a grain of truth
in this rejection, because the customer
does not need specifications. The customer needs results. But the idea that
it’s bad to spend an appropriate time
at the beginning of the project to clarify
the overall requirements and design is
nonsense. You do need at some point to
focus on the deliverables; but until then
you should take all the time necessary
to address the big issues of specification and design. I’ve seen projects fail
miserably for blindly applying the Agile
catechism: we’re Agile, we don’t need
to stop and think, we just go ahead and
code! Not surprisingly, what they code is
junk and they have to redo it, but maybe
at that point the money has run out and
the customer has lost faith.
Leah Hoffmann is a technology writer based in Piermont, NY.
© 2015 ACM 0001-0782/15/03 $15.00
where to take the introductory pro-
gramming course offered at ETH.
Coming from industry, the last
thing I expected to do was to teach
bright-eyed 19-year-olds the rudiments
of programming, let alone in German,
or my imitation of it. Yet it has been
one of the most exciting things I have
done at ETH. I started looking in depth
at how we can teach programming today to kids who have been using smartphones and videogames all their lives,
and need the competitive advantage of
becoming true professionals.
I use Eiffel and Design by Contract
right from the start. The experience
resulted in a textbook, Touch of Class,
and more recently I dived head-on
into MOOCs, first producing a kind of
skunkworks MOOC outside of any organizational structure at the initiative
of my colleague Marco Piccioni. Now
we have redone it in a completely official context and it’s an edX offering.
It applies the same pedagogical principles as our course and also benefits
from our research on distributed software development; students can compile and run programming exercises
online, as quizzes in the course, and
see the results right away.
You also recently published a book
on Agile development methods with
the subtitle “The Good, the Hype and
the Ugly.”
Usually, when you see a novel idea in
software engineering, you can quickly
recognize whether it’s good or bad.
What’s special about Agile is that it’s a
mix of the best and the worst. My book
is a cool-headed attempt to separate
the wheat from the chaff.
Wirth had
retired from ETH and I received an
invitation to take on a chair. It took
me a year to organize the transfer, because I had my company to deal with,
and I couldn’t just drop it overnight.
And it’s a long flight from Santa Barbara to Zurich. Nonetheless, I dived
headfirst into the academic world.
Yet you have remained involved with
Eiffel Software.
The trick for me has been not to develop a dual personality. I’m the same
person whether I work as a professor or
whether I’m devoting time to the company, and my research is still in the context and philosophy of Eiffel. If you want
to survive as a company, you have to do
what the customers want. In academia,
you can play with crazy ideas and experiment without regard to what you can
sell. You’re not going to hit the scientific
jackpot every time. But once in a while,
you are ahead of the game and do things
that you cannot do in a company if you
are focused on the bottom line.
What specific elements of EiffelStudio
have evolved through your academic
work?
Eiffel offers you the ability to test
programs automatically—and it really
is completely automatic in the sense
that everything is generated by the software, even the test cases. That started
out in an academic context at ETH and
was refined through several excellent
Ph.D. theses.
The much more ambitious goal,
which has been made possible by a succession of Ph.D. theses, is the idea of
fully verified software. For a long time,
that looked like a purely intellectual
pursuit, but it’s now becoming a reality. We call it EVE, the Eiffel Verification
Environment. There’s still a lot of work
to be done, and we have benefited from
tremendous advances in technology, in
particular the Boogie tools from Microsoft Research. But it’s becoming realistic to imagine that we can take large, re-al-life programs and prove that they’re
correct. And if they’re not correct, we
can also—that’s another part of the EVE
research—automatically suggest fixes.
On the teaching side, you helped pro-
duce a MOOC (Massive Open Online
Course) that enables students any-
“The trick for me has
been not to develop
a dual personality.
I’m the same person
whether I work as
a professor or
whether I’m devoting
time to the company.”
[CONTINUED FROM P. 96]
