Recently I’ve been working on a project where we have been switching over the datasource code from one code base to another.\u00a0 The codebase is pretty monstrous and has at least 30 developers checking in on it.<\/p>\n
Many things\u00a0 bothered me about the tasks in this. There was no documentation on it, at all.\u00a0 So we had to spike out over and over what this new codebase was, and how our old codebase worked.\u00a0 Also, a lot of baseline integration tests had been removed so if we did changes we could have little confidence as to what we made work corerctly, or broke.<\/p>\n
I guess when you have to do this kind of thing there’s no roadmap and its impossible to estimate == even though management presses down on your team for that information.\u00a0 The re-architecture had no architect oversight, no visibility to the business (like an invisible oil change) but was in reality a strategic move: the change would put our application on a shared code base with other applications, and possibly opening the door for more feature work more quickly because of this.\u00a0 Maybe the end-game customer wouldn’t not see anything but a better app, but the tech team’s business customers should have known about this major re-work.<\/p>\n
Most of the spiking was done by me and a cohort for a few months.\u00a0 We had object designs and impedances, dead ends, all that good stuff when you wander into the unknown.\u00a0 It was tough because there was really nothing to be accountable for, until at the end we produced a workable plan to get the job done.<\/p>\n
Remember this is a monster codebase.\u00a0 And the current data system had at least 4 different types of implementation so you couldn’t just “switch” — there was business logic buried into the way we did our datasources.\u00a0 The system was a sharding system spreading data out across multiple databases based on an encrypted key; and the key could be almost everything and that, too, was tied to rules.<\/p>\n
When I sat looking at the entire set of requirements we had gathered the solution stood out — a series of small tiny changes over all the classes over time.\u00a0 The METHOD to do the work actually was dictating the architecture we’d live with until the conversion was complete.\u00a0 We would have two data systems up, and slowly switch, class by class, over, until complete.\u00a0 After looking at what we could do, this would work the best over the whole-hog conversion my colleagues were pushing.<\/p>\n
Sounds nice and agile, right?\u00a0 It is.<\/p>\n
But I realize there is a weakness in this approach: during the conversion there is opportunity for abuse of having two db systems in.\u00a0 And, you can say “well just tell everyone and if it gets abused that’s a communication problem.”\u00a0 No, not true.\u00a0 Developers on the team have to drop in features and get them to work — so they may be forced to do one thing or another at that time to make the application work.\u00a0 It’s called “continuous integration.”\u00a0 So the weakness is, a small methodological conversion creates more tech debt over time that has to be refactored over time.<\/p>\n
This tech debt, though, is very acceptable because the small changes are easier to test and track than a one-time whole conversion.\u00a0 And if the system gets a bit abuses, when we get to those classes we’ll fix it.<\/p>\n
It’s interesting how a good methodology can save the day.<\/p>\n","protected":false},"excerpt":{"rendered":"
Recently I’ve been working on a project where we have been switching over the datasource code from one code base to another.\u00a0 The codebase is pretty monstrous and has at least 30 developers checking in on it. Many things\u00a0 bothered me about the tasks in this. There was no documentation on it, at all.\u00a0 So […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[],"_links":{"self":[{"href":"http:\/\/10kdev.net\/index.php?rest_route=\/wp\/v2\/posts\/451"}],"collection":[{"href":"http:\/\/10kdev.net\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/10kdev.net\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/10kdev.net\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"http:\/\/10kdev.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=451"}],"version-history":[{"count":2,"href":"http:\/\/10kdev.net\/index.php?rest_route=\/wp\/v2\/posts\/451\/revisions"}],"predecessor-version":[{"id":453,"href":"http:\/\/10kdev.net\/index.php?rest_route=\/wp\/v2\/posts\/451\/revisions\/453"}],"wp:attachment":[{"href":"http:\/\/10kdev.net\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=451"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/10kdev.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=451"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/10kdev.net\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=451"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}