Follow us on Twitter at http://twitter.com/blogCACM
The Communications Web site, http://cacm.acm.org,
features more than a dozen bloggers in the BLOG@CACM
community. In each issue of Communications, we’ll publish
selected posts or excerpts.
implement some other huge changes,
often simply for the sake of doing so.
Let’s take a closer look at what I mean.
Let’s say a new developer joins the
team. At first, he checks all the boxes.
He knows his code, he’s got energy, he’s
easy to communicate with, and he’s
putting in time, submitting new tickets
and offering useful suggestions. During those first few days, he seems like a
gift from the heavens.
As he learns more about the project,
the hazardous enthusiasm starts to
creep in. Instead of tickets with helpful suggestions, he hits me up on Telegram with a bold claim: the architecture is a complete and utter mess, and
I’ve got just a matter of weeks before
the project will implode.
I counter with a polite reassurance
that I understand, but before even
hearing me out, he’s already suggest-
ing that we re-do everything from
scratch. At the very least, he suggests
we trash a collection of objects, and
replace them with a singleton and
a particular ORM library. Of course,
he’s been using these for months, and
they’re amazing and as soon as I see
everything in action I’m going to be
floored and, and, and …
Now at this stage, there’s a lot I will
probably want to say. I could remind
him that I am an architect myself, and
that I have a long string of successes un-
der my belt. I might point out that we’ve
been working on this project for some
time and that so far development is pro-
gressing at a comfortable pace.
Often, however, I say very little
and instead ask him to submit a ticket. I offer an assurance: I’ll review
his suggestions as soon as possible.
And I casually remind him that I am
an architect, and in fact the architect
for this project. In an ideal world,
he’d accept that and follow up some
incremental changes. More often,
he claims that he’ll show me how it’s
supposed to be done.
A few days later, he hits me up with
a huge pull request. There are tons
of changes, and some of them actually look quite interesting. The problem is, a lot of the suggestions are all
but antithetical to the principles I’ve
embedded into the existing architecture. I know he’s put a lot of time into
his project, but I have to reject the
pull request anyway.
Can you guess what happens next?
The developer, once a godsend, simply ups and disappears. You see, I’m
and How Eagerness
Can Kill A Project
June 27, 2019
Programmers are constantly contribut-
ing to my open source projects (all of
my projects are open source, FYI). Some
are volunteering their time, others are
paid through Zerocracy. While I have
worked with a lot of great developers
over the years, I have also come across
a number of people afflicted with what
I call “hazardous enthusiasm.”
These people have energy and of-
ten the skills, but are overzealous and
don’t know how to break down their
changes and deliver them incremental-
ly. People afflicted with hazardous en-
thusiasm frequently want to tear down
and rebuild the entire architecture or
and Thinking about
Yegor Bugayenko ponders the dangers of “hazardous enthusiasm,”
while Mark Guzdial considers whether the need to teach
computational thinking can be “designed away.”