This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
I’m working on a DevOps transition for a large defense company. The plan is to lift and shift 2M+ lines of immensely complected code into containers in AWS. Simplicity and locality are novel concepts here and I’m struggling with how we decouple all this spaghetti code. My gut tells me we should scrap the code base and start over, but this isn’t going to go over well with managment. Any thoughts on how we might enable locality with a more gradual approach? Or convince managment it’s worth it to scrap the old code?
I’m working on a DevOps transition for a large defense company. The plan is to lift and shift 2M+ lines of immensely complected code into containers in AWS. Simplicity and locality are novel concepts here and I’m struggling with how we decouple all this spaghetti code. My gut tells me we should scrap the code base and start over, but this isn’t going to go over well with managment. Any thoughts on how we might enable locality with a more gradual approach? Or convince managment it’s worth it to scrap the old code?
One book that might be of interest is "The Mikado Method", which lays out a method for de-tangling the kind of code you're talking about.
Although 2M+ lines of code sounds somewhat overwhelming. What's the imagined timeline for this work?
Everything needs to be in AWS within 6 months, no specific timeline to make it simple
Then I'm guessing simplification will be out of the question. 2M+ lines of code sounds like a long-term project if it needs to be simplified. Although the Mikado Method might help, I doubt it could be done in 6 months.
Just my 2 cents from a few programs like this, usually the reason there are 2M lines is part of the reason why starting from scratch is going to recreate a lot of the same problems. I'd echo the Mikado commentary, and worth considering that strangling the code base ensures at least partial results in 6 months. Starting from scratch is more likely to be a big bang phoenix project (:
Hi All. I’m unable to make today’s Webinar with Dominica. Will the session be recorded? Thanks...
Hi All. I’m unable to make today’s Webinar with Dominica. Will the session be recorded? Thanks...
<!here> Our call with Dominica DeGrandis is in 2.5 hours. Any questions around time management and The Third Ideal? This is the perfect time to ask it.
Hi Dominica DeGrandis, I really liked your book! How do you scale the visualisation and make it possible to understand? The question is explained more below. First small scale: Let’s assume that we can visualise work for one team with kanban boards etc. The product (code) is also visible with work items connected to modules and repos. Then large scale: How do you visualise work for many teams if you have a complex product? Isn’t it a good idea to visualise the teams, the product and the work together? It’s like a combination of three fine books: a) The teams: Team Topologies, b) The product: From Project to Product and c) The work: Making Work Visible How can this be visualised for two kinds of companies: • DevOps. A large complex software ”product”. Build by the IT department at Parts Unlimited. Can also be Netflix, Spotify etc. • Industrial DevOps. A complex physical product, like a Tesla where the cor is the product. The product is built by Tesla in R&D and in manufacturing.
Hi Dominica DeGrandis, I really liked your book! How do you scale the visualisation and make it possible to understand? The question is explained more below. First small scale: Let’s assume that we can visualise work for one team with kanban boards etc. The product (code) is also visible with work items connected to modules and repos. Then large scale: How do you visualise work for many teams if you have a complex product? Isn’t it a good idea to visualise the teams, the product and the work together? It’s like a combination of three fine books: a) The teams: Team Topologies, b) The product: From Project to Product and c) The work: Making Work Visible How can this be visualised for two kinds of companies: • DevOps. A large complex software ”product”. Build by the IT department at Parts Unlimited. Can also be Netflix, Spotify etc. • Industrial DevOps. A complex physical product, like a Tesla where the cor is the product. The product is built by Tesla in R&D and in manufacturing.
<!here> You can now join our call with Dominica DeGrandis: https://zoom.us/j/863323710
Question for Dominica. What have been the most successful approach addressing technical debt. I have seen both creating a Hardenning Sprint/Iteration every now and then or release, or reserving velocity dedicated to this in each Sprint/Iteration. Any other options? Pros and cons? How you ensure to change the mindset in addressing debt every day. Thanks
Question for Dominica. What have been the most successful approach addressing technical debt. I have seen both creating a Hardenning Sprint/Iteration every now and then or release, or reserving velocity dedicated to this in each Sprint/Iteration. Any other options? Pros and cons? How you ensure to change the mindset in addressing debt every day. Thanks
Question to Dominica DeGrandis: Do you have some recommendations on how to handle info (work) coming from different systems like emails, calendars, tasks, Slack threads, Jira tickets? The situation is similar at work or at home, a lot of things you want to do.
Dominica, We use Kanban for our Ops team for the 3 types of work (business, internal, and maintenance). We have WIP limits and despite our best efforts, we still run into Thief Unknown Dependency. (i.e. Open a case with the vendor because we couldn't do it ourselves, or some kind of scheduling issue we could not foresee). So, cards get stuck in WIP for long periods of time, yet the tech is idle. So, they start working on something else. Then we run into the same kind of issue. To combat this we've started breaking the work up into even smaller batches. Just curious what other suggestions you might have in these scenarios.
Dominica, We use Kanban for our Ops team for the 3 types of work (business, internal, and maintenance). We have WIP limits and despite our best efforts, we still run into Thief Unknown Dependency. (i.e. Open a case with the vendor because we couldn't do it ourselves, or some kind of scheduling issue we could not foresee). So, cards get stuck in WIP for long periods of time, yet the tech is idle. So, they start working on something else. Then we run into the same kind of issue. To combat this we've started breaking the work up into even smaller batches. Just curious what other suggestions you might have in these scenarios.
"If there's a promise of having time to do daily improvements, but there's only time made for feature work, that's a huge red flag."
Thank's for sharing the presentation deck! Is it possible for you to do some quick updates with DI instead of debt?
Thank's for sharing the presentation deck! Is it possible for you to do some quick updates with DI instead of debt?
Done! https://itrevolution.com/wp-content/uploads/2020/01/ITRev-Webinar-Jan-2020.1.pdf