Slaying The Legacy Dragon: Practical Lessons in Replacing Old Software

1,770
-1

Published on

Everyone hates the legacy application and wants to replace it. You're tired of the brittle, untested code, the outdated frameworks, the platform nobody cares about anymore. You want to apply current practices and the productivity gains of today's tools. Usually this is just a frustrated dream, but every once in a while, you actually get to do it. That's great news, but it raises a question: how do you do that?

In this presentation, we'll examine the issues encountered by a business undertaking the enormous effort of replacing a key legacy application with a new technology stack. We'll explore the technology, business, and people problems that can result, looking at specific technology solutions for a slow and careful migration of business-critical functionality off of one system and on to another of a very different kind.

Published in: Technology, Business
2 Comments
2 Likes
Statistics
Notes
No Downloads
Views
Total Views
1,770
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
2
Likes
2
Embeds 0
No embeds

No notes for slide
  • Test of speaking notes. If screens are set up properly, you should see this.
  • This talk is addressed to architects, but all developers, PMs, and business people can benefit.
    This talk is about legacy code like Feathers’ book. This talk does not dwell on technical details. It points to many tools and disciplines, but we can’t cover it all without making it a several-day workshop.
    I’m an independent consultant, developer, trainer. Work with UGs and IASA in Denver. NFJS speaker.
  • This talk is addressed to architects, but all developers, PMs, and business people can benefit.
    This talk is about legacy code like Feathers’ book. This talk does not dwell on technical details. It points to many tools and disciplines, but we can’t cover it all without making it a several-day workshop.
    I’m an independent consultant, developer, trainer. Work with UGs and IASA in Denver. NFJS speaker.
  • This talk is addressed to architects, but all developers, PMs, and business people can benefit.
    This talk is about legacy code like Feathers’ book. This talk does not dwell on technical details. It points to many tools and disciplines, but we can’t cover it all without making it a several-day workshop.
    I’m an independent consultant, developer, trainer. Work with UGs and IASA in Denver. NFJS speaker.
  • This talk is addressed to architects, but all developers, PMs, and business people can benefit.
    This talk is about legacy code like Feathers’ book. This talk does not dwell on technical details. It points to many tools and disciplines, but we can’t cover it all without making it a several-day workshop.
    I’m an independent consultant, developer, trainer. Work with UGs and IASA in Denver. NFJS speaker.
  • This talk is addressed to architects, but all developers, PMs, and business people can benefit.
    This talk is about legacy code like Feathers’ book. This talk does not dwell on technical details. It points to many tools and disciplines, but we can’t cover it all without making it a several-day workshop.
    I’m an independent consultant, developer, trainer. Work with UGs and IASA in Denver. NFJS speaker.
  • This talk is addressed to architects, but all developers, PMs, and business people can benefit.
    This talk is about legacy code like Feathers’ book. This talk does not dwell on technical details. It points to many tools and disciplines, but we can’t cover it all without making it a several-day workshop.
    I’m an independent consultant, developer, trainer. Work with UGs and IASA in Denver. NFJS speaker.
  • This talk is addressed to architects, but all developers, PMs, and business people can benefit.
    This talk is about legacy code like Feathers’ book. This talk does not dwell on technical details. It points to many tools and disciplines, but we can’t cover it all without making it a several-day workshop.
    I’m an independent consultant, developer, trainer. Work with UGs and IASA in Denver. NFJS speaker.
  • This talk is addressed to architects, but all developers, PMs, and business people can benefit.
    This talk is about legacy code like Feathers’ book. This talk does not dwell on technical details. It points to many tools and disciplines, but we can’t cover it all without making it a several-day workshop.
    I’m an independent consultant, developer, trainer. Work with UGs and IASA in Denver. NFJS speaker.
  • St. George was originally venerated in Cappadocia, now known as Turkey. The origins of the myth are unclear, but the story is familiar: the town Silene is beset by a dragon (Ascalon) living in a lake. The peace is kept by feeding the dragons sheep, later children chosen by lottery, finally the king’s daughter. George appears on horseback, wounding the dragon with a spear, the fashioning the virgin’s corset (in the medieval version) into a collar and leading it back to down. George says I’ll kill it if you’ll repent and be baptized.
  • St. George was originally venerated in Cappadocia, now known as Turkey. The origins of the myth are unclear, but the story is familiar: the town Silene is beset by a dragon (Ascalon) living in a lake. The peace is kept by feeding the dragons sheep, later children chosen by lottery, finally the king’s daughter. George appears on horseback, wounding the dragon with a spear, the fashioning the virgin’s corset (in the medieval version) into a collar and leading it back to down. George says I’ll kill it if you’ll repent and be baptized.
  • St. George was originally venerated in Cappadocia, now known as Turkey. The origins of the myth are unclear, but the story is familiar: the town Silene is beset by a dragon (Ascalon) living in a lake. The peace is kept by feeding the dragons sheep, later children chosen by lottery, finally the king’s daughter. George appears on horseback, wounding the dragon with a spear, the fashioning the virgin’s corset (in the medieval version) into a collar and leading it back to down. George says I’ll kill it if you’ll repent and be baptized.
  • St. George was originally venerated in Cappadocia, now known as Turkey. The origins of the myth are unclear, but the story is familiar: the town Silene is beset by a dragon (Ascalon) living in a lake. The peace is kept by feeding the dragons sheep, later children chosen by lottery, finally the king’s daughter. George appears on horseback, wounding the dragon with a spear, the fashioning the virgin’s corset (in the medieval version) into a collar and leading it back to down. George says I’ll kill it if you’ll repent and be baptized.
  • St. George was originally venerated in Cappadocia, now known as Turkey. The origins of the myth are unclear, but the story is familiar: the town Silene is beset by a dragon (Ascalon) living in a lake. The peace is kept by feeding the dragons sheep, later children chosen by lottery, finally the king’s daughter. George appears on horseback, wounding the dragon with a spear, the fashioning the virgin’s corset (in the medieval version) into a collar and leading it back to down. George says I’ll kill it if you’ll repent and be baptized.
  • St. George was originally venerated in Cappadocia, now known as Turkey. The origins of the myth are unclear, but the story is familiar: the town Silene is beset by a dragon (Ascalon) living in a lake. The peace is kept by feeding the dragons sheep, later children chosen by lottery, finally the king’s daughter. George appears on horseback, wounding the dragon with a spear, the fashioning the virgin’s corset (in the medieval version) into a collar and leading it back to down. George says I’ll kill it if you’ll repent and be baptized.
  • St. George was originally venerated in Cappadocia, now known as Turkey. The origins of the myth are unclear, but the story is familiar: the town Silene is beset by a dragon (Ascalon) living in a lake. The peace is kept by feeding the dragons sheep, later children chosen by lottery, finally the king’s daughter. George appears on horseback, wounding the dragon with a spear, the fashioning the virgin’s corset (in the medieval version) into a collar and leading it back to down. George says I’ll kill it if you’ll repent and be baptized.
  • St. George was originally venerated in Cappadocia, now known as Turkey. The origins of the myth are unclear, but the story is familiar: the town Silene is beset by a dragon (Ascalon) living in a lake. The peace is kept by feeding the dragons sheep, later children chosen by lottery, finally the king’s daughter. George appears on horseback, wounding the dragon with a spear, the fashioning the virgin’s corset (in the medieval version) into a collar and leading it back to down. George says I’ll kill it if you’ll repent and be baptized.
  • St. George was originally venerated in Cappadocia, now known as Turkey. The origins of the myth are unclear, but the story is familiar: the town Silene is beset by a dragon (Ascalon) living in a lake. The peace is kept by feeding the dragons sheep, later children chosen by lottery, finally the king’s daughter. George appears on horseback, wounding the dragon with a spear, the fashioning the virgin’s corset (in the medieval version) into a collar and leading it back to down. George says I’ll kill it if you’ll repent and be baptized.
  • St. George was originally venerated in Cappadocia, now known as Turkey. The origins of the myth are unclear, but the story is familiar: the town Silene is beset by a dragon (Ascalon) living in a lake. The peace is kept by feeding the dragons sheep, later children chosen by lottery, finally the king’s daughter. George appears on horseback, wounding the dragon with a spear, the fashioning the virgin’s corset (in the medieval version) into a collar and leading it back to down. George says I’ll kill it if you’ll repent and be baptized.
  • St. George was originally venerated in Cappadocia, now known as Turkey. The origins of the myth are unclear, but the story is familiar: the town Silene is beset by a dragon (Ascalon) living in a lake. The peace is kept by feeding the dragons sheep, later children chosen by lottery, finally the king’s daughter. George appears on horseback, wounding the dragon with a spear, the fashioning the virgin’s corset (in the medieval version) into a collar and leading it back to down. George says I’ll kill it if you’ll repent and be baptized.
  • Anecdote about failed migration.
    This is a large-scale action that you can’t sneak in like testing in Groovy.
    Killing a dragon is great. You do a good thing, and people remember you. You learn a lot. You improve.
    But it might hurt you! Be ready. Also, people usually won’t tolerate the risks unless they feel the pain.
  • Anecdote about failed migration.
    This is a large-scale action that you can’t sneak in like testing in Groovy.
    Killing a dragon is great. You do a good thing, and people remember you. You learn a lot. You improve.
    But it might hurt you! Be ready. Also, people usually won’t tolerate the risks unless they feel the pain.
  • Anecdote about failed migration.
    This is a large-scale action that you can’t sneak in like testing in Groovy.
    Killing a dragon is great. You do a good thing, and people remember you. You learn a lot. You improve.
    But it might hurt you! Be ready. Also, people usually won’t tolerate the risks unless they feel the pain.
  • Anecdote about failed migration.
    This is a large-scale action that you can’t sneak in like testing in Groovy.
    Killing a dragon is great. You do a good thing, and people remember you. You learn a lot. You improve.
    But it might hurt you! Be ready. Also, people usually won’t tolerate the risks unless they feel the pain.
  • Anecdote about failed migration.
    This is a large-scale action that you can’t sneak in like testing in Groovy.
    Killing a dragon is great. You do a good thing, and people remember you. You learn a lot. You improve.
    But it might hurt you! Be ready. Also, people usually won’t tolerate the risks unless they feel the pain.
  • Anecdote about failed migration.
    This is a large-scale action that you can’t sneak in like testing in Groovy.
    Killing a dragon is great. You do a good thing, and people remember you. You learn a lot. You improve.
    But it might hurt you! Be ready. Also, people usually won’t tolerate the risks unless they feel the pain.
  • Anecdote about failed migration.
    This is a large-scale action that you can’t sneak in like testing in Groovy.
    Killing a dragon is great. You do a good thing, and people remember you. You learn a lot. You improve.
    But it might hurt you! Be ready. Also, people usually won’t tolerate the risks unless they feel the pain.
  • Anecdote about failed migration.
    This is a large-scale action that you can’t sneak in like testing in Groovy.
    Killing a dragon is great. You do a good thing, and people remember you. You learn a lot. You improve.
    But it might hurt you! Be ready. Also, people usually won’t tolerate the risks unless they feel the pain.
  • Nothing of scale can succeed without them. Groovy unit testing doesn’t need them, even if they exist.
    Should be expressable in terms of some simple business abstraction (production cost, time to market, distribution, quality, etc.)
    Probably not your job, but you’d better know these anyway.
  • Nothing of scale can succeed without them. Groovy unit testing doesn’t need them, even if they exist.
    Should be expressable in terms of some simple business abstraction (production cost, time to market, distribution, quality, etc.)
    Probably not your job, but you’d better know these anyway.
  • Nothing of scale can succeed without them. Groovy unit testing doesn’t need them, even if they exist.
    Should be expressable in terms of some simple business abstraction (production cost, time to market, distribution, quality, etc.)
    Probably not your job, but you’d better know these anyway.
  • Nothing of scale can succeed without them. Groovy unit testing doesn’t need them, even if they exist.
    Should be expressable in terms of some simple business abstraction (production cost, time to market, distribution, quality, etc.)
    Probably not your job, but you’d better know these anyway.
  • Nothing of scale can succeed without them. Groovy unit testing doesn’t need them, even if they exist.
    Should be expressable in terms of some simple business abstraction (production cost, time to market, distribution, quality, etc.)
    Probably not your job, but you’d better know these anyway.
  • Nothing of scale can succeed without them. Groovy unit testing doesn’t need them, even if they exist.
    Should be expressable in terms of some simple business abstraction (production cost, time to market, distribution, quality, etc.)
    Probably not your job, but you’d better know these anyway.
  • Nothing of scale can succeed without them. Groovy unit testing doesn’t need them, even if they exist.
    Should be expressable in terms of some simple business abstraction (production cost, time to market, distribution, quality, etc.)
    Probably not your job, but you’d better know these anyway.
  • An old version of something important is going obsolete. You have a new CIO who hates Java/loves Java/wants to make an impression.
  • An old version of something important is going obsolete. You have a new CIO who hates Java/loves Java/wants to make an impression.
  • An old version of something important is going obsolete. You have a new CIO who hates Java/loves Java/wants to make an impression.
  • An old version of something important is going obsolete. You have a new CIO who hates Java/loves Java/wants to make an impression.
  • An old version of something important is going obsolete. You have a new CIO who hates Java/loves Java/wants to make an impression.
  • An old version of something important is going obsolete. You have a new CIO who hates Java/loves Java/wants to make an impression.
  • It’s a good time to back up and take a fresh look at the old system.
  • It’s a good time to back up and take a fresh look at the old system.
  • The business understands the problem better now. The business has changed. Reexmaining old concept will lead to better features, less code. Previous hacks/workarounds can die. Smaller system, less waste.
  • Resist all change. The legacy system supports a business and works. Person-decades of effort have gone into it.
  • Resist all change. The legacy system supports a business and works. Person-decades of effort have gone into it.
  • Resist all change. The legacy system supports a business and works. Person-decades of effort have gone into it.
  • Resist all change. The legacy system supports a business and works. Person-decades of effort have gone into it.
  • Resist all change. The legacy system supports a business and works. Person-decades of effort have gone into it.
  • Resist all change. The legacy system supports a business and works. Person-decades of effort have gone into it.
  • Resist all change. The legacy system supports a business and works. Person-decades of effort have gone into it.
  • Resist all change. The legacy system supports a business and works. Person-decades of effort have gone into it.
  • Resist all change. The legacy system supports a business and works. Person-decades of effort have gone into it.
  • Resist all change. The legacy system supports a business and works. Person-decades of effort have gone into it.
  • Resist all change. The legacy system supports a business and works. Person-decades of effort have gone into it.
  • Resist all change. The legacy system supports a business and works. Person-decades of effort have gone into it.
  • Resist all change. The legacy system supports a business and works. Person-decades of effort have gone into it.
  • Does anybody really choose? Usually not. Probably there’s an enterprise standard, or an architect or tech-savvy executive has a preference or a relationship that makes the decision for you.
  • Does anybody really choose? Usually not. Probably there’s an enterprise standard, or an architect or tech-savvy executive has a preference or a relationship that makes the decision for you.
  • Choosing by hipness: might not be bad. Can be a strategic recruiting advantage, can expose you to new productivity gains.
    Probably is bad, though. Resume-driven design is a moral failing.
  • Choosing by hipness: might not be bad. Can be a strategic recruiting advantage, can expose you to new productivity gains.
    Probably is bad, though. Resume-driven design is a moral failing.
  • If you’re a Java shop, prefer Java as a platform. If you’re a PHP shop, consider staying there. You can change a team, but it’s hard.
  • If you’re a Java shop, prefer Java as a platform. If you’re a PHP shop, consider staying there. You can change a team, but it’s hard.
  • These debates are interminable. They are not useless, but in reality, you can probably build anything with anything. While specific characteristics matter, form is more important than function. What is the wood grain of the platform? What does the community care about?
  • These debates are interminable. They are not useless, but in reality, you can probably build anything with anything. While specific characteristics matter, form is more important than function. What is the wood grain of the platform? What does the community care about?
  • These debates are interminable. They are not useless, but in reality, you can probably build anything with anything. While specific characteristics matter, form is more important than function. What is the wood grain of the platform? What does the community care about?
  • These debates are interminable. They are not useless, but in reality, you can probably build anything with anything. While specific characteristics matter, form is more important than function. What is the wood grain of the platform? What does the community care about?
  • These debates are interminable. They are not useless, but in reality, you can probably build anything with anything. While specific characteristics matter, form is more important than function. What is the wood grain of the platform? What does the community care about?
  • These debates are interminable. They are not useless, but in reality, you can probably build anything with anything. While specific characteristics matter, form is more important than function. What is the wood grain of the platform? What does the community care about?
  • These debates are interminable. They are not useless, but in reality, you can probably build anything with anything. While specific characteristics matter, form is more important than function. What is the wood grain of the platform? What does the community care about?
  • These debates are interminable. They are not useless, but in reality, you can probably build anything with anything. While specific characteristics matter, form is more important than function. What is the wood grain of the platform? What does the community care about?
  • These debates are interminable. They are not useless, but in reality, you can probably build anything with anything. While specific characteristics matter, form is more important than function. What is the wood grain of the platform? What does the community care about?
  • These debates are interminable. They are not useless, but in reality, you can probably build anything with anything. While specific characteristics matter, form is more important than function. What is the wood grain of the platform? What does the community care about?
  • These debates are interminable. They are not useless, but in reality, you can probably build anything with anything. While specific characteristics matter, form is more important than function. What is the wood grain of the platform? What does the community care about?
  • These debates are interminable. They are not useless, but in reality, you can probably build anything with anything. While specific characteristics matter, form is more important than function. What is the wood grain of the platform? What does the community care about?
  • These debates are interminable. They are not useless, but in reality, you can probably build anything with anything. While specific characteristics matter, form is more important than function. What is the wood grain of the platform? What does the community care about?
  • These debates are interminable. They are not useless, but in reality, you can probably build anything with anything. While specific characteristics matter, form is more important than function. What is the wood grain of the platform? What does the community care about?
  • These debates are interminable. They are not useless, but in reality, you can probably build anything with anything. While specific characteristics matter, form is more important than function. What is the wood grain of the platform? What does the community care about?
  • These debates are interminable. They are not useless, but in reality, you can probably build anything with anything. While specific characteristics matter, form is more important than function. What is the wood grain of the platform? What does the community care about?
  • Prototyping: a sticky wicket. Usually can’t find pain points in a simple demo. Hard to discern productivity advantages when you’re just dipping your toe in the water.
    BUT NOT ALWAYS. Can be good on large-scale stuff. Also, you should always play around with new technologies; just recognize the limitations in doing so.
  • Prototyping: a sticky wicket. Usually can’t find pain points in a simple demo. Hard to discern productivity advantages when you’re just dipping your toe in the water.
    BUT NOT ALWAYS. Can be good on large-scale stuff. Also, you should always play around with new technologies; just recognize the limitations in doing so.
  • We won’t get into many specifics. Writing the new app is just building code. Lots of help on how to do that. Go to No Fluff if you want to learn more. :)
    It’s up to you to do the actual lancing of the beast, but there are some areas of interest we can discuss along the way.
  • We won’t get into many specifics. Writing the new app is just building code. Lots of help on how to do that. Go to No Fluff if you want to learn more. :)
    It’s up to you to do the actual lancing of the beast, but there are some areas of interest we can discuss along the way.
  • We won’t get into many specifics. Writing the new app is just building code. Lots of help on how to do that. Go to No Fluff if you want to learn more. :)
    It’s up to you to do the actual lancing of the beast, but there are some areas of interest we can discuss along the way.
  • The biggest issue is who lives and who dies. This affects everything.
  • The biggest issue is who lives and who dies. This affects everything.
  • When the legacy DB is bigger than just this app or has other reasons to live, you have to stick with it. This will limit your ability to improve things.
  • When the legacy DB is bigger than just this app or has other reasons to live, you have to stick with it. This will limit your ability to improve things.
  • This can help a little bit, like tylenol. Treating symptoms. In reality, domain modeling and schema design leak onto one another a lot. Tacit knowledge of ORM framework shapes domain design.
  • This can help a little bit, like tylenol. Treating symptoms. In reality, domain modeling and schema design leak onto one another a lot. Tacit knowledge of ORM framework shapes domain design.
  • This doesn’t mean the legacy database has to stay awful forever. You can reform an old schema a piece at a time. You need Liquibase and lots of help.
    Interestingly, Ambler also holds the key to true migration.
  • This doesn’t mean the legacy database has to stay awful forever. You can reform an old schema a piece at a time. You need Liquibase and lots of help.
    Interestingly, Ambler also holds the key to true migration.
  • This doesn’t mean the legacy database has to stay awful forever. You can reform an old schema a piece at a time. You need Liquibase and lots of help.
    Interestingly, Ambler also holds the key to true migration.
  • This doesn’t mean the legacy database has to stay awful forever. You can reform an old schema a piece at a time. You need Liquibase and lots of help.
    Interestingly, Ambler also holds the key to true migration.
  • This doesn’t mean the legacy database has to stay awful forever. You can reform an old schema a piece at a time. You need Liquibase and lots of help.
    Interestingly, Ambler also holds the key to true migration.
  • This doesn’t mean the legacy database has to stay awful forever. You can reform an old schema a piece at a time. You need Liquibase and lots of help.
    Interestingly, Ambler also holds the key to true migration.
  • This doesn’t mean the legacy database has to stay awful forever. You can reform an old schema a piece at a time. You need Liquibase and lots of help.
    Interestingly, Ambler also holds the key to true migration.
  • The new schema comes to life alongside the old, and triggers synchronize them. Assumptions of triggers.
    If triggers won’t work, you can try ETL—with time constant constraints.
    Also consider nontraditional NoSQL solutions.
    Concurrency scenarios.
  • The new schema comes to life alongside the old, and triggers synchronize them. Assumptions of triggers.
    If triggers won’t work, you can try ETL—with time constant constraints.
    Also consider nontraditional NoSQL solutions.
    Concurrency scenarios.
  • The new schema comes to life alongside the old, and triggers synchronize them. Assumptions of triggers.
    If triggers won’t work, you can try ETL—with time constant constraints.
    Also consider nontraditional NoSQL solutions.
    Concurrency scenarios.
  • The new schema comes to life alongside the old, and triggers synchronize them. Assumptions of triggers.
    If triggers won’t work, you can try ETL—with time constant constraints.
    Also consider nontraditional NoSQL solutions.
    Concurrency scenarios.
  • The new schema comes to life alongside the old, and triggers synchronize them. Assumptions of triggers.
    If triggers won’t work, you can try ETL—with time constant constraints.
    Also consider nontraditional NoSQL solutions.
    Concurrency scenarios.
  • The new schema comes to life alongside the old, and triggers synchronize them. Assumptions of triggers.
    If triggers won’t work, you can try ETL—with time constant constraints.
    Also consider nontraditional NoSQL solutions.
    Concurrency scenarios.
  • The new schema comes to life alongside the old, and triggers synchronize them. Assumptions of triggers.
    If triggers won’t work, you can try ETL—with time constant constraints.
    Also consider nontraditional NoSQL solutions.
    Concurrency scenarios.
  • Sometimes there are good reasons not to do this with triggers, like changing database technologies or scale considerations. This is difficult, but answers may exist.
  • Sometimes there are good reasons not to do this with triggers, like changing database technologies or scale considerations. This is difficult, but answers may exist.
  • This is a good time to consider whether legacy content belongs in an RDBMS.
  • This is a good time to consider whether legacy content belongs in an RDBMS.
  • Are there lots of blobs? That’s a smell.
  • Good solutions for nonrelational content.
  • Good solutions for nonrelational content.
  • Good solutions for nonrelational content.
  • Good solutions for nonrelational content.
  • To make a credible go at this, you need tooling. Liquibase provides this.
  • To make a credible go at this, you need tooling. Liquibase provides this.
  • If this is your existing team, they’re probably up to the task. But is this your team? Will yours need formal training? Do they want to learn new things? Have they demonstrated an ability to learn? Does a sober assessment of your team tell you they can do this?
  • If this is your existing team, they’re probably up to the task. But is this your team? Will yours need formal training? Do they want to learn new things? Have they demonstrated an ability to learn? Does a sober assessment of your team tell you they can do this?
  • Maybe that’s not your team. If you’re refactoring to a new technology, can you hire for it? Downside to cutting-edge tech: hard to recruit. How to look for relevant experience. Look for related, foundational, and analogical technologies. Consider your market.
  • Maybe that’s not your team. If you’re refactoring to a new technology, can you hire for it? Downside to cutting-edge tech: hard to recruit. How to look for relevant experience. Look for related, foundational, and analogical technologies. Consider your market.
  • Anxiety is a threat response. Cognitive resources are conserved to deal with the threat. This makes us unpleasant to deal with, particularly when the threat is misperceived.
    Much more to be said about relational systems as they apply to the workplace. Most of this is out of scope, but you *will* deal with anxious people if you’re refactoring a legacy system of any size.
  • Anxiety is a threat response. Cognitive resources are conserved to deal with the threat. This makes us unpleasant to deal with, particularly when the threat is misperceived.
    Much more to be said about relational systems as they apply to the workplace. Most of this is out of scope, but you *will* deal with anxious people if you’re refactoring a legacy system of any size.
  • Anxiety is a threat response. Cognitive resources are conserved to deal with the threat. This makes us unpleasant to deal with, particularly when the threat is misperceived.
    Much more to be said about relational systems as they apply to the workplace. Most of this is out of scope, but you *will* deal with anxious people if you’re refactoring a legacy system of any size.
  • Anxiety is a threat response. Cognitive resources are conserved to deal with the threat. This makes us unpleasant to deal with, particularly when the threat is misperceived.
    Much more to be said about relational systems as they apply to the workplace. Most of this is out of scope, but you *will* deal with anxious people if you’re refactoring a legacy system of any size.
  • Anxiety is a threat response. Cognitive resources are conserved to deal with the threat. This makes us unpleasant to deal with, particularly when the threat is misperceived.
    Much more to be said about relational systems as they apply to the workplace. Most of this is out of scope, but you *will* deal with anxious people if you’re refactoring a legacy system of any size.
  • Anxiety is a threat response. Cognitive resources are conserved to deal with the threat. This makes us unpleasant to deal with, particularly when the threat is misperceived.
    Much more to be said about relational systems as they apply to the workplace. Most of this is out of scope, but you *will* deal with anxious people if you’re refactoring a legacy system of any size.
  • Anxiety is a threat response. Cognitive resources are conserved to deal with the threat. This makes us unpleasant to deal with, particularly when the threat is misperceived.
    Much more to be said about relational systems as they apply to the workplace. Most of this is out of scope, but you *will* deal with anxious people if you’re refactoring a legacy system of any size.
  • Anxiety is a threat response. Cognitive resources are conserved to deal with the threat. This makes us unpleasant to deal with, particularly when the threat is misperceived.
    Much more to be said about relational systems as they apply to the workplace. Most of this is out of scope, but you *will* deal with anxious people if you’re refactoring a legacy system of any size.
  • Anxiety is a threat response. Cognitive resources are conserved to deal with the threat. This makes us unpleasant to deal with, particularly when the threat is misperceived.
    Much more to be said about relational systems as they apply to the workplace. Most of this is out of scope, but you *will* deal with anxious people if you’re refactoring a legacy system of any size.
  • Anxiety is a threat response. Cognitive resources are conserved to deal with the threat. This makes us unpleasant to deal with, particularly when the threat is misperceived.
    Much more to be said about relational systems as they apply to the workplace. Most of this is out of scope, but you *will* deal with anxious people if you’re refactoring a legacy system of any size.
  • Anxiety is a threat response. Cognitive resources are conserved to deal with the threat. This makes us unpleasant to deal with, particularly when the threat is misperceived.
    Much more to be said about relational systems as they apply to the workplace. Most of this is out of scope, but you *will* deal with anxious people if you’re refactoring a legacy system of any size.
  • Anxiety is a threat response. Cognitive resources are conserved to deal with the threat. This makes us unpleasant to deal with, particularly when the threat is misperceived.
    Much more to be said about relational systems as they apply to the workplace. Most of this is out of scope, but you *will* deal with anxious people if you’re refactoring a legacy system of any size.
  • Anxiety is a threat response. Cognitive resources are conserved to deal with the threat. This makes us unpleasant to deal with, particularly when the threat is misperceived.
    Much more to be said about relational systems as they apply to the workplace. Most of this is out of scope, but you *will* deal with anxious people if you’re refactoring a legacy system of any size.
  • Anxiety is a threat response. Cognitive resources are conserved to deal with the threat. This makes us unpleasant to deal with, particularly when the threat is misperceived.
    Much more to be said about relational systems as they apply to the workplace. Most of this is out of scope, but you *will* deal with anxious people if you’re refactoring a legacy system of any size.
  • Anxiety is a threat response. Cognitive resources are conserved to deal with the threat. This makes us unpleasant to deal with, particularly when the threat is misperceived.
    Much more to be said about relational systems as they apply to the workplace. Most of this is out of scope, but you *will* deal with anxious people if you’re refactoring a legacy system of any size.
  • Fred Brooks: "The second is the most dangerous system a man ever designs." (p 55)
    Throw in all the things you thought of the first time. Only applies if the same architect is building the second one, or knew the first one very well.
    You had to live with all of these problems all this time. And they were your fault! Finally things can be made right.
    Related: the “now’s our chance” dynamic of sneaking functionality in. This can afflict anyone.
  • We’ve talked about how rebuilding a legacy system interacts with the business, how you should approach it to maximize your reputation, reasons businesses do this, how to choose a platform, how to deal with the database, what impacts this can have on people, how to employ web services, and what kinds of pitfalls we can find. This is a difficult task, and it will always be painful, but it can be done.
  • Slaying The Legacy Dragon: Practical Lessons in Replacing Old Software

    1. 1. Slaying the Legacy Dragon Practical Lessons in Replacing Old Software Tim Berglund
    2. 2. Housekeeping
    3. 3. Housekeeping Audience
    4. 4. Housekeeping Audience via Negativa
    5. 5. Housekeeping Audience via Negativa Disable write-only mode
    6. 6. Housekeeping Audience via Negativa Disable write-only mode Tim Berglund www.augusttechgroup.com tim.berglund@augusttechgroup.com @tlberglund
    7. 7. Housekeeping Audience via Negativa Disable write-only mode Tim Berglund www.augusttechgroup.com tim.berglund@augusttechgroup.com @tlberglund Sponsored by No Fluff Just Stuff
    8. 8. Slaying the Dragon
    9. 9. Slaying the Dragon
    10. 10. Slaying the Dragon St. George
    11. 11. Slaying the Dragon St. George Untestable
    12. 12. Slaying the Dragon St. George Untestable Brittle
    13. 13. Slaying the Dragon St. George Untestable Brittle Orphaned framework
    14. 14. Slaying the Dragon St. George Untestable Brittle Orphaned framework Low productivity
    15. 15. Slaying the Dragon St. George Untestable Brittle Orphaned framework Low productivity Downtime
    16. 16. Slaying the Dragon St. George Untestable Brittle Orphaned framework Low productivity Downtime Poor performance
    17. 17. Slaying the Dragon St. George Untestable Brittle Orphaned framework Low productivity Downtime Poor performance Frustrated Users
    18. 18. Slaying the Dragon St. George Untestable Brittle Orphaned framework Low productivity Downtime Poor performance Frustrated Users A Frustrated Business
    19. 19. Not a Guerrilla Action
    20. 20. Not a Guerrilla Action Che was unit testing in Groovy
    21. 21. Not a Guerrilla Action Che was unit testing in Groovy Executive buy-in
    22. 22. Not a Guerrilla Action Che was unit testing in Groovy Executive buy-in Being St. George
    23. 23. Not a Guerrilla Action Che was unit testing in Groovy Executive buy-in Being St. George That’s a big dragon
    24. 24. Not a Guerrilla Action Che was unit testing in Groovy Executive buy-in Being St. George That’s a big dragon The king’s daughter
    25. 25. Business Drivers
    26. 26. Business Drivers
    27. 27. Business Drivers Writing tests in Groovy?
    28. 28. Business Drivers Writing tests in Groovy? For Anything of Scale
    29. 29. Business Drivers Writing tests in Groovy? For Anything of Scale Drivers must be KNOWN
    30. 30. Business Drivers Writing tests in Groovy? For Anything of Scale Drivers must be KNOWN Drivers must be ARTICULATED
    31. 31. Business Drivers Writing tests in Groovy? For Anything of Scale Drivers must be KNOWN Drivers must be ARTICULATED Drivers must be REPEATED
    32. 32. Reasons for a Reboot
    33. 33. Reasons for a Reboot
    34. 34. Reasons for a Reboot EOL
    35. 35. Reasons for a Reboot EOL CIO
    36. 36. Reasons for a Reboot EOL CIO Recruiting: it’s not them, it’s you
    37. 37. Reasons for a Reboot EOL CIO Recruiting: it’s not them, it’s you Nonfunctional expectations
    38. 38. Reasons for a Reboot EOL CIO Recruiting: it’s not them, it’s you Nonfunctional expectations Technology limitations
    39. 39. Reconceptualizing
    40. 40. Reconceptualizing
    41. 41. Don’t keep it the same!
    42. 42. Don’t change it!
    43. 43. Don’t change it!
    44. 44. Don’t change it!
    45. 45. Don’t change it!
    46. 46. Don’t change it! Tacit Knowledge
    47. 47. Don’t change it! Tacit Knowledge User habit
    48. 48. Don’t change it! Tacit Knowledge User habit Frustrating—but familiar
    49. 49. Don’t change it! Tacit Knowledge User habit Frustrating—but familiar Value the legacy system!
    50. 50. Don’t change it! Tacit Knowledge User habit Frustrating—but familiar Value the legacy system! http://www.joelonsoftware.com/articles/fog0000000
    51. 51. Choosing a Platform
    52. 52. Choosing by Hipness
    53. 53. Choosing by Team Capabilities
    54. 54. Platform Capabilities
    55. 55. Platform Capabilities
    56. 56. Prototyping
    57. 57. Prototyping
    58. 58. The Dragon Itself
    59. 59. The Dragon Itself NOTE: this talk contains no actual dragon battle plans.
    60. 60. Database Migration
    61. 61. Database Migration
    62. 62. When the Legacy Schema Won’t Die
    63. 63. When the Legacy Schema Won’t Die
    64. 64. Clever ORM Mapping
    65. 65. Clever ORM Mapping
    66. 66. Legacy Refactoring
    67. 67. Legacy Refactoring Normally a dark art
    68. 68. Legacy Refactoring Normally a dark art Possible with tools and discipline
    69. 69. Legacy Refactoring Normally a dark art Possible with tools and discipline <shameless-plug />
    70. 70. Legacy Refactoring Normally a dark art Possible with tools and discipline <shameless-plug /> There is hope!
    71. 71. Legacy Migration
    72. 72. Legacy Migration
    73. 73. Legacy Migration Two Databases Coexist
    74. 74. Legacy Migration Two Databases Coexist Triggers for synchronization
    75. 75. Legacy Migration Two Databases Coexist Triggers for synchronization Old schema withers on the vine
    76. 76. Legacy Migration Two Databases Coexist Triggers for synchronization Old schema withers on the vine Arduous but well worth it
    77. 77. When Triggers Attack
    78. 78. NoSQL
    79. 79. NoSQL
    80. 80. NoSQL
    81. 81. NoSQL
    82. 82. NoSQL
    83. 83. NoSQL
    84. 84. NoSQL http://nosql.mypopescu.com/
    85. 85. Schema Change
    86. 86. Schema Change
    87. 87. Web Services
    88. 88. Web Services
    89. 89. People Problems
    90. 90. Using Your Existing Team
    91. 91. Using Your Existing Team
    92. 92. Are skills available to hire?
    93. 93. Are skills available to hire?
    94. 94. Red Team vs. Blue Team
    95. 95. Red Team vs. Blue Team Legacy Team
    96. 96. Red Team vs. Blue Team Legacy Team Migration Team
    97. 97. Red Team vs. Blue Team Legacy Team Migration Team Valuing the legacy system
    98. 98. Red Team vs. Blue Team Legacy Team Migration Team Valuing the legacy system Good Blue Players
    99. 99. Red Team vs. Blue Team Legacy Team Migration Team Valuing the legacy system Good Blue Players Recalcitrant Blue Players
    100. 100. Red Team vs. Blue Team Legacy Team Migration Team Valuing the legacy system Good Blue Players Recalcitrant Blue Players Untrainable Blue Players
    101. 101. An Anxious Team
    102. 102. An Anxious Team Bowen Theory
    103. 103. An Anxious Team Bowen Theory Results of Anxiety
    104. 104. An Anxious Team Bowen Theory Results of Anxiety Decreased ability to learn
    105. 105. An Anxious Team Bowen Theory Results of Anxiety Decreased ability to learn Demands for certainty
    106. 106. An Anxious Team Bowen Theory Results of Anxiety Decreased ability to learn Demands for certainty Either-or thinking
    107. 107. An Anxious Team Bowen Theory Results of Anxiety Decreased ability to learn Demands for certainty Either-or thinking Desire for quick fix
    108. 108. An Anxious Team Bowen Theory Results of Anxiety Decreased ability to learn Demands for certainty Either-or thinking Desire for quick fix Defensive behavior
    109. 109. An Anxious Team Bowen Theory Results of Anxiety Decreased ability to learn Demands for certainty Either-or thinking Desire for quick fix Defensive behavior Reduced imagination
    110. 110. An Anxious Team Bowen Theory Results of Anxiety Decreased ability to learn Demands for certainty Either-or thinking Desire for quick fix Defensive behavior Reduced imagination You are dumb and mean
    111. 111. An Anxious Team Bowen Theory Results of Anxiety Decreased ability to learn Demands for certainty Either-or thinking Desire for quick fix Defensive behavior Reduced imagination You are dumb and mean Solutions
    112. 112. An Anxious Team Bowen Theory Results of Anxiety Decreased ability to learn Demands for certainty Either-or thinking Desire for quick fix Defensive behavior Reduced imagination You are dumb and mean Solutions Is it rational?
    113. 113. An Anxious Team Bowen Theory Results of Anxiety Decreased ability to learn Demands for certainty Either-or thinking Desire for quick fix Defensive behavior Reduced imagination You are dumb and mean Solutions Is it rational? Information
    114. 114. An Anxious Team Bowen Theory Results of Anxiety Decreased ability to learn Demands for certainty Either-or thinking Desire for quick fix Defensive behavior Reduced imagination You are dumb and mean Solutions Is it rational? Information Deal with vectors
    115. 115. Pitfalls
    116. 116. Pitfalls
    117. 117. Second System Effect
    118. 118. Second System Effect Adde parvum parvo magnus acervus erit!
    119. 119. Second System Effect srsly!
    120. 120. Second System Effect Ovid sez: “Add a little to a little and there will be a big pile.”
    121. 121. Overpromising
    122. 122. Overpromising Motivations
    123. 123. Overpromising Motivations Sealing the deal
    124. 124. Overpromising Motivations Sealing the deal Being a hero
    125. 125. Overpromising Motivations Sealing the deal Being a hero Sunny optimism
    126. 126. Overpromising Motivations Sealing the deal Being a hero Sunny optimism Dimensions
    127. 127. Overpromising Motivations Sealing the deal Being a hero Sunny optimism Dimensions Delivery time
    128. 128. Overpromising Motivations Sealing the deal Being a hero Sunny optimism Dimensions Delivery time Functionality
    129. 129. Overpromising Motivations Sealing the deal Being a hero Sunny optimism Dimensions Delivery time Functionality Nonfunctional improvements
    130. 130. Overpromising Motivations Sealing the deal Being a hero Sunny optimism Dimensions Delivery time Functionality Nonfunctional improvements Solutions
    131. 131. Overpromising Motivations Sealing the deal Being a hero Sunny optimism Dimensions Delivery time Functionality Nonfunctional improvements Solutions Iterate and measure
    132. 132. Overpromising Motivations Sealing the deal Being a hero Sunny optimism Dimensions Delivery time Functionality Nonfunctional improvements Solutions Iterate and measure Publish incremental results
    133. 133. Overpromising Motivations Sealing the deal Being a hero Sunny optimism Dimensions Delivery time Functionality Nonfunctional improvements Solutions Iterate and measure Publish incremental results Focus on business drivers
    134. 134. The Dragon, Slain
    135. 135. Thank You Tim Berglund www.augusttechgroup.com tim.berglund@augusttechgroup.com @tlberglund Sponsored by No Fluff Just Stuff
    136. 136. Photo Credits Smaug Destroying Laketown http://thespectacleblog.wordpress.com/2009/03/12/the-best-monsters-in-kid-lit/ 1950s Era Kitchen of Questionable Sexual Politics http://www.vintageadbrowser.com/household-ads-1950s#ad2x37yn4diylmqj St. George and the Dragon http://www.fromoldbooks.org/Cassell-MagazineOfArt/pages/337-St.-George-and-the-Dragon/ Che Guevara http://www3.uakron.edu/worldciv/pascher/che.html Typewriter Ad http://www.vintageadbrowser.com/office-ads-1950s#adbz3ufs8ths6l8k Slinky http://www.vintageadbrowser.com/tools-ads-1950s/2#ad4g1wzxkuxkuuy0 Platform Shoe http://www.flickr.com/photos/mediaeater/145813815/ Hipster http://www.flickr.com/photos/jalex_photo/2102264370/ Truck, Vines, and Oil Cans http://www.flickr.com/photos/m-louis/2065730338/sizes/l/ Rusty Oil Drums http://www.flickr.com/photos/carsten_tb/3332082580/
    137. 137. Photo Credits Painting Car http://www.flickr.com/photos/schudio/3182465850/ Credible Hulk http://www.flickr.com/photos/marcoveringa/3243701953/ Marine Corps Drill http://www.flickr.com/photos/sis/121704669/ Vintage Circus Ad http://www.vintageadbrowser.com/entertainment-ads-misc-years/16#admqdba5a2efbu10 Red Team vs. Blue Team http://news.filefront.com/the-red-vs-blue-team-calls-it-quits/ Pitfall http://www.flickr.com/photos/arkestra/323314605/ Ovid http://commons.wikimedia.org/wiki/File:Latin_Poet_Ovid.jpg Vintage Strange Contraption Ad http://www.vintageadbrowser.com/electronics-ads-1940s/61#adj2cm4xmpjmhnyb Blob http://www.flickr.com/photos/zen/513338540/ Gears http://www.flickr.com/photos/tim_d/155441805/

    ×