Strangling the Legacy out of an Application
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 170 | |
| Author | ||
| License | CC Attribution - NonCommercial - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/50537 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Information technology consultingMereologyGroup actionCodeBitInheritance (object-oriented programming)Multiplication signSoftware developerNatural numberNeuroinformatikSuite (music)Total S.A.
01:23
Function (mathematics)Software maintenancePhysical systemProduct (business)Continuous functionSurface of revolutionTime evolutionNetwork topologyMedical imagingMultiplication signDependent and independent variablesCartesian coordinate systemArithmetic meanPhysical systemBoss CorporationMathematicsFunctional (mathematics)Projective planeFlow separationComputer architectureFamilySingle-precision floating-point formatData managementSoftware developerConnected spaceVisualization (computer graphics)RewritingSheaf (mathematics)Presentation of a groupMoment (mathematics)ForestWebsiteFormal languageSurface of revolutionMultitier architectureBitInteractive televisionAnalytic continuationMilitary baseTwitterGreatest elementBootstrap aggregatingGoodness of fitSpecial unitary groupWave packetRootkitParameter (computer programming)Data conversionCodeFreewareUser interfaceSoftware maintenanceReduction of orderTrailType theoryLine (geometry)Slide ruleCommutatorContext awarenessDecision theoryChainSoftwareMachine visionVideo gameComputing platformInsertion lossPoint (geometry)Right angleColor confinementFunctional (mathematics)Square numberGoogolBookmark (World Wide Web)Sign (mathematics)Group actionPattern languagePerspective (visual)EvoluteComputer iconComputer animation
10:53
Pairwise comparisonArchitectureFunctional (mathematics)Machine visionProjective planePairwise comparisonPhysical systemState of matterRewritingAddress spaceField (computer science)Multiplication signCartesian coordinate systemComputer architectureVolumenvisualisierungIterationFlow separationPeer-to-peerDivision (mathematics)Arithmetic meanCodeComputer configurationMathematicsLevel (video gaming)1 (number)Software bugCurveDemosceneSlide ruleBitCASE <Informatik>Uniform resource locatorReal numberFunctional (mathematics)Service (economics)Right angleComputer animationDiagram
19:20
Table (information)Web pageForm (programming)Time domainObject (grammar)State of matterGUI widgetGame controllerService (economics)Order (biology)Software maintenanceFunctional (mathematics)Web applicationSoftware frameworkElement (mathematics)Programming languageSequenceLink (knot theory)CodeCartesian coordinate systemUser interfaceLogicPhysical systemAxiom of choiceLine (geometry)Right angleProcedural programmingWeightData storage deviceComputer architectureMathematicsDatabaseNeuroinformatikTable (information)User interfaceDomain nameNumberModal logicWeb pagePattern languageInternetworkingInternet forumProduct (business)Revision controlWeb serviceData transmissionUniform resource locatorImage resolutionMatching (graph theory)Game theoryCASE <Informatik>Web 2.0Network topologyGraph coloringUtility softwareWebsiteObject (grammar)Multiplication signAsynchronous Transfer ModeOperator (mathematics)Category of beingForcing (mathematics)Form (programming)Data managementSign (mathematics)Decision theoryBitAuthorizationModule (mathematics)Water vaporStatement (computer science)Client (computing)Thermodynamisches SystemProjective planeSolvable groupSQL ServerFacebookHacker (term)INTEGRALAuthenticationLoginEntire functionServer (computing)Endliche ModelltheorieBusiness objectReal numberState of matterSocial classGame controllerComputer animation
26:19
Form (programming)Web pageTime domainObject (grammar)State of matterService (economics)Game controllerGUI widgetArchitectureTable (information)View (database)Web serviceDatabaseLibrary (computing)CASE <Informatik>MereologySoftware frameworkUser interfaceLogicCodeWeb 2.0CompilerScripting languageFlow separationEndliche ModelltheorieValidity (statistics)Rule of inferenceMultiplication signSoftware maintenanceMathematicsReduction of orderModule (mathematics)View (database)Data managementINTEGRALFunctional (mathematics)Projective planeMachine visionAuthorizationAuthenticationCore dumpWeb applicationSource codeQuery languageServer (computing)Profil (magazine)Coma BerenicesSoftware developerUser interfaceConnectivity (graph theory)Utility softwareDomain nameObject (grammar)Computer architectureWeightGame controllerWeb pageMeasurementCode refactoringNetwork topologyStandard deviationProduct (business)Mathematical analysisForm (programming)Shape (magazine)Shift operatorAsynchronous Transfer ModeSoftware testingCartesian coordinate systemVisualization (computer graphics)Compilation albumOrder (biology)Letterpress printingGroup actionCellular automatonSystem callMachine codeGraph coloringSequelLine (geometry)Right angleBlock (periodic table)Client (computing)1 (number)Program flowchart
33:17
Table (information)DivisorComputer architectureComa BerenicesCartesian coordinate systemSystem callVisualization (computer graphics)WeightLine (geometry)DatabaseBitRight angleComputer architectureNumbering schemeVolume (thermodynamics)Bridging (networking)Data structureDivisorTable (information)1 (number)CodeGreen's functionContinuum hypothesisElectronic mailing listFocus (optics)MereologySampling (statistics)Code refactoringProgram flowchartComputer animationDiagram
35:59
Table (information)Game controllerDivisorBuildingView (database)Menu (computing)Electric currentData storage deviceObject (grammar)Form (programming)PlanningComputer architectureElectric generatorPoint (geometry)Functional (mathematics)Menu (computing)CASE <Informatik>Cartesian coordinate systemComputer architectureAuthorizationEntire functionProcess (computing)Goodness of fitMathematicsAuthenticationComputer configurationAreaInformation technology consultingForm (programming)BitState of matterPhysical systemWeb 2.0WeightComplete metric spaceWeb pageStandard deviationMereologyBridging (networking)Customer relationship managementDecision theoryHuman migrationCodeMachine codeOcean currentSampling (statistics)Software frameworkFlow separationTheoryObject (grammar)Web applicationConstructor (object-oriented programming)Metropolitan area networkUniform resource locatorLoginComputer animationMeeting/Interview
43:05
Function (mathematics)Term (mathematics)Natural numberCartesian coordinate systemCodeAreaSign (mathematics)Interactive televisionGreen's functionTerm (mathematics)Exterior algebraFunctional (mathematics)CASE <Informatik>Level (video gaming)BitRight angleForm (programming)Menu (computing)Field (computer science)MereologyProjective planeOnline helpMultiplication signMachine visionComplete metric spaceCodeBuildingArithmetic meanPhysical systemComputer fileWeb pagePlanningHorizonLattice (order)Computer fontSpacetimeUser interfaceDifferent (Kate Ryan album)Uniform resource locatorProper mapBit rateComputer programmingExpected valueData managementEntire functionMomentumApplication service providerAnalytic continuationRewritingStack (abstract data type)DivisorFront and back endsSoftware maintenanceComputer animation
50:11
Service (economics)View (database)Endliche ModelltheorieArchitectureWeb pageTime domainObject (grammar)Form (programming)State of matterGUI widgetGame controllerTable (information)CodeApplication service providerSoftware developerOrder (biology)DataflowPhysical systemCore dumpState of matterMereologyRule of inferenceSoftware testingNumberFunctional (mathematics)Computer architectureWeb 2.0Goodness of fitFront and back endsThermodynamisches SystemExecution unitForm (programming)Code refactoringWeb pageMultiplication signAuthorizationPosition operatorMathematicsQuery languageCartesian coordinate systemUser interfaceProjective planeVariable (mathematics)Test-driven developmentUnit testingNeuroinformatikSoftware maintenanceDifferent (Kate Ryan album)Set (mathematics)Complex (psychology)LogicNetwork topologyBridging (networking)Single-precision floating-point formatCASE <Informatik>WeightBit rateOffice suiteBlogLevel (video gaming)DivisorInternet forumFacebookComputer animationProgram flowchart
57:48
Rule of inferenceBoss CorporationBit rate
Transcript: English(auto-generated)
00:03
So, welcome. I thought, sometimes I think that I'm the only one working with legacy applications, but apparently not. I'm happy you're here. I thought I'd start with some, you know, this is nature. Fresh air, sun, have you heard of it? Okay, well, this is Norway, so it's rain all the time, isn't it?
00:24
I remember my parents bringing me to vacations in Norway when I was a kid, and I said, never more. It was rain, it was cold. Next year, we went to Greece instead. So, I'm Anders Schabel. I'm a developer and working as a consultant at a company called Kantor in Stockholm,
00:43
part of the telecomputing group. And I've been coding since I was nine, and I've written quite a bit of code that was bad code, and I hope I've written some good code. I'd say that throughout the talk, if you have any questions, just raise your hand.
01:05
We'll take them as they come, and I'll also save some time at the end for questions and discussions, because I think I've got about 1% of the experience of legacy code in this room. 99% is you. So, at the end, I'm happy to have a bit of a discussion.
01:23
But first, looking back, were you all at the keynote? Then Luc talked about the future, or rather, the time that already is here, but a lot of companies are struggling to understand that time. But do you remember this? This is Visual Basic 6.
01:43
Forbes Designer, Code, and this picture, it ends in 98 and going forward. I remember this was actually the first conference I went to. It was a presentation from Microsoft of the new distributed intranetwork architecture,
02:02
where we moved from one tier to two tier to end tier, and it would be so much better. At that time, I believed in it. I'm a bit more seasoned now, and I think that the next big thing, it will be the latest and greatest until the next big things come. But back then, I really believed in it. Anyone here that has been working in this kind of context?
02:25
Ah, do you like it? Just laughs. Well, we'll make a slight detour first and talk about gardening, actually. In our garden at home, we have not that nice old pine tree.
02:44
It works. It provides the functionality it's supposed to. It provides shade. But the architecture of this application, sorry, tree. I don't like pine trees. I'm thinking of beautiful big oak instead. So I go have a chat with the garden government or boss.
03:02
That is my wife. And I say that I think that wouldn't it be better with a large oak here instead of this pine tree? And she says, yes, it would. And you know what? I take that for a yes. So I go ahead. I bring my chainsaw. No more pine tree.
03:21
I bring this small oak tree instead I get. And I plant it and I'm happy. It has this new nice architecture. It's an oak tree. While it might not be as big as the pine tree, but eventually it will. I imagine just in 20 years, this will be a magnificent tree.
03:44
And imagine in 100 years when my kids are really old, sitting there watching their grandkids play under this magnificent oak. It will be great. So of course I'm happy. I'm proud. I go get my wife.
04:02
She's not happy. Actually I showed this line to my wife. And she said, hey, you can't show that to the devs. They all think I'm stupid. I wouldn't let you bring the chainsaw in the first place. Actually after I showed this line, I can't find my chainsaw anymore. It's just disappeared.
04:22
Well, you're laughing. But I think that this is what we often do as engineers. We have this old application that provides a functionality. It's ugly. It's a pine tree. And we walk to the boss and say, we should rebuild this. Look, we can have this beautiful oak.
04:41
But then somewhere along the way, we prioritize the architecture and the technology and we lose track of the functionality. You won't get much shade out of this. Actually, I prepared these slides a couple of weeks ago. But then when I was planning my trip here, I checked the timetable for the commuter trains in Stockholm
05:02
to get to the airport. And it had this brand new site. Twitter bootstrap based. Nice, clean design. But the favorite functionality, the one that I use the site most for to find when there are shutdowns of traffic, I can't find it anymore.
05:22
That functionality was somehow lost. So, what I'm going to talk about today is how to transfer the pine tree to the oak without having to go through the chainsaw moment. But first, I would like to look a bit
05:41
about the business perspective. How many here are developers? Okay, anyone who is a boss or manager or responsible for a budget? Okay, good. So, when we have an idea, we of course know that we should replace
06:01
this crappy old architecture and code. But to do that, we need funding. At least I'm not working for free. I prefer if someone pays my salary, which means someone needs to provide funding. The business drivers for doing anything is either new functionality
06:22
or that the current maintenance of the application is too expensive. That's roughly the only two things that you will ever be able to use as an argument against your boss to get funding for anything. So, while it comes to an end, they often try to postpone this as long as possible,
06:42
but in the end, they have to fund a rewrite of the system. And, well, what do they do once they've decided that a rewrite is needed? They put a no-change policy on the legacy system. And that can last for a long time. I mean, it can last for several years
07:03
if it's a large project. And then, at the end, you have a big bang release where every single change feature that you bring into the rewriting system is an increased risk. This one remedy that is often used in rewrite projects to handle this risk and reduce risk
07:21
is to make it one-to-one rewrite. Well, imagine for a moment that you are actually managers. I know you're devs, but imagine you're managers. And I'm a developer. I'm the sole developer here. I'm trying to sell this rewrite to you. And you know what? If you fund this rewrite, you'll get no new functionality.
07:40
And it's a one-to-one rewrite to reduce risk. So when we are done, you will have the same sheet to use the interface and the same sheet to functionality. Okay, anyone want to fund my rewrite? Ah. But I know some of you are thinking now that, well, at least it's better code because you're developers. So you're thinking, it's better code. So while there is some gains by rewriting anyways,
08:05
but let me tell you, this is a one-to-one conversion. So when we're done with the rewrite, we will have the same sheet architecture. And then we can start working with a new platform, new language to improve.
08:22
Well, this is not a very good way, I think, to do a rewrite. Let's look at a popular methodology for, or movement for development. Agile. That's really mainstream nowadays. What does Agile learn just?
08:41
Well, what we can learn is that we should reduce risk by using agreements. We shouldn't have a big bang release. And that goes to the same for rewrites or changing applications. We should have early and continuous user interaction. And any software development effort should be an evolution, not a revolution.
09:01
So that brings us into the topic of today, strangling. So if your boss is unwilling to fund and bring out the money needed for that complete huge rewrite, you can use a very effective means called strangling.
09:22
Oops, sorry, wrong. I wasn't supposed to show that one. My boss said I wasn't allowed. Well, let's move on to the other strangling. This is a plant. There's a lot of trees in this presentation. When I was looking for images for this presentation, there's so many beautiful images of strangler vines out there.
09:43
Just type it in on Google and try. This is a strangler vine. It's an old tree here, and then this one is using the old tree to grow. It seats itself in the crown of the old tree, and then it roots down to the bottom while still being high up in the air
10:01
and having access to the sun. The patent strangler application was named by Marty Fowler after he had visited a forest with strangler vines. So what we do with an application when strangling it is that we start building a new separate application besides the old one,
10:21
a new separate one with a new architecture just like this trike, its own trike. It has some connections to the old application here, but it's a known trike. We add more and more functionality, more and more trikes. They start to grow together, and eventually we have got rid of the old application,
10:45
the old legacy code. I think this picture is just beautiful. This was more of a business section of the talk, so let's look at cost-value comparison because when you show this to managers,
11:01
there's always this question about cost and value. We'll try to go through it quite quickly. First, to the left, we have a complete rewrite with a big bang release, which means that we are investing. The blue field here is the cost, the money spent.
11:21
The orange field is the value gained from the effort. We start rewriting. We were spending a lot of time rewriting until the cutover date here, and we are accumulating cost. We are not only accumulating cost. We're actually getting negative value
11:40
because once we have started with the rewrite, there is this no-change policy in place, which means that there will be new business needs that we can't address because there's a no-change policy. After a few months, there's something that happens. The business would like the old application,
12:01
which they are still actively using. They would like it to be changed, and we are not allowed to do it. So now it's a negative value because they won't get the support that they need to the business. It happens again, and we have negative cost. Or, in some cases, that's severe
12:23
that you need to lift the no-change policy and say, okay, we can change it. And then it gets worse because the rewrite team is effectively chasing the old application. What you are to replace becomes a moving target,
12:41
and you will have double cost. You will both have to implement the new functionality in the old legacy system that is hard to work with due to the legacy state of the code, and you will have to implement it in the new system. Then, after 12 months, we have the big bang switchover.
13:00
Do we provide value at the switchover date? Is it a positive value? If you rewrite this application as a big bang release, would anyone here think you could write it and have no bugs? No! Can I hire you?
13:22
No, we will have bugs, of course. And it means we will have even more negative value. So we fixed those bugs, and after 13 months of work, we're back where we started value-wise. We have not produced any value but not incurred any loss.
13:42
But we spent quite a lot of money. That's fun. Also, all these not realized value, money being spent but not having produced any value yet. That's risk to the business. If we decide that we have to halt the project temporarily or for good,
14:02
but it might be a funding issue, well, we need to work on something else for a while, so let's just halt the project right now and we'll commence in six months. Well, then you have all this money spent with no value delivered. If we instead go for the strangling option,
14:23
we will do some initial behind-the-scenes work in a month or so, then we will start delivering new functionality, re-written functionality. And since we are doing a rewrite, gradually releasing it, there's no reason to just do one-to-one rewrite.
14:42
We can actually work closely with the business and make sure that the functionality we deliver is up-to-date with the business needs as they are right now. A rewrite with strangling takes substantially longer time. Sorry, wrong button.
15:01
It takes a bit, maybe about 18 months before we are entirely through it. But look at the cost and value curves. Apart from this startup phase here, we're delivering value all the time. And then when we are done,
15:21
we can continue to deliver value but spend less money per month. No, I don't think so, because the question was if strangling wouldn't be the same graph
15:41
as one-to-the-left, although smaller iterations. And I don't think so, because here we are first doing a one-to-one lift of the old architecture, because we are afraid to change anything to reduce risk. But here, if we replace a certain functionality in the system, there is no need to just make a one-to-one replacement.
16:03
You can ask the business, how should this functionality look like?
16:23
The comment was that you need to can't replace just a single functionality, but you need to replace often a larger mess. I'll get back to that when we talk about architecture in a while, how to do that, because that's one of the challenges with the strangling applications. But to summarize this slide,
16:43
then with strangling, we have some behind-the-scenes work initially, but then we start to deliver value. And if we compare the two options, we deliver value a lot earlier, and time is money for business. The return on investment quote
17:02
is all usually used by those counting money in the company, and it means, how fast do I get value for the money spent? And actually, the cost is somewhat lower here than here in the end, because once we've rewritten the entire application,
17:21
we have to make quite a huge effort to boost the functionality and get that new functionality into the system. And we definitely reduce risk, which is important. So anyone keen on continuing the business talk,
17:41
or should we move over to tech stuff and architecture? Architecture. Well, when we are doing strangling, we can start out nice with a new trunk, and then everyone on the team works with a new technology,
18:01
some Angular here, JS, some Ember JS, some Knockout JS, some server-side render days, we did not ever see, and this is our new application, which is not better. So we need to make sure
18:20
that we're not ending up in this situation.
19:04
Anyone recognize it? It's not Alexander Rybak. It's Queen, a song called One Vision. You need a vision of where you are going, and you need to make sure that you share that vision with the entire team.
19:21
We need to know that we have this old application, and everyone must make coordinated efforts moving functionality over to the new architecture. And that's easy to say, but how do you do it? What do you do when you get this mess of 300,000 lines of messy legacy code that's 10 years old?
19:41
I did that. It was two years ago I first saw this application and dug into it. This is what I saw. And the first step I did was classifying, but this is the example of an application we'll talk about today. So let's go through the various things. This is a web application. How many here are working on web applications?
20:04
How many are working on other kinds of applications, such as rich clients? The example here will be web, but I'll talk a bit at the end of the architecture here about visual business 6 example as well.
20:22
So let's look at this architecture. It was written 10 years ago, this application, in .NET 1.0 release candidate something. It was created. And I think that was a good decision because when the application was first written, they knew that .NET was coming.
20:41
They had the choice. Stick with the DNA architecture visual basic 6 or use the new .NET architecture. I'm very grateful that they did indeed choose to use the... Well, they did not choose to use VB6. They used .NET, which meant that we didn't have to change programming languages.
21:02
But still, it's an architecture that was written in .NET 1.0, no entity framework, no link to SQL, no membership providers, and an architecture heavily influenced by the DNA way of thinking.
21:21
And also I think it was written by people reading the book on architecture and solvable applications having it open beside the computer because it's a splendid example of an anemic domain model. An anemic domain model is an anti-pattern. Anemic, it's a disease where something's wrong with your blood,
21:43
so you're just pale and becomes a vampire or something. And an anemic domain model, it is something that at first sight looks like a real domain model with classes and objects representing the business domain.
22:01
But when you look closer at it, there's nothing there. They are just data transfer objects. Public properties with setters and getters. You can read and write to all the properties and no methods. The behavior is somewhere else. So looking at this application,
22:21
we had a web project, a website, which contains a number of modules, an authentication and authorization manager, a navigation manager, a state manager, a session manager. As soon as I hear a class named managers, there's some ugly feeling within me.
22:45
Usually it's a sign there's something fishy in there. Then we had a lot of web forms pages which used web form controls. I'll get back to the colors soon. They used some shared web utilities and we had a business logic layer
23:01
with a facade and the so-called domain objects. That's called a DB controller. You store procedures for database access. We also had a web service using the business logic layer because this is a kind of ordering system and most people are using the web interface but there are some big partners
23:21
using direct integrations with their order systems. So what do you think the business logic functionality actually resided? I think the store procedures or the manager thing, that's a good guess.
23:42
Some of it is in the store procedures, in the code for the web form pages. That's right, code behind. Thousands of lines of code behind with all the business logic, copy-pasted. So what I did when I first got this pile of stinking rotten code,
24:01
don't tell my colleagues that I've been maintaining this, that I named the code rotten and stinking, but that's my impression of it, was to try to classify it. And that's the colors. The first thing I did was to identify dead code, the red things here, store procedures that when...
24:21
I brought the database into SQL server data tools. They had been hand hacking in the production database when they were upgrading. So I brought it under source control through bringing it into SQL server data tools and I found a number of procedures that didn't compile because the procedures didn't match the table definitions
24:41
or the tables were even gone. Those were obviously not used. Delete. I found a number of web form pages where the name of the page was underscore old. Well, I did a quick search, searching the entire code base to make sure no one actually referenced it,
25:01
but no. And if I have a web page with a name that is not to be found anywhere in the code base, it can't possibly be used. If you want to be on the safe side, search the web server logs as well, but then delete it. So all code that could be just deleted at first sight is saving a lot of time in the next step.
25:25
Then I looked through it and found that there are some things in this architecture that are really important and I need the functionality within my new architecture but I simply just can't let it be as it is.
25:50
That's a good question. Why did we start this operation? Maintenance costs was the trigger in this particular case. Maintenance costs and prohibitively expensive when we wanted to do new things.
26:03
And also, legacy user interface. Web forms are not that nice to work with when the people in the business were used to Facebook and other rich internet applications.
26:21
So that's the driver in this case. So what we did, we had some dead parts that were just removed and then we moved on to the, what I call it, yellow here. The database tables, the web source and the authentication authorization manager.
26:41
Those were appointed as candidate for rebuild. We should take the functionality they have and fix them. So that's the rewrite but constrained to certain modules. Then we had some parts of the code were actually quite good.
27:03
They didn't have that legacy smell all over them. The black one, the web utilities. Actually, I moved some things out to a separate project called web utilities with code that I found. Well, it's decent enough. We can just put it in ordinary maintenance mode
27:21
which means that there are some refactoring needs but they can be addressed when someone needs to work with the code. The external interface, the API is fine. To be honest, no testing because I love TDD.
27:41
I prefer working test-driven when I can but in this case, the code was in such a bad shape that it wasn't even possible to write tests against it. It would require very substantial refactoring. So, I'm coming back briefly to where we could test.
28:05
I'll just mention the blue things. Those are frozen. Those are mainly the trunk of the old tree. It's there, it supports the business, it's rotten on the inside, the code is a mess but the business are actually right now quite happy
28:21
with the functionality it provides and I'm quite happy because there's no change request so I don't need to look at the code. So, I just decided this is frozen. It can be as it is for now but as soon as someone wants to make a change to the functionality, we should rewrite it
28:41
but for now, it can just be frozen and that's a risk reduction. But then, well, the other thing we've been waiting for, the new code. We add the new architecture besides the old one and here it gets interesting. We put some MVC views into the web project.
29:05
The MVC views need to be in the actual website. We created a new separate web project or a class library called WebNew where we put the MVC controllers and MVC view models. The reason to put this in a separate class library
29:22
was to make a very clear distinction to all developers what is legacy code and what is brand new shiny code. In this project, when a zero compiler warning policy, we enabled code analysis with a zero warning policy.
29:41
Here, you can write tests, make sure the code is testable. Well, whatever quality standards you use and want to use for new code, use it in the new project. And then, when working in the old project, well, the views are part of the new project. They should live up to the new standards as well.
30:01
But when working and you have to do interfacing to this old stuff, well, do it so that it works for now. But this was a really important thing to make the shift in mind for the team that we are in the new code with new rules and new quality measurements and here we have the old code.
30:22
We are leaving that behind us. We moved the business logic into a domain model and this time it was a real domain model. I mean, there are methods on the entity objects that actually do things and validate business rules. We brought in entity framework and could get rid of some 100,000 lines
30:43
of handwritten and partially generated code. There's some SQL script generating C sharp code in this application from the database schema. We could get rid of that using entity framework as a standard product to just get the database access working
31:00
and it became way faster because the old handwritten thing did... I did a search once and brought up SQL Server Profiler to see how many SQL queries were actually executed against the database to do a simple search. At 5,000 queries, I started to think,
31:23
well, this is a lot. At 17,000, I went to grab some coffee while it was running. At 37,000, it was complete. My coffee mug was empty by then.
31:42
We also moved all the web service that should be rewritten and moved it to use the new core library which meant that it actually used the same business logic rules as the web interface. So in the end, the vision is to get here.
32:05
Actually, we had some issues with integrating partners because previously, the web service was basically raw access into the database bypassing all business validation. When we put this into production,
32:23
the integration partners had issues because they were used to bypass some business rules and now we enforce them. Let's talk briefly also leaving this web example... I mean, web applications are a dream to strangle
32:41
because it's basically... each page is very independent from each other. If you have Visual Basic 6 client, for example, it's much harder, but it's still doable. One thing you can do is to... if you have a form, you want to change some functionality in that form.
33:01
You can write that as a .NET component and wrap it in a com interface and then you can use that com interface from the Visual Basic 6 code. Eventually, when you've changed enough of the controls and components of the form into being proper .NET components,
33:21
you can switch it around. You can make the entire application a .NET native application, but call and certainly isolated Visual Basic 6 components through com. Depending on what kind of application you have, you have to work with how to find those ways to interconnect the applications.
33:46
Let's continue. I said at the previous peak issue that a lot of code was frozen. That was not entirely true. When we start an application, it starts out nice in a straight line.
34:00
Everyone is working the same. Then someone has an idea. I think my way of doing this is way better than your way. You're wrong. And then you have another idea, but it was not that good idea, so it won't be used at all, so it's just a dead end. And then you're over there. You have your own idea,
34:21
but what you were doing, I don't really know, but it screwed up. This is what an architecture usually looks like when you get into it. And this is very hard to strangle. At first start, it is a good idea to do some careful refactoring, trying to find out
34:40
what was the original intent of the architecture and bring the application back in line with the original intent. So we once again have just one way of doing... Well, I should use that one. One way of doing things. Then, when we are starting working,
35:01
we should prioritize what should we do first, which one important thing is to identify impediments in the old architecture. We are here exploring the code, the wildness of the old code. In the application I showed you, I wanted to do some refactoring to the database schema, so I was out there looking
35:20
for how the database schema was handled. And finally, I found it and it was deep frozen. The architecture, so much of the code was hardwired to the structure of the database. So that became the first focus of anything. It was to migrate parts of the code
35:43
that locked down certain database tables that I wanted to change. Because I definitely didn't want to change any database tables where I still had the old database access code using it.
36:01
One method that needs to be used is to build bridges, or what I call bridges. If we turn the sample architecture around a bit, we have the old stack to the right, the blue ones, and the new stack to the left, the gray and green. And we need to make sure that these two...
36:21
These are really separate applications built under one roof. And we need to make sure that they can coexist. We need to bridge them somewhere. In this case, for a web application, it's the layout master, making sure that we have the same layout for the entire system to the users.
36:42
And also menus navigation, we need to seamlessly be able to navigate users from an old page to a new page and back. They shouldn't notice too much whether it's rewritten or not. Then it's also sometimes important to refactor to isolate behavior.
37:03
For example, menu generation is sometimes, like in the application I worked with, copy-pasted. There were 137 web form pages, and all had their own copy of the menu generation, and all have their own copy of authentication and authorization.
37:23
And all were depending on the current user objects stored in the session. And Wayne checks. So what we did there was to do a quick search in the entire code base and find all those cases and replacing them with a facade, current users.
37:41
So we had one entry point to that dependency, which meant we could rewrite the authentication and authorization while providing a backwards compatible API to the old code, but still using new standard ways of doing it in the new code.
38:01
So bridges are good. They can be made lean. The other thing you can do is pillars, where you can move, not move the migrate functionality all the way through the application,
38:20
but rather you do it asymmetrically. So maybe you plug in the entity framework working under a facade and keep the facade. This is a bad way. I've tried it. Don't repeat my mistake. The reason is bad that when I come to the next step and I want to change the facade
38:42
and keep the web forms, I need to rebuild the pillars. I need to build them again. For every layer that you step up, you need to build new pillars in the migration. And the pillars are substantially harder to build than the bridges. The bridge is a lean construction,
39:01
just gluing together, supporting these two. The pillars need to bear the weight of the entire application ahead, atop of it, and to support all the different data, all the different functionality. So don't do this. I'll get back to another example application
39:23
where one of the reasons that strangling failed was this. But before, I would like to talk a bit about the future. This is Martin Fowler. I thought I'd show you a picture of him because I got a lot of inspiration from his writing on this.
39:41
And he usually presents himself as a general loudmouth, but I think he's a great thinker. And it's this, that 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. The code we are writing today,
40:01
or maybe not today, but the code we wrote last week and the code we will write next week, is the legacy code of the next years to come. I'm not there yet. I think I'll change jobs before the new things I write now need to be strangled. But if you can provide hooks
40:21
or think of how should we strangle this, it's good. But I think also that if you have a really good architecture, layered architecture with separation of concerns properly, then it is easy to strangle in the future.
40:42
That's it about theoretical architecture. I would like to go into a bit about my experiences doing this. But first, anyone has any questions on more theoretical architecture? Okay, let's move on. What about reality?
41:03
The first system I worked on a few years ago, we came this far. And we had some pillars in the architecture. They are now in the face of studying a new standard CRM system instead.
41:20
So this is the fate of that system. The reasons, I think, is that they didn't have the funding needed to go through. Although it's less expensive to do strangling than to do a complete rewrite, it's still expensive. And what we did, in this case,
41:42
was to sell to the customer that, well, we can do this new functionality with this new technology, which means it will be delivered faster and it will be better, and it will have better performance than the old things. Then we said that, well, you have performance issues in part of the application. Those parts, we can migrate those
42:02
to new data access and get it working better. But we didn't really tell the whole story to the customer that to gain full advantage of this is a strategic decision that you are to work with this application, you are to maintain it for at least five more years, you are to spend the money needed
42:23
to get all migrated. We didn't do that, because, actually, I'm a consultant. We knew that that customer didn't really have that funding. So, in hindsight, we should probably have been more honest to the customer, which could have meant
42:41
that we had chosen another option from the start. The other one is better off. This is the current state of it. One functionality area has been rebuilt, and when we did that, we could, thanks to the new architecture, we could deliver new functionality
43:01
much faster and much better and improved user experience. It was a bit slow start with the team to get up to speed on ASP.NET MVC that they hadn't been working with before, but then we gained momentum. And also, when we...
43:22
That was a completely new area that we built first. Then, we rebuilt one area with a much improved functionality. This application is 10 years old, and the business driver in this case is that the entire application needs to be reworked. The business has changed so substantially
43:41
in those 10 years that the application is no longer supporting the business properly. They want rebuilt, and thanks to the straining methodology, we can work closely together with the business, get everyone involved,
44:00
and make sure that the new functionality or the things that we have rewritten are actually providing new functionality in the way that they need for working right now. So, we are currently discussing long-term. We have shown them
44:21
that this is the way to go. We have delivered value. They are trusting us now that we can do this. So, now it's the right time to discuss the long-term aspects and how to get through it with everything. Very early on in the project, I asked the customer, if we do this, what is the maintenance horizon
44:41
that we will have for this project? And they said five. Is it okay to say five years? I asked. And they said five years, yes. This system, we have decided that this system will be living for at least five more years, probably ten. But at least five. Which means that every time I have to motivate that we should do anything,
45:01
I can say that if it repays in five years, it's fine to do it. And in five years, you can get nearly everything to be repaid. And then, it's important that this turned into a joint effort with the business and tech rewrite or revamp of the system.
45:21
It's not just a tech project where we are sitting in a basement coding. So this is, actually, it shouldn't be rocket science nowadays with the Agile principles. We're getting everyone involved. We have continuous user interactions. We are delivering,
45:40
not continuous delivery, but we are delivering every month at least with new functionality replacing some parts of the system. Getting actual uses on the new system. But then, there are some challenges, of course.
46:00
If this is your application, and this was my application, this won't help. It's still just a pig, even if you put lipstick on it. So it's important to make sure that it really rewrites all the way through the stack. When you're pressed of time, it's easy to just make a fancy
46:20
Ajax Twitter bootstrap-based user interface, and it's still the same shitty backend. That's not a rewrite. And if you do that, you've lost the opportunity to communicate with the users and the customers of the rewrite, because if the user interface is shitty, the customers and users understand the need for rewrite.
46:43
If the user interface is shiny and nice, it's much harder to sell the need for rewrite. But actually, in the project I'm talking about, we kept the styling of old pages to make sure that it was very visible to the users that there was a difference. That's part of expectation management.
47:01
So we didn't want to come into a situation where we had users coming to a page that looks new, but had the same old bad backend with bad performance. So now the users can see right away, oh, this looks like my old forms. Well, the menu and other stuff around is revamped, but the actual forms looks old,
47:23
and it works like the old forms. It's a lot of reloading, it's slow, it's painful. And then you get to the new, fresh parts, and it's fast and works nicely. Actually, in that, we had a meeting where we talked about making up,
47:41
not the pig, but actually the corpse. So we said, we'll make up the corpse of the old system just to make sure that it looks a bit better with a bit larger font in some things that were important for readability, but it still looks like a corpse. It should be looking at the old system.
48:02
Then another success factor is long-term planning. Agile doesn't mean unplanned or short-sighted. Agile means that you can change your mind when you learn as you go, but you should still have roadmap, a vision, where are you going. That's important.
48:20
And then the thing that faulted in the first project I mentioned, funding. It's still expensive, but it's less expensive than a complete Big Bang rewrite, and it's less expensive than all other alternatives I know about.
48:42
And if you just go partly through it and then have to halt the rewrite temporarily, you have gained a lot of value so far, and you have delivered that value and can use that value that you've gained so far. And then on a personal level,
49:01
I like challenges. Do you like challenges when coding? Is this challenging? It's flat? It's green? Yeah, but okay, assume that you did.
49:22
Assume that it took a lot of effort to get here. That's right, but assume that, well, you're from Norway. You don't know what a natural flatland looks like, do you? In Sweden we do have some flat areas, but it naturally looks like this.
49:41
There's no effort to get there, and there's really no effort to build anything on top of that. You could surely mess up anyways, but it's not that much of a challenge. Working with legacy code is much more of a challenge. I find it so much more challenging myself. People are often striving to get two greenfield projects.
50:03
I've done that too, that was interesting, but not as challenging. So, that's about my experiences, and we have some minutes left. Actually, we've got close to ten minutes left, I think.
50:21
So, questions, comments, or personal war stories? Or anyone think I'm wrong on something? That's most fun, because then we can discuss.
50:41
Why should you fund my project when he knows that when I'm done, I will just start over with a new one? Because it will take a few years to get through, but then you will have a few years of maintenance. I won't start over right away.
51:03
I think it's easy to get into that position as a developer. I mean, we migrated this project to ASP.NET MVC, and we're just partly through it, but still, Angular looks great. We should use a Web API backend and rewrite the application in Angular,
51:23
and that's when we've just migrated 30% of the functionality. Don't do that. Actually, it's an important challenge, I think, to make sure that you only have two different sets of architecture at the same time. It's so easy.
51:41
We have the old web form-based architecture. We have the ASP.NET MVC architecture, and then we could start with the single-page application architecture. Then we have three different architectures to build bridges between. That's stupid. We should make a coordinated effort to move to a new one, and then we should make sure that the architecture we've chosen
52:02
is stable enough so that we can just maintain it for three to five years. There was someone else. Yeah. Yes. Yes, the question was about testering development
52:45
and that Marty Fowler and other authorities in our business claim that you should do tests before refactoring. If we were to do tests in this case,
53:02
I think it should be on the behavior level, behavior tests, because the unit tests, which is often used in testering development, would unit test these parts of the code and test the way that code is structured, and we don't want to keep that at all.
53:24
We say that, well, it's been working for ten years. It lacks tests. It lacks a lot of readability of everything, but it's been working. Don't fix what ain't broken. And since we are rewriting the code also with new functionality, we're actually starting all over. We are going to the users and asking,
53:42
what is the functionality you really want? Not what the system does today. So in that case, if we do test-driven development, and that's a good idea to do, then you should use behavior-driven development and test-driven development on the new business logic
54:01
and the new functionality. And also in this case, I mean, you are here at a conference. You are the visible matter of the development community. We have some 99% dark matter in the development community that never put their foot here, never read a blog, never do anything besides going to the office at eight,
54:22
doing the work in the same way they always have done, get for lunch, continue working the same way, and at five o'clock they go home. And while they might look at a computer for checking Facebook, but no code in the spare time. And when you do such a huge change to a team,
54:45
as this is, moving from web forms, I had people here that had been working in this very system for four or five years, and before that they had been working in other web form systems with the same architecture for maybe,
55:02
well, they've been working with this for ten years since it was introduced. Getting them to even start working with MVC, it's a shock to them. And I, in this case, I chose to focus on getting them up to speed on MVC,
55:22
and for quality, code quality, we use code reviews. Everything was code reviewed by opted out of tests, mostly. We put some tests on core business rules in the entity layer, because there were some complex business rules that were hard to test from the user interface.
55:41
And then also for testing, I prefer Selenium, and using end-to-end tests that are web driven. I think you get a better return on investment there. We have time for one or two more questions.
56:03
No one. If we run the old and new architecture in parallel.
56:22
Yes, we did, and we do. This is a phase that we're still going through, and we have functionality, parts of the system using, built in the old fashioned way, and parts of the system in the new way. This system has a certain number of user interface flows that you go through,
56:41
where there's an order flow for a certain thing. And the order flow for one kind of goods is, well, say wheelchair. We are changing the wheelchair ordering flow in one step, and replacing that. And then we go on to the hearing aid ordering flow.
57:03
But when we deliver the wheelchair ordering flow, the hearing aid ordering flow is still the same. And still using those. And sometimes we are changing core pages of the application that is an entry to another flow. So you start in something that is rewritten,
57:23
and then when the flows diverge, you're diverted to an old flow. It's just to make sure that you understand what state and what session variables and whatever, queries doing parameters, whatever that page expects to be present, and then just make sure that they are present and hand them over to the old flow.
57:45
So that's it for this time. Thank you very much for coming. I would like to remind you just briefly about the rating when you're leaving, and it's the green one you should pick. Nothing else. And also, I'm doing another talk on Friday,
58:02
the last session of the conference on using the Scrum rules against your boss. How to get some peace to work. You're welcome back then. Thank you very much.