00:00:00.000
I am Nathan walls and I am a software
00:00:16.260
developer at vitalSource technologies were the primary office I work out of is
00:00:21.990
in Raleigh North Carolina but we've got offices here and there we're owned by a encrypt contact group
00:00:27.269
and they're headquartered in Luverne Tennessee today what I'm going to be doing is talking about a history of the
00:00:33.540
suite of our applications organized around common core and this court dates
00:00:39.450
back to the very early days of Ruby on Rails so I'm going to start out by doing
00:00:44.640
a little bit of stage setting this here on this chart is a rolled up aggregation
00:00:52.050
of seven different repositories that we have dating from August 2 of 2005 all
00:01:00.300
the way to this past week showing the number of commits per week it's not broken up by repository this is just
00:01:06.869
like an aggregate number of commits it represents a substantial but you know
00:01:13.619
fundamentally incomplete view of what one segment of what our company does so
00:01:22.189
overall is you look from the left side to the right side you kind of see that there's a general trend line that goes
00:01:27.659
you know very ever so slightly up into the right and then you look just past
00:01:34.009
this area around 2015 into 2016
00:01:39.270
and you see a giant spike there on the right side of the graph we're going to
00:01:44.759
set it we're going to take a deeper look at that a little bit later in the talk but the nice thing is that with these
00:01:50.909
seven repositories we have a lot of history starting from subversion going all the way through our transition to
00:01:56.640
get so I'm going to start with a little
00:02:01.860
bit of a prologue here vitalSource does a number of things around eBook
00:02:07.020
publishing we allow publishers to send us books to build they can set prices
00:02:13.930
determine availability different different things along that nature and then we will sell them on to end-users
00:02:21.420
particularly students in learning applications might start with this began
00:02:28.209
in actually had this wrong this should be October 2015 we're in the middle of
00:02:34.569
an upgrade from rails 2.3 and Ruby 187 and I was gaining experience across the
00:02:40.900
app suite by working on this project and one of the pieces that we needed to do was upgrade a lot of JavaScript reason
00:02:49.780
being is that the app used a lot of prototype which was going away in favor
00:02:55.329
of jQuery we had a lot of the old rjs style link to remote and link to remote
00:03:01.930
guess calls and a few other underscore remote methods that we were using and
00:03:15.549
was just magical Ruby incantations that became javascript in the browser so this
00:03:23.859
led to upgrading that non - non Ruby flavored JavaScript basically consolidating on one version at jQuery
00:03:30.849
and so on and as part of this process I come across some very early code and I
00:03:37.989
run git flame and that leads to a discovery and part of what I see is some
00:03:43.780
code from the original maintainer of or the original committer on the projects that I'm working on and
00:03:50.459
so that leads me to go to Twitter and say hey yeah I've looked at some very
00:03:56.139
old code today and this was originally started by Dan Benjamin - you may know
00:04:02.799
from podcasting Fame and he actually got to actually wrote back in was a bit astonished that this code that he had
00:04:08.889
written back in 2005 and had worked on for a little while was still in use and substantially the same as when he had
00:04:16.090
written it so I got a bit curious about
00:04:21.370
the history of this looking at the code across several of our just
00:04:26.419
connected codebases and in preparing for this talk and in earlier you have talked
00:04:32.300
to several members of the development team past and present and talked to members of the business team who are
00:04:38.389
basically present for the inception and the continuing behavior or the growth of
00:04:46.159
these applications and that's we're going to talk about today we're going to
00:04:51.169
talk about team growth and changes at a high level in practices between
00:04:56.629
interactions between the business and between it with developers code growth a
00:05:02.180
little bit and then how we've how that code has changed we're going to go into
00:05:07.879
some code examples not many but we'll get to see a little bit we're going to
00:05:13.430
see how developers and business interact and then we'll spend some time looking at reflections and available lessons and
00:05:21.229
then we'll also talk about some tools that folks can use to actually come at
00:05:26.960
some of these these understandings and lessons that they can draw out of their
00:05:32.750
own code bases as I was putting this together there were two quotes that came
00:05:40.490
up one of one of which which is kind of an offhanded comment and that was in the
00:05:47.300
absence of logic there's history and then a couple that Canada the second one came up a couple of times from two
00:05:54.589
different people and that was it seemed like a good idea at the time so in a
00:06:02.180
twelve-year-old codebase there's going to be a lot of lessons learned there's going to be a lot of changes to best
00:06:10.310
practices best best practices are going to evolve and you're not going to start
00:06:16.729
out having all of these in hand to start with but the nice thing is is that this
00:06:24.050
code has been around for 12 years because it has actually been successful for the business and the business has been successful so that's why we still
00:06:31.669
get to work with it so I'm going to go through the history in in for axe
00:06:38.920
first one is with the appearance of rails and David touched on some of this
00:06:46.490
this morning in his opening keynote but this was the the original announcement
00:06:52.490
to the Ruby Langley list about rail 0.50
00:06:57.830
and that the thing that he had been talking about was actually out there and people could look at it now remember
00:07:04.610
this is before ruby gems was a thing this is before github was a thing this
00:07:09.980
was you know just throwing a library out there and seeing you who would kind of
00:07:15.650
grab onto it and go with it so this is July of 2004 over at vitalSource
00:07:24.890
technologies there's been you know a series of kind of cobbled together
00:07:30.800
automation steps around building and assembling ebooks there was a lot it was
00:07:36.200
basically a lot of Java in place but there was a sense that it was a very
00:07:42.140
limited process and the folks who were working on that were kind of basically overwhelmed with its limitations and
00:07:49.970
there was also a desire to have a very visual process and so something like rails coming along actually made it
00:07:57.350
feasible to build a robust web application so rails comes in and Dan
00:08:07.220
had actually been experimenting with rails and he found that he liked working with that more than working with a
00:08:14.240
combination of a PHP front-end and Java back-end and so he and another developer
00:08:19.670
Damon clink sales basically started building they started building this at
00:08:25.300
the Apple Worldwide Developer Conference I believe this would have been 2005 and they skipped most of the sessions to
00:08:32.360
actually start writing this new rails application with Dan's focused on writing a front-end piece and Damon
00:08:39.080
focused on writing the backend piece now looking back at this there's a lot that
00:08:46.340
we count on in rails today that was not there Ajax was new
00:08:51.540
prototype and jQuery did not exist and the Russ conventions that were so
00:08:56.759
familiar with were not actually part of Rails yet and what people were used to
00:09:02.220
with api's were very much around having xml-rpc style or soap style or you know
00:09:08.880
if you did it you kind of combine flavors and you if you look at the
00:09:13.889
original rails codebase that's spun up with this you actually get a whizzle file that comes up in your routes file
00:09:20.639
which I found really interesting the other things that we didn't have at that
00:09:27.389
time is Capistrano wasn't around so there was you deployments did not have
00:09:32.730
the Roebourne path and so there's a lot of these things that we think of as fully baked into rails or how rails
00:09:38.970
applications get get shipped now that you had to get figured out but they but
00:09:46.709
they got it figured out and so this is the first commit message I apologize for the readability this is it's ended up a
00:09:53.100
bit smaller than I thought but this is about four hundred files from that first pass at the app that got committed back
00:10:00.329
in August of 2005 and what the changelog
00:10:06.959
has is that this was using rails 0.11 dot one from March 27th of 2005 one of
00:10:18.149
the controllers that got committed here was the library's controller we still have one of these in our app today but
00:10:24.449
as you can see here that it's still somewhat recognizable as Ruby code and somewhat recognizable as rails code but
00:10:31.170
it looks very different than how we might ordinarily bright a rails controller today so that's the start of
00:10:40.529
Phoenix which became which kind of was renamed into connect in time and then it has more recently become an application
00:10:47.819
called manage but there's another application and that's p2 services which
00:10:53.040
is a essentially a services layer and that was came along in 2000 2006 around
00:11:02.220
this time frame rails hits one dot Oh in December five rails 1.1 which brought in rjs and
00:11:10.250
being able to write those magic the magic ruby incantations that would give you JavaScript for for Ajax and remotes
00:11:17.620
came around in 2006 1.2 brought in rest
00:11:24.110
and the rest conventions that were more familiar with today started their hit
00:11:29.390
2.0 in 2007 and 2.3 and 2009 skipping over a few releases here act 2 growing
00:11:40.460
the business the code and the frustrations that come along with it rails marches forward Heroku gets
00:11:47.210
founded github gets founded passenger comes out which which helps out the
00:11:52.610
deployment story verses see if I remember at the time there was a lot of mongrel in use at the time and rails you
00:12:01.100
know is kind of riding high it's like oh hey you know if you're building an app you're building it in rails was kind of it was kind of the default thing or a
00:12:09.740
vital source you the the growth of these applications was actually starting to
00:12:15.020
outgrow how the development organization worked and so there's a tension between
00:12:22.300
building on features versus time taken to like go research business problems answer customer questions and that sort
00:12:28.010
of thing and all of this ended up being driven being very business driven and
00:12:33.350
very interrupt driven and so it was you know some of the developers who were present at the time found it you kind of
00:12:38.930
frustrating to actually get work done developers had managers at the time but
00:12:44.060
their direct interaction with that met with their managers was fairly minimal
00:12:50.350
the applications grew and developers had typically had areas and tasks
00:12:57.490
specialization so I mean it's kind of a natural way of saying folks got siloed but folks kind of you know developed
00:13:04.550
areas of the code that they're comfortable with and areas of the code started developing their style so you
00:13:10.400
can you look through different parts the application and how you this developer was involved in writing this
00:13:17.030
substantially or wrote whole thing the number of applications
00:13:22.650
grew so Phoenix that original kind of front-end application and the database
00:13:30.240
layer started in 2005 there were VST
00:13:35.280
models and t2 services which was wavy see models of the way of saying hey we're going to take our models and we're
00:13:40.410
going to share them between this codebase and the services layer in a third repository in time the migrations
00:13:50.010
moved out into their own application called Goose and then we had a couple of
00:13:55.980
reporting applications for basically providing business data back and those
00:14:02.100
that was reporter and uber reporter and then a third version of our API layer
00:14:08.520
because p2 services involved two different versions came out in 2010
00:14:17.120
there's a limitation along the way and that is that this suite of applications
00:14:24.510
along with others that were that were running rails we're all going to basically be locked together in terms of
00:14:31.740
versions so everything was going to be running Ruby 187 and rails 2.3 and the
00:14:37.860
idea there was we only want to have machines that look one way and so if we
00:14:45.990
need to repurpose machines we can ship them to any other application and there's no there's nothing to shift about them do any any application can
00:14:52.770
run on any machine this started to become a limiting factor because rails
00:15:00.150
hit 3.0 in 2010 this I'm sure folks who
00:15:06.450
were in doing rails development back then remember this was the big community merge with merb there were also a lot of
00:15:15.870
like active record changes around that time Ruby itself hits 1.9.3 and we're
00:15:22.470
starting to try and get out of the perceived performance detriment performative of Ruby 187 Ruby Enterprise
00:15:30.060
Edition around this time - which was kind of a performance optimized version of 187 that's the folks behind fusion
00:15:36.090
passengers hold Ruby to Rails 3.2 ruby
00:15:42.450
2.2 or 2.0 rails 4 and rails 4.2 all followed at the company it's now about
00:15:54.000
2013 and a new CT arrived and not long
00:15:59.370
after there's a new development director as well and here we start seeing some
00:16:06.450
process and organizational changes and the team is starting to get out of the
00:16:11.790
mindset of shipping everything as soon as possible and more thinking about having very like batch work building
00:16:21.420
things to be more testable you know we have there's much further to go with this and really trying to have the
00:16:28.740
technical management provide kind of an umbrella for development to basically
00:16:33.779
shield them from you know incoming requests that are you important
00:16:39.000
questions to answer but maybe like you know are you happy you're having to answer questions or you need feature
00:16:45.120
shift and trying to figure out a good balance of that and then we had product
00:16:50.700
managers come in as well so - basically you take input from the business about how to shape feature work and that sort
00:16:56.820
of thing bugs that needed to get get addressed questions that need answering rather than taking that input directly
00:17:03.000
from the business itself and so work continued but the upgrades did not so in
00:17:10.980
time of the the requirement to have kind of that lock step that I talked about where everything is going to be on Ruby
00:17:17.790
187 and rails 2.3 that got lifted but as consensus was building - for an upgrade
00:17:26.579
to say hey you know we really need to catch up with where the communities at
00:17:31.610
vitalSource bought is primary competitor in 2014 the competitor was a smart
00:17:39.660
and they were they had roughly the equivalent size business as vitalSource did and vital sources
00:17:48.030
then had to engage in the work of basically absorbing in digesting and changing all the applications to you
00:17:56.490
take on this new business I took about 18 months from 2014 to to mid 2015 and
00:18:05.520
that was everything from migrating users you know picking up either publishing agreements identifying functionality
00:18:12.960
that existed in one place but not in the other and making sure that it was present for what was going to be what was going to exist going forward and
00:18:19.220
then beginning work on a new combined storefront with features that core smart
00:18:25.590
had that vital source did not and of
00:18:30.690
course rails and Ruby kept moving and so now these seven five to ten year old
00:18:36.150
applications you know we're still stuck at Ruby 187 and 2.3 and now had an
00:18:42.900
18-month hit on them being able to deploy we come to act free where we
00:18:53.640
actually get to the big upgrade its fall 2005 and most of the work of integrating
00:19:00.390
core smart has been completed and a plan was made to get the applications upgraded and part of that was our CTO al
00:19:09.870
basically he's really an Operations fellow at heart once was you had to focus on
00:19:16.530
minimal downtime yet where no downtime deployments that sort of thing a really
00:19:22.679
avoiding operational impact on the business where we can and at that time
00:19:28.799
it was getting very hard to get continued support for Ruby 187 and rails
00:19:34.980
2.3 you could there were some quarters where you can still get security support
00:19:40.200
for them but by and large that it ended so the upgrade process got its start and
00:19:48.630
it was mostly a parallel effort across each the applications and it was
00:19:53.640
basically we took it as a stepwise progression from rails 3
00:19:58.860
from 2.3 when that was done we went to 3.1 when that was done and settled we
00:20:05.070
went to 3.2 and a 4.0 and a 4.1 to 4.2
00:20:10.370
we did the similar stepwise process through Ruby largely interspersed with
00:20:16.890
the versions of Ruby that would correspond with a version of rails at the time and that took I think I did
00:20:26.580
about seven months to get through everything and get it shipped tested and
00:20:32.850
and out and stable some of the
00:20:38.460
challenges that came along with that were mixing urgent work and upgrade work
00:20:44.720
we had a problem keeping divergent coded code bases shippable where if we have
00:20:53.700
the bulk of the work on these upgrades happening there was further back changes that would have bug fixes applied and
00:20:59.580
then we had to basically bring those bug fixes forward or we would have fixed bugs in the upgrade version and then might have backed toward something and
00:21:05.310
just trying to keep all of that balanced out was fairly challenging and further
00:21:11.310
to the fact that these seven applications all shared a database and so we had this basically coordinating
00:21:19.920
all the cross application dependencies such that the applications could go out in the right order such that they would
00:21:26.070
all continue to function when they shipped on the new code bases or on the upgraded code bases so some notable
00:21:34.890
challenges with that there were a lot of things about upgrading rails that kind
00:21:43.500
of like force the force their hand at 3.0 where there was functionality that
00:21:49.200
came in in before one that got deprecated at two and finally removed in three we had to move off of RJ templates
00:21:56.340
to two native JavaScript we had transitioned fully to TR B we
00:22:02.160
incorporated the asset pipeline at long last and then there's a lot of restructuring of active record queries
00:22:08.940
because there's been a lot of work that had gone in in with active record in that amount of time and we got that finally got to take
00:22:14.160
advantage of that the teens also shifted
00:22:19.560
so what had basically been you know a kind of a few silos here and there there
00:22:26.490
was an API and platform team that focused on back-end stuff they'd had a changeover in personnel and then that
00:22:35.040
team then then grew with some additional hiring and then for the front-end applications like connect there were
00:22:41.070
additional hires brought in and then there was additional textual management and product management brought in to
00:22:46.890
help those applications as well and then
00:22:53.510
using kind of some of the lessons learned that we'll talk about in a little bit a new application was started
00:23:00.750
and it basically took kind of the hard lessons of database coupling versus the
00:23:06.300
API layers and you we actually were able to say okay we're going to not go down
00:23:12.360
that same path and so when that new product started in early 2016
00:23:18.060
it basically instead of hooking into the same database it's had the hard
00:23:23.340
requirement of we're going to use an API layer instead and whatever they needed locally it would save locally but
00:23:29.910
anything that was in the core database over in Phoenix had to go over an API and would not actually directly touch
00:23:36.240
the database and because how rails is
00:23:42.230
being used has also evolved in that amount of time its rails on the server side but it's
00:23:48.960
delivered as a single page app using react on client side and that's been a model for more of our apps that were
00:23:56.040
that we're using going forward and it seems to be working really well for us we also start getting into some
00:24:03.120
technical culture ships here and the beginnings of some increased code review
00:24:09.030
culture a more collaborative work which is which is really good so we come to
00:24:15.060
act four and that is growing the code with a with a guided tactical approach
00:24:20.180
the review culture gets stronger earlier and here we get we come out of it we shift
00:24:26.190
our code reviews earlier we don't have a single person able to review or like
00:24:32.789
responsible for the for the final sign-off and so we're not waiting for that signup to happen and potentially potentially
00:24:38.309
throwing work back we start a version 4 of our API layer and here we're taking
00:24:44.970
JSON as the first preference with XML supported for external API s but as the
00:24:50.340
second choice gaze on you know if we said in our opinion is far far more
00:24:56.340
pleasant to work with and then some of the large JavaScript or large XML pieces that we've been working with we start
00:25:03.330
returning meaningful error messages with our API s and we're basically able to
00:25:08.460
take the experience of the earlier versions and integrations that incorporate that into that design we're
00:25:16.169
doing more upwards opportunistic refactoring now so lots of logic
00:25:21.629
extractions in the classes a lot of you know like oh hey let's set up controllers in this different way we we
00:25:29.700
went very controller heavy with our code early on and so now it's probably it's
00:25:35.100
probably closer what folks would expect more of now and that's you know more you service objects use cases for some of
00:25:41.700
the newer applications and then really trying to you only have the controller's
00:25:46.710
handle your interaction with the business object instead of directly you know trying to do everything as they had
00:25:53.100
been doing before as part of that we're also moving towards basically treating
00:26:00.480
the API as how you're going to interact with the core data in the central
00:26:05.700
database so you I think in time what we're looking to do is kind of get away
00:26:11.220
from having shared models between code bases we're going to get away from having shared migrations that have to
00:26:17.460
run in one repository and then you have to take the copy the database schema over to the other repositories to get that in sync and then basically anything
00:26:25.350
any data interaction takes place over an API transaction and then we've been you
00:26:31.769
know as folks have been using the UI pieces more we're also increasing you know the amount of work that we do
00:26:37.400
for API and integration work both internally and externally the other nice
00:26:44.090
thing about getting to getting to this point is that each team has the the ownership of when they upgrade to new
00:26:50.810
versions of rails and Ruby and so it's possible for them to either update to 2.4 and 5.0 basically when they feel
00:26:58.550
that they're ready to and want to take that work on the team that I'm working on currently we're probably going to
00:27:03.890
take this work on in the next month or two and then finally we're going to take on a UX refresh of the core application
00:27:11.750
because it hasn't changed a whole lot since 2005 when it was initially written we're going to be increasing our
00:27:18.440
automated test coverage basically filling pieces in development culture is
00:27:24.320
shifting towards keep the build green make sure there's tests write code that
00:27:29.900
is easier to test and you know when we're writing new features let's actually lead with having the automated
00:27:36.800
testing done when that feature shifts instead of trying to fill it in later and process why is we're refining we've
00:27:44.960
gone from most teams have gone from scrum to Kanban and each team kind of
00:27:50.780
gets to iterate on its own practices and how they how they handle their business in terms of you taking new work in from
00:27:56.030
the business where they retrospect putting new processes or taking processes the way that sort of thing in
00:28:04.850
in time we're moving some of these apps towards a well-earned retirement our
00:28:12.940
early service layer is is due to be
00:28:18.710
replaced and with our v4 layer with more up-to-date authentication mechanisms and
00:28:24.410
and more restful api is our two reporting applications that were written against this codebase are being replaced
00:28:31.460
with a more capable ETL based reporting application that's being written by
00:28:37.520
another development team and you know essentially we're taking the opportunity
00:28:43.190
to say you know it's okay to let these go we don't have to keep it we don't have to keep the
00:28:48.340
applications going in order to have the value for the other things that are that
00:28:53.390
we're still working on so some tools and methods that I think
00:28:58.880
are generally applicable to teams that are that are working with you know code
00:29:04.010
bases that are older than say six months or two years or what have you
00:29:09.500
code climate if you use it has a charming complexity graph and so what it
00:29:15.500
can be really neat to look at what this is basically find out what you have kind
00:29:20.540
of in the upper right-hand corner find out and then figure out how you want to
00:29:25.580
dig into okay why are we changing this a lot and why is the code quality suspect
00:29:32.600
for the change that we have to make and you know accordingly what kind of changes can we make to pull that
00:29:39.320
complexity insurance cord down you know can we can we extract logic can we you
00:29:45.290
know break apart some complexity and a more easily testable things things that don't have to change as much github has
00:29:54.590
code frequency graphs this is for the
00:29:59.630
Phoenix application and if you look kind of on the far right around 2015 on the
00:30:06.830
right-hand side you'll see kind of some spikes there that was where we were doing our upgrade work you'll remember
00:30:11.929
if you go back a I'll have it up on the screen again but the commits kind of
00:30:17.090
like we had a big spike in commits but overall the code added and practice and
00:30:22.190
change a whole lot or at least nearly as much as what we had back in if you look 2009 so if you're looking back to your
00:30:30.830
code base you can look at Oh what happened around this time frame that necessitated so many changes going on in
00:30:38.570
the code base that's that's kind of an area to dig into and look at more thoroughly here's another one from p2
00:30:46.549
services where basically we see a bit you know a bunch of spikes at different
00:30:54.320
points and so those are also things that we could dig into github also can show you the complete
00:31:01.230
history for individual files so if you go into a tree view for any commit hash
00:31:06.920
you pick out a file that you want to look at and then there's a nice history button it'll give you a nice graphical look at everything that is happened on
00:31:14.790
that file in that repository and that can be you'll see the commit message but you can also dive into context with the
00:31:20.970
other hashes and see what's going on there I also think it's very helpful to
00:31:26.460
to look at project release history so we're using rails we have we use a
00:31:33.150
number of gems we have our own project release history these are all things
00:31:39.510
that we can draw from to basically kind of figure out what's happened in a project and figure out how those how
00:31:45.810
those changes in our dependencies influences direction of our projects we
00:31:53.090
also have git log and I you use this to assemble the the commit charts that I
00:32:00.510
that I put up next but you basically have an incredibly rich tool to dislike
00:32:05.880
dig into yo Cayman spike emitter you can get a range of commits you after a certain date before a certain date show
00:32:11.640
me last 100 commits show me commits that touch this file on the command line and
00:32:16.830
it's all incredibly fast but the nice thing is that you can also do some data
00:32:23.550
exports with this and so that's how I actually got to this here and that you
00:32:28.980
can basically format an export from git log which I'll show you here where you
00:32:36.750
basically define the format that you want to use and then I do a little bit of a cleanup after the fact and then I
00:32:42.840
end up with commit lines that look like this is the pipe of the limited file and then I wrote a small rails application
00:32:51.320
to basically pull all that in and then I can throw that to a library called chart
00:32:58.260
kick which will act which actually spits out this graphic right here where you
00:33:04.380
can actually see what the commits are over time and you can also do like grouping by week by month by saying and
00:33:10.650
then depending how you import that data you can do some other nifty slicing and dicing with it
00:33:15.960
as well get itself is a very wonderful
00:33:21.870
tool I wanted to get into this for this for this presentation but I couldn't quite get to it
00:33:27.540
get is a time machine so I can go back to any point in time in these projects
00:33:33.480
and basically start over from how those projects looked at a given point in time
00:33:39.960
so if I want to go back to 2010 and see what those project looked like I could in theory spin those up and I thought
00:33:46.410
there is you can get a virtual machine using a version of Linux from back then
00:33:51.420
or a docker container with you know with the right version of Linux you get the right version Ruby installed the right
00:33:57.240
version of rails installed and then kind of set that codebase up as it would have existed at that time and kind of be able
00:34:03.090
to look at things and say oh okay I can put myself back in context for what happened back then that could be
00:34:09.210
valuable to you if you wanted like hey where did this happen why did we do it this way you can you can learn from that and then kind of the bigger piece or
00:34:19.050
that I should say as big a piece of this for me was talking with folks who had
00:34:25.679
been involved in this from the from the very beginning or over the life cycle of these applications both from from a
00:34:32.520
development standpoint and from a business standpoint they're not always
00:34:37.830
going to be available you may not have access to every participant I got good responses from most of the people I
00:34:43.470
contacted though I was very helpful and where you can talk to folks to get context for why certain businesses
00:34:49.290
business decisions were made why curtain a certain code is structured the way that it is that can all be very helpful
00:34:55.409
I do find it very helpful to to kind of approach this in a I'm curious manner
00:35:03.510
not a not an accusatory fashion so my questions were I tried to phrase my
00:35:09.450
questions with kindness like you know like hey you know can you tell me about what happened around this can you tell
00:35:15.570
me about what what it was like working on this project back when everything was
00:35:20.670
brand new and some of the feedback that I got around this was pretty interesting and
00:35:27.599
to pieces I got from one of our developers Tommy Stokes was that you know we all learn as we go and get
00:35:35.500
better with time and so don't look at code from six years
00:35:40.809
ago as an evaluation of how a developer is now and then you can also look at the
00:35:49.420
code and think that you know if this could have been implemented in a better fashion or it could have been tested better there's probably a really good
00:35:56.859
reason why it wasn't at the time and that could be because if this is requirements and deadlines it could be
00:36:02.559
because of the developers own experience it could just be general technical limitation and so some lessons that are
00:36:11.680
available with those and just think about lessons available oftentimes we
00:36:19.240
hear like lessons learned but I saw something recently where they said lessons available just because you
00:36:27.819
weren't necessarily guaranteed to learn just that that lesson was available to you so here getting to MVP was critical
00:36:37.049
because there was overwork and we needed better automation cooling and shifting
00:36:44.020
shifting gears to allow external access the application is something that was kind of a big change for the teams and
00:36:50.020
one that is still kind of rippling out and then the upgrade itself took took a
00:36:56.710
long time in that stalled innovation there's always more that we can do in
00:37:02.890
terms of refactoring business logic on particularly moving towards a single responsibility principle sure shared
00:37:10.119
migrations and models have not served as well it's a headache for all of us trying to move things intelligently
00:37:15.700
through the application that causes test breakage you know the apps are overly coupled for how they really could be but
00:37:24.040
there's a joy in writing rails versus other software development you know for
00:37:30.730
Dan Benjamin when you started the project it was preferable to writing hybrid PHP and Java solution and for one
00:37:38.140
of our other developers Aaron's ARPA working with rails was the first moment she felt she enjoyed software
00:37:43.869
development if we'd understand where we
00:37:51.220
would be now we probably would in terms of allowing external access the number of customers we would have how much
00:37:58.150
stuff would be coming in we would have looked at structuring your data and our applications that differently at the API
00:38:06.610
layer making the errors more clean and clear and descriptive having good
00:38:11.680
documentation not treating every response as a 200 ok regardless of what
00:38:18.280
happens with it is a big one for us we have to keep that in some areas because that's what the expectation is that
00:38:23.740
that's not one that we want to keep and I think one of the one of the most
00:38:30.280
important things I'm left with is expect that you know my current my presence of my prior colleagues did the best work
00:38:36.760
that they could given their knowledge and understanding and circumstances at the time and so I approach I approach
00:38:42.220
this with love and kindness to try and really put myself in the shoes that they
00:38:47.800
were in when when this happen trying to understand this contextually and understanding that everybody learns as a
00:38:53.950
project goes on best practices evolve and new perspectives are going to come in and add distinctiveness as if people
00:38:59.680
come and go on a team but rails a service does very well for lost to 12
00:39:05.680
years and will continue to do so for the for these applications and you know it's
00:39:11.560
been surprising that you everything has been as stable as it has been we are
00:39:16.810
changing the UX this is how it looked back when dan started this project back in 2005 and we are recently kind of
00:39:23.920
giving it a UX facelift and so soon it will look like this and that this caused audible gasp when this was a demoed last
00:39:32.170
week people were astonished that it was like oh wow it's changing finally and
00:39:38.560
the other thing that was interesting in it I've got just a little bit of time left so I need to wrap up but the
00:39:43.840
business took a big risk rails was not at one dot when and so they had a business critical
00:39:49.180
need and they they took a leap of faith in going with rails when it would have
00:39:56.290
been very easy to say no so it's kind of
00:40:01.600
with the mix of astonishment that it's gone on so long and it has more
00:40:07.810
potential to fulfill so I have some
00:40:14.500
thank yous to run through really quick but I got some invaluable research assistance with some interviews software
00:40:20.500
they used to build and some presentation was on Rails 5 and so on and I'm online
00:40:25.840
at base 10 and these slides will be available at Walt Corp qf / presentations probably sometime in the
00:40:32.350
next week or so and you'll you'll see stuff when the conference releases