[Twisted-Python] Evangelism notes...

Mike C. Fletcher mcfletch at rogers.com
Wed May 4 16:08:12 EDT 2005

As some of you know, I use Twisted to develop one of our products, a
fairly large Cable modem management application. I've developed and
released TwistedSNMP, and am, generally speaking comfortable with the
package.  I've also been using Twisted within the company for my other
projects.  I've just come back from a meeting where a decision was made
to completely rewrite a *delivered* application on our own dime for the
sole purpose of eliminating Twisted.

I found this rather disappointing.

I realise that the problem lay in part in my own "choice" (didn't
actually choose, it just happened) of projects with which to introduce
Twisted, but I felt it would be useful to share the experience with others.

The Project:

    * Cross-protocol server intended to act as a "web services"
      intermediary for payment-processing services from a number of
      different banking systems.
          o Fairly straightforward networking protocols on all sides
          o All protocols were custom (i.e. we had to write them) save
            the client-side interface (which was XMLRPC)
          o Seems like a perfect problem domain for Twisted
    * Initially coded using Twisted by me, then pair programming with a
      colleague as he took over lead on the project
          o If my goal had initially been to evangelise, I should have
            *started* the project with pair programming so that the
            system wasn't already in-place and mystifyingly complex
                + Even the Finger sample is mystifyingly complex if you
                  jump into it at the end of the process
                + Unfortunately, I didn't realise the project would be
                  passed on to someone else before completion, I'd
                  thought it would remain part of my portfolio within
                  the company
                + Even if we did start out together, we really should
                  have done some *formal* training on Twisted, rather
                  than relying on knowledge transfer via pair
                  programming.  Again, it started out just being a few
                  lines here and there, we didn't see much being done
                  beyond the base system.
          o He never, in the entire process, saw anything really come
            from Twisted (other than problems where the complexity of
            the system got in the way of doing the rather simple task
            (from his point of view)), since the low-level coding was
            already done when he started working with the system.
                + Probably would have been better to start him on the
                  much larger project, where Twisted represents far less
                  of the overall complexity of the application.
          o In particular, test-driven development with threading in the
            background for blocking operations caused significant headaches
    * Project was delivered, paid for, and has been running in
      production for a few weeks, but 2 reported bugs cropped up
          o To fix one, needed to update to 2.0 (deferred object
            cleanup)... this caused rather a lot of upset, as the
            sysadmins were upset about such a huge package needing to be
            updated (and they tried to do just the core packages first,
            which doubled the work-load involved in preparing that
            update versus using Sumo)
          o Fixing the other was no big deal, except that something in
            2.0 changed how the test-suite was running so that it now
            hung on completion...
    * Now, at this point there had been serious conversations just an
      hour earlier during a management meeting about replacing Twisted
      for 2 separate projects.  The entire company is watching as we go
      to fix the *trivial* error while we're together after the
      meeting... but the test suite won't complete.  Must be something
      wrong with the background thread not exiting thinks I.
          o What do we call to shutdown the threadpool?  I don't
            remember, let's check the reference docs... 20 minutes of
            searching for the 2.0 reference docs (with the entire
            company watching this)... finally ask on IRC... told to
            build them myself and contribute them.  Cute, but didn't
            really drive home the whole "robust, professional,
            well-documented platform on which to develop business
            systems" meme as much as I'd hoped.  (Some of that is
            definitely my fault, I was pretty frustrated by the time I
            went to IRC to ask where the documentation was).
          o Finally go with the 1.3 docs, hoping there's not some change
            to the API that's causing the problem (though that looks
            very probable at this point, the change to 2.0 being the
            primary difference between working and not).
    * Finally get the 1.3 docs, hack together a
      reactor.threadpool.stop() call with a dummy last-run-test-suite
      and get the test suite to run-and-exit...
          o Keep in mind, we've just had to introduce a glaringly ugly
            and fragile hack to get around something trivial.  There may
            be a better way to run the tests, but it's a bit late for
            thinking of that now...
    * Now that we can run the test suite and focus on what happens
      during it, we discover that the ESMTP client can't connect to a
      local SMTP host without authentication (or at least, it wouldn't
      with the code we were using across the network to a remote
      host)... no documentation on the ESMTP client, of course.[1]
    * At which point my colleague (lead on this project) got well and
      truly fed up and decided to dump Twisted and rewrite the project
      in plain-old-Python.

There's lots of points where, had I anticipated the problems, I might
have salvaged the project in its current state.  If I'd anticipated that
the problems would be non-trivial to fix, I could simply have returned
to my workstation and fixed them in a relaxed and pressure-free
environment.  I could have spelunked through the code to figure out the
interfaces in lieu of documentation.  That's fine for me, I already
understand Twisted enough to spelunk through and find what I want, but
it doesn't make a great argument when someone's simply mystified by all
the pieces scattered here and there that seem to be joined by nothing
more than hope and bailing wire.

I could have done better at evangelising. In the end, though, I had to
concede that stripping out Twisted and writing the code himself would
probably be faster and easier in the long run than trying to work around
problems in an under-documented "foreign" system (again, from his

Especially given the small size of the project, a few simple select
loops and a thread can solve 90% of what Twisted is providing for him. 
Thinking back on that conversation; at that point the *only* failing
feature was the ESMTP-sending, and I'm pretty sure it would have
resolved to something like passing a None instead of a "" for the
username and password; but when it came right down to it, he's the one
maintaining the code, and as far as he can see, Twisted just gets in the

Don't know if the other project will be rewritten as well.  Given
decision on this one, I'd imagine it will.  I'd also predict that
Twisted is now Techne non Grata wrt any new development where it's not
an explicit requirement (given that we're going to be eating costs on
rewriting a project to eliminate it).  Certainly I'll have a hard sell
going forward.

So, anyway, just felt the need to share that.  Sorry again for the sharp
post to IRC.

Peace, all,

[1] How did ESMTP get in there anyway, if it's a 1.3 codebase?  Well, it
shares common functionality with the big application, one piece of that
being the automated use of ESMTP.

  Mike C. Fletcher
  Designer, VR Plumber, Coder

More information about the Twisted-Python mailing list