
New GitHub Tool Lets Coders Build Software Like Bridges - gpresot
http://www.wired.com/2016/02/rebuilding-modern-software-is-like-rebuilding-the-bay-bridge/
======
dhatch387
Surprised Wired is writing about this. Scientist is a great release from GH. I
think the technique is powerful, but not particularly novel.

~~~
tartuffe78
Seems like native advertising

~~~
captn3m0
This is what I thought as well. I'd seen it yesterday, but couldn't correlate
that this article would be talking about the same tool after seeing the
headline. "Lets Coders Build Software Like Bridges" doesn't make it sound like
a refactoring toolkit at all.

Are bridges refactored 5 years after being built?

------
brudgers
Repository:
[https://github.com/github/scientist](https://github.com/github/scientist)

------
jdbernard
Scientist is cool. It's a little annoying that the article makes it seem like
no one has thought of this before Github. But whatever, maybe more people will
learn about the pattern and use it.

The other implicit conclusion that the article is making, that this will
somehow make software more like a traditional engineering discipline also
makes me a little uncomfortable. There still is no silver bullet.
[http://c2.com/cgi/wiki?NoSilverBullet](http://c2.com/cgi/wiki?NoSilverBullet)

~~~
anentropic
is there a generic name for this type of thing? not sure how to google for
existing implementations

~~~
jdbernard
The article, and the Github repo use the name Branch By Abstraction[1]. It is
related to the idea of a Strangler Application [2]

[1]
[http://martinfowler.com/bliki/BranchByAbstraction.html](http://martinfowler.com/bliki/BranchByAbstraction.html)

[2]
[http://www.martinfowler.com/bliki/StranglerApplication.html](http://www.martinfowler.com/bliki/StranglerApplication.html)

~~~
DonHopkins
Oh that's a great name for a pattern. I can't wait for Craigslist to release
their software migration tool, the Craigslist Strangler.

"There's another important idea here - when designing a new application you
should design it in such a way as to make it easier for it to be strangled in
the future. Let's face it, all we are doing is writing tomorrow's legacy
software today. By making it easy to be strangled in the future, you are
enabling the graceful fading away of today's work." -Martin Fowler

------
robgibbons
Forgive my ignorance, but how does this approach differ from traditional unit
testing or end to end testing?

My point being that unit testing essentially gives you the same confidence in
your refactoring efforts that Scientist proposes to offer. Tests already
demand that your interface remains the same, and that old code does no harm
when replacng legacy.

~~~
rhinoceraptor
This [1] is a good writeup on how they used it to replace the merge that
github uses. You can't really capture the totality of corner cases in unit
tests, especially for complicated things.

[1]: [http://githubengineering.com/move-
fast/](http://githubengineering.com/move-fast/)

------
lunula
The name "Scientist" is about as good as "Engineer" or "Programmer." In other
words, extremely confusing when used as a product name in a technical domain!

~~~
hnbrox
the name is a bit annoying. seems very dude-cool-name-syndrome.

~~~
wanda
They really hammer it home with the emoji commit messages.

There's also exhibit C:

From Github repository "Scientist" : README.md

    
    
        "How do I science?"

------
brightball
I got really excited about this thinking that it was something that worked
outside of the code base as an interface proxy that could work cross-language.

~~~
ivan_ah
Yes, I was imagining a "traffic demultiplexer" of some sort that could feed
the old and new backend in parallel and observe they have the same behaviour.

I think something like that would be useful for a lot of people in industry
who have to maintain legacy monoliths. The ideal tool would allow "switchover"
from old to new gradually, one URL endpoint at a time.

This can be used to replay traffic
[https://github.com/buger/gor/](https://github.com/buger/gor/) so can do load
testing at least...

------
markbnj
What is the difference between this and writing your services to an API that
runs behind something like haproxy that can be quickly configured to direct
requests to whatever stack you like?

~~~
jbrooksuk
Scientist seems to run both versions of the code.

~~~
markbnj
Both versions of an API can run behind haproxy as well, and requests can be
switched between them based on many different criteria from OSI layer 4 on up.
I guess I just don't see what was novel or interesting about the basic idea of
switching between two implementations that satisfy a declared interface. It
was just a few years back that DI was all the rage.

------
GreaterFool
tl;dr small (and perhaps cool?) Ruby library?

Headline got me excited but then I ended up at the GitHub page.

------
raimue
The analogy does not seem to fit. Of course they built the new bridge before
tearing down the old one. There is not really an option to divert traffic, it
has to cross the bay.

The Scientist software copies the input and feeds it into two systems in
parallel. There is no analogy for that in real life. There is no way to copy
cars.

And I really hope they do not actually need to run load tests for bridges
after they have been built.

~~~
libria
Lot of comments here attacking the analogy. It's just a throwaway analogy. Can
we just overlook non-essential parts of the article and discuss the code and
techniques instead?

~~~
astral303
I feel like I am being mislead with a sensationalist article. The tool has
already been discussed on HN.

Software engineering is extremely unlike bridges in that bridges get
constructed once. Software gets constructed (from source to machine code)
every time you build and run it.

------
brandonmenc
> She envisions aging banks using it to upgrade decades-old Fortran code to
> Ruby or any other modern language.

I know it's just an article, but...

If anyone thinks they should replace working Fortran code that does numerical
analysis with Ruby, they should be fired.

~~~
gravypod
You have to conflicting issues on this point.

The first being that the code works fine, the deployment works fine,
everything is working just fine. Do. Not. Touch. It.

These are some of the most financially important systems in America to date.
It's not a question about if they have to work, it's a question about just how
bad things would get if they didn't work for even a day.

The next problem that comes up is what happens when someone finds a bug 60,
40, or even 10 years in the future? What happens when some of this old
hardware breaks and it becomes not only impossible to find replacement parts
but also impossible to fabricate new ones in house.

Eventually, like all languages, Fortran will die out as time goes on. So few
people know it now that it is inevitable.

Eventually something has to give and we can do two things until then.

1\. Wait for time to pass and pretend nothing will ever happen to these
machines.

2\. Slowly start rewriting all of the stack, and transferring everything to
more modern systems designed to be just as long term as their predecessors so
that in the event of a replacement being needed it exists.

I don't know about anyone else, but I like to have backups/fallbacks when
planning for the future.

I'm not saying that Ruby or any new language should be entrusted with this
kind of responsibility. But there needs to be a decision and it needs to be
made over the next couple of decades.

~~~
plq
> What happens when some of this old hardware breaks and it becomes not only
> impossible to find replacement parts but also impossible to fabricate new
> ones in house.

You get a modern Fortran compiler, you compile the old code for the new stuff
and off you go. What am I missing?

> Eventually, like all languages, Fortran will die out as time goes on. So few
> people know it now that it is inevitable.

Like _ALL_ languages? Ha, tell that to the COBOL programmers at the heart of
some financial institutions mate. Heck, RPG is still supported on some IBM
hardware.

~~~
gravypod
I'm talking about languages on a larger scale. Do you mean to tell me that
COBOL or Fortran will last _forever_?

All languages die out eventually. It does not matter that it is a programming
language, the concept will remain.

Nothing is perpetual, nothing lasts forever. I hate to break it to you, but
eventually something will give.

------
niftylettuce
It's a shame GitHub puts effort into stuff like this as opposed to actually
listening to their users (e.g. "Dear GitHub"). We can infer a shift from
GitHub to alternate services soon from this, unless they change.

~~~
skewart
To be fair, developing something like this is probably orthogonal to
developing the kinds features they have been neglecting to develop recently.
Scientist was probably entirely within engineering, and not a massive effort.
Making the things users are asking for would be a much bigger effort across
the organization.

But, I do completely agree that they've been dropping the ball lately.

------
mannykannot
This is a really unfortunate choice of an example - the replacement bridge has
suffered enormous cost overruns.

[http://www.citylab.com/politics/2015/10/from-250-million-
to-...](http://www.citylab.com/politics/2015/10/from-250-million-
to-65-billion-the-bay-bridge-cost-overrun/410254/)

------
thesz
Nobody mentioned Erlang so far.

My biggest disappointment with "Scientist" is that it basically provides
service which Erlang code has for free - hot code reloading. For decades now.
Along with other cool features like great support for parallel execution,
hierarchical monitoring and so on.

Article mentions some early user raves about this tool in context of "it
allows me do refactoring!"

Of course it would help, but there are languages that either have all this
cool stuff for decades (Erlang), or can allow you to do heavy refatoring
without asking for help from "interesting" tools like this "Scientist"
(Haskell).

~~~
Qwertious
"The greatest form of flattery is imitation."

Huh, does that apply less if they've basically never heard of you when they
imitate you? Not to imply that Erlang is unheard of, I'm just saying it's not
as popular and orthodox as Python/Ruby/C/java/etc.

~~~
thesz
There is a variant of hot code reloading (dynamic binary program patching) for
C.

[http://www.cs.umd.edu/~hollings/papers/apijournal.pdf](http://www.cs.umd.edu/~hollings/papers/apijournal.pdf)

And there even older one (I cannot find because search in my blog (LJ) is
broken).

