Podcasts about software projects

In software development, the real challenge often isn't coding—it's solving the right problems. In this episode of Building Better Developers with AI, hosts Rob Broadhead and Michael Meloche tackle one of the most overlooked but costly traps in tech: solving problems in software projects that don't need solving, while missing the ones that do. With the help of AI, they explore why teams often get stuck fixing symptoms instead of addressing root causes, launching features that don't matter, or optimizing performance before users even exist. Through candid examples and sharp insights, they demonstrate how developers can shift their mindset to deliver meaningful and lasting solutions. Solving Problems in Software Projects with AI This episode begins with a lighthearted intro: No, AI won't send killer robots to your house—but it can help you become a better developer. Rob and Michael let AI help set the topic: solving problems in software projects without actually solving the problem. They explain how developers often confuse motion with progress. Writing code doesn't mean you're building value. Launching a feature doesn't mean it's needed. These illusions create technical debt and user frustration. Michael compares this to marketing tricks, such as offering gift cards to attract users instead of improving the site to keep them engaged. Solving the Right Problem in Software Projects A quote from Einstein sets the tone: “If I had an hour to solve a problem, I'd spend 55 minutes thinking about the problem.” Rob and Michael emphasize the importance of understanding before acting. Too many developers rush to fix bugs without asking: What's broken? What does the user expect? Michael draws on insights from Dan Heath's "Upstream" to emphasize the importance of preventing issues, rather than just reacting to them. Effective developers think ahead and solve problems at the source—not just in the code, but in the system design and user flow. Avoid Quick Fixes When Solving Problems in Software Projects Rob warns against “band-aid fixes”—temporary solutions, such as increasing timeouts or adding unnecessary features. These surface-level patches don't address the core issue and often exacerbate the problem. Michael provides examples from the gaming world and enterprise software, highlighting instances where shipping buggy systems is done solely to meet a deadline, only to spend months patching them. Instead, they advocate for delivering a Minimum Viable Product (MVP) that truly addresses user needs. Why Listening Solves More Than Writing Code Michael shares a powerful technique: shut up and let your customer talk. Developers often assume they understand the problem after hearing a few words. But real insights come from listening deeply and asking open-ended questions. Rob adds that great discovery comes from dialogue. Clients often reveal critical needs casually—things you'd never hear if you rushed through the requirements checklist. Strategic Planning vs Feature Bloat Planning is vital, but discipline is equally important. Michael recommends an early brainstorm to throw every idea on the table. Then, trim down ruthlessly to only what's needed for your MVP. Rob warns against premature optimization: spending hours adjusting colors and layout before functionality is in place. Significant development is about timing—doing the right work at the right stage. Final Thoughts on Solving Problems in Software Projects The episode concludes with a call to action: focus on outcomes, not output. Don't measure your value by lines of code or number of features. Measure it by the clarity, stability, and usefulness of the solution you deliver. Sometimes, the best move is to slow down, ask more questions, and think more deeply. Rushing to implement can lead to rework and frustration. Thoughtful, deliberate problem-solving builds better developers and better software. Stay Connected: Join the Developreneur Community We invite you to join our community and share your coding journey with us. Whether you're a seasoned developer or just starting, there's always room to learn and grow together. Contact us at info@develpreneur.com with your questions, feedback, or suggestions for future episodes. Together, let's continue exploring the exciting world of software development. Additional Resources One Offs, Side Projects, and Veering From Standards Setting Realistic Expectations In Development The Importance of Properly Defining Requirements Building Better Developers With AI – With Bonus Content

Connect to John Gilroy on LinkedIn   https://www.linkedin.com/in/john-gilroy/ Want to listen to other episodes? www.Federaltechpodcast.com When most of us hear the word “lifecycle,” we normally assume they are talking about the Software Development Lifecycle. Today, we are going to vary that concept and discuss the Contract Lifecycle and its management. It has been recognized as a part of systems management, so it has developed its own abbreviation: Contract Lifecycle Management, or CLM. Our guest is Ryan Donley from Icertis. He highlights the shift from traditional methods like Excel spreadsheets to modern digital platforms. Much like software, the CLM can be divided into pre-award, post-award, compliance, and closeout areas. Every agency oversees this sequence in a unique manner. Ryan Donley points out that some organizations still use Excel spreadsheets for this task. He recommends that people realize that antiquated processes can limit your ability to have accurate information and can cause reporting to be delayed. Further, when a system is automated, coordination between departments is accelerated, and issues like compliance can be acted upon quickly. Icertis operates on a single-tenant GCC high cloud with Microsoft, ensuring security and compliance.

Connect to John Gilroy on LinkedIn   https://www.linkedin.com/in/john-gilroy/ Want to listen to other episodes? www.Federaltechpodcast.com We all know the quote from Peter Drucker, "If you can measure it, you can manage it."   It's pretty easy to apply when throwing a javelin but difficult when measuring success in complex software development projects. Today, we sat down with Jeff Gallimore, Chief Technology and Innovation Officer and founder of Excella. He brings with him decades of experience collaborating with teams on successful federal projects. We start by noting the fallacy of using one metric to measure success. While completing the initiative on time might make an agency administrator happy, that will change rapidly if compliance is not achieved, and scaling will break the system into pieces. Jeff has seen breakthroughs using a framework called DORA, DevOps Research and Assessment). The key metrics are deployment frequency, lead time for changes, change failure rate, and failed deployment recovery time.  These metrics, now part of Google, are research-based and predictive of IT and organizational outcomes. They emphasize the importance of a holistic approach, avoiding single-metric focus, and the role of leadership and culture in fostering high-performing teams

A piece on leadership and teams needed to create great software projects and overcome the organisational immune system, all without any fan noise, and an intro from Mark.Unicorn project bookDevOps handbook (hint, DevOps is *not* a separate team or job title, that's just Ops)Culture - The Fearless Organisation bookMeLE Fanless Mini PC Quieter 4CDead Sea Effect

How do you take advantage of Git pre-commit hooks? How do you build custom software checks and rules that run every time you commit your code? Christopher Trudeau is back on the show this week, bringing another batch of PyCoder's Weekly articles and projects.

Study Finds 268% Higher Failure Rates for Agile Software Projects - DEBUNKED This study is deeply rooted and focused SOLELY on Agile Delivery. After reading the study if 600 participants... And digging deep into what smelled about the report, I came up with a few things that led me to believe that the creator if the study was merely trying to sell a competing product.. How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/

In the world of software development, the difference between a successful project and a frustrating one often boils down to one critical factor: effective requirements gathering. When teams fully understand what they need to build, how it functions, and what the end-user expects, they are much more likely to deliver a product that meets or exceeds expectations. However, when requirements are vague or misunderstood, the project can quickly veer off course. This blog explores the importance of gathering precise requirements, setting clear expectations, and establishing a solid foundation for successful software projects. The Importance of Requirements Gathering At the core of every software project is a set of requirements that defines what the software should do. These requirements serve as the blueprint for the entire project, guiding developers, testers, and stakeholders alike. However, gathering these requirements is not just about listing features and functions. It involves a deep understanding of the problem that the software aims to solve, the users it will serve, and the environment in which it will operate. Effective requirements gathering involves asking the right questions and digging beneath the surface. It's about understanding not just what the client thinks they need but also what they actually need to achieve their goals. This process can be challenging, especially when clients may not be fully aware of the complexities that go into software development. For example, a client may ask for a “simple” feature without realizing the technical intricacies required to implement it. Expectation Setting: Aligning Vision and Reality with Requirements Once the requirements are gathered, the next critical step is expectation setting. This involves aligning the client's vision with the realities of software development. It's about ensuring that everyone involved in the project has a clear and shared understanding of what will be delivered, how long it will take, and what it will cost. Expectation setting is not a one-time conversation. It requires ongoing communication throughout the project to manage changes, address misunderstandings, and ensure that everyone remains on the same page. For instance, if a client envisions a feature that is technically difficult or expensive to implement, it's essential to discuss these challenges upfront. This way, the client can make informed decisions about prioritization, trade-offs, and budget. Level Setting: Establishing a Common Ground Alongside expectation setting, level setting is another crucial aspect of a successful project. Level setting ensures that all team members, from developers to stakeholders, have a shared understanding of the project's scope, objectives, and constraints. This process helps prevent misunderstandings and miscommunications that can derail a project. Level setting often involves creating detailed documentation. This can be a project charter or scope statement, which outlines the project's goals, deliverables, timelines, and responsibilities. By establishing this common ground early on, teams can work more efficiently and collaboratively. This also helps reduce the risk of costly revisions or delays later in the project. Avoiding Common Pitfalls Even with the best intentions, software projects can encounter pitfalls if requirements gathering, expectation setting, and level setting are not handled correctly. One common issue is assumption-based development, where developers assume they understand what the client wants without verifying these assumptions. This can lead to significant rework and frustration when the delivered product does not meet the client's needs. Another pitfall is scope creep. This is where additional features or changes are introduced without proper evaluation of their impact on the project. This often occurs when requirements are not clearly defined or when expectations are not properly managed. To avoid these issues, it's essential to maintain strict control over the project's scope and ensure that any changes are carefully considered and documented. The Path to Successful Software Projects and Requirements Successful software projects are built on a foundation of clear, well-defined requirements, realistic expectations, and a shared understanding among all stakeholders. By focusing on these critical aspects of project management, teams can reduce the risk of misunderstandings, delays, and costly revisions. Effective requirements gathering is not just a step in the process. It is the cornerstone of delivering a product that truly meets the client's needs and expectations. In the end, getting it right from the start is the key to successful software development. Stay Connected: Join the Developreneur Community We invite you to join our community and share your coding journey with us. Whether you're a seasoned developer or just starting, there's always room to learn and grow together. Contact us at info@develpreneur.com with your questions, feedback, or suggestions for future episodes. Together, let's continue exploring the exciting world of software development. Additional Resources Software Development Requirements: Staying True to Specifications The Importance of Properly Defining Requirements Changing Requirements – Welcome Them For Competitive Advantage Creating Use Cases and Gathering Requirements The Developer Journey Videos – With Bonus Content

In this episode, we provide a comprehensive step-by-step guide for small businesses on how to take a software project from concept to launch, ensuring successful outcomes. Ricardo Cimmino shares invaluable insights and practical advice drawn from years of experience in the industry. He'll discuss topics such as: Defining Clear Objectives: Understanding the importance of setting […] The post Successfully Launching Software Projects, With Ricardo Cimmino first appeared on Business Creators Radio Show with Adam Hommey.

We are in the bag with the second half of our gargantuan Your Sinclair Top 100.  In this episode Drisky and Kingy countdown from 50 to 1.     The games covered in this episode are:- 50 Enduro Racer - 1987 - Activsion  sega https://spectrumcomputing.co.uk/entry/1628/ZX-Spectrum/Enduro_Racer 49 Tetris - 1988 - Mirrorsoft https://spectrumcomputing.co.uk/entry/5212/ZX-Spectrum/Tetris   48 Renegade - 1987 - Renegade https://spectrumcomputing.co.uk/entry/4082/ZX-Spectrum/Renegade   47 Antics - 1984 - Bug byte https://spectrumcomputing.co.uk/entry/537/ZX-Spectrum/Antics   46 Bobby Bearing - 1986 - The Edge https://spectrumcomputing.co.uk/entry/606/ZX-Spectrum/Bobby_Bearing   45 International Match Day - 1986 - Ocean https://spectrumcomputing.co.uk/entry/2514/ZX-Spectrum/International_Match_Day 44 Rescue - 1987 - Mastertronic https://spectrumcomputing.co.uk/entry/4110/ZX-Spectrum/Rescue   43 Midnight Resistance - 1990 - Ocean data east https://spectrumcomputing.co.uk/entry/3188/ZX-Spectrum/Midnight_Resistance 42 The Hobbit - 1982 - Melbourne House https://spectrumcomputing.co.uk/entry/6440/ZX-Spectrum/The_Hobbit 41 Fantasy World Dizzy - 1989 - Codemasters https://spectrumcomputing.co.uk/entry/9335/ZX-Spectrum/Fantasy_World_Dizzy   40 Highway Encounter - 1986 - Vortex Software https://spectrumcomputing.co.uk/entry/2323/ZX-Spectrum/Highway_Encounter 39 Mercenary - 1987 - Novagen https://spectrumcomputing.co.uk/entry/3126/ZX-Spectrum/Mercenary   38 Gauntlet - 1986 US GOLD https://spectrumcomputing.co.uk/entry/1989/ZX-Spectrum/Gauntlet   37 Lode Runner - 1984 software projects https://spectrumcomputing.co.uk/entry/2912/ZX-Spectrum/Lode_Runner 36 Cybernoid - 1988 - Hewson https://spectrumcomputing.co.uk/entry/1196/ZX-Spectrum/Cybernoid 35 I, Ball 2: Quest for the Past - 1987 - Firebird https://spectrumcomputing.co.uk/entry/2431/ZX-Spectrum/I_Ball_II 34 Deus Ex Machina - 1984 - Automata https://spectrumcomputing.co.uk/entry/1373/ZX-Spectrum/Deus_Ex_Machina   33 Knight Lore - 1984 - Ultimate https://spectrumcomputing.co.uk/entry/9366/ZX-Spectrum/Knight_Lore 32 Jet Set Willy - 1984 - Software Projects https://spectrumcomputing.co.uk/entry/2589/ZX-Spectrum/Jet_Set_Willy   31 Lunar Jetman - 1983 - Utlimate https://spectrumcomputing.co.uk/entry/9372/ZX-Spectrum/Lunar_Jetman   30 Nebulus - 1987 - Hewson https://spectrumcomputing.co.uk/entry/3377/ZX-Spectrum/Nebulus   29 Think! - 1985 - Arioloasoft https://spectrumcomputing.co.uk/entry/5235/ZX-Spectrum/Think   28 Deactivators - 1986 - Reaktor https://spectrumcomputing.co.uk/entry/1278/ZX-Spectrum/Deactivators 27 Super Hang-On - 1987 - Electric Dreams https://spectrumcomputing.co.uk/entry/5019/ZX-Spectrum/Super_Hang-On   26 Light Force - 1986 - FTL https://spectrumcomputing.co.uk/entry/2882/ZX-Spectrum/Lightforce   25 Manic Miner - 1983 - Bug Byte https://spectrumcomputing.co.uk/entry/3012/ZX-Spectrum/Manic_Miner 24 3D Starstrike 2 - 1986 - Realtime Games Software https://spectrumcomputing.co.uk/entry/4881/ZX-Spectrum/Starstrike_II   23 The Great Escape - 1986 - Ocean https://spectrumcomputing.co.uk/entry/2125/ZX-Spectrum/The_Great_Escape 22 Chase H.Q. - 1989 - Ocean https://spectrumcomputing.co.uk/entry/903/ZX-Spectrum/Chase_HQ 21 Alien - 1984 - Mind games/Argus Press https://spectrumcomputing.co.uk/entry/145/ZX-Spectrum/Alien 20 Spy vs. Spy - 1985 - Beyond Software https://spectrumcomputing.co.uk/entry/4786/ZX-Spectrum/Spy_vs_Spy   19 Back to Skool - 1985 - Microsphere https://spectrumcomputing.co.uk/entry/362/ZX-Spectrum/Back_to_Skool 18 Underwurlde - 1984 - Ultimate https://spectrumcomputing.co.uk/entry/9446/ZX-Spectrum/Underwurlde   17 Starquake - 1985 - Bubblebus https://spectrumcomputing.co.uk/entry/4873/ZX-Spectrum/Starquake   16 Elite - 1985 - Firebird https://spectrumcomputing.co.uk/entry/1601/ZX-Spectrum/Elite 15 Lords of Midnight - 1984 - Beyond Software https://spectrumcomputing.co.uk/entry/6604/ZX-Spectrum/The_Lords_of_Midnight https://www.icemark.com/tower/manual/guide.htm 14 Ant Attack - 1983 - Quicksilva https://spectrumcomputing.co.uk/entry/210/ZX-Spectrum/Ant_Attack   13 Chuckie Egg - 1983 - AnF software https://spectrumcomputing.co.uk/entry/958/ZX-Spectrum/Chuckie_Egg 12 Carrier Command - 1989 - Rainbird https://spectrumcomputing.co.uk/entry/825/ZX-Spectrum/Carrier_Command 11 Sim City - 1990 - Infogrames https://spectrumcomputing.co.uk/entry/4509/ZX-Spectrum/Sim_City   10 T.L.L. 1984 - Vortex https://spectrumcomputing.co.uk/entry/5302/ZX-Spectrum/TLL   9 Boulder Dash - 1984 - Front Runner - First Star https://spectrumcomputing.co.uk/entry/639/ZX-Spectrum/Boulder_Dash 8 Rainbow Islands - 1990 - Ocean https://spectrumcomputing.co.uk/entry/724/ZX-Spectrum/Rainbow_Islands   7 The Sentinel  - 1987 - Firebird https://spectrumcomputing.co.uk/entry/4400/ZX-Spectrum/The_Sentinel   6 R-Type - 1988 - Electric Dreams Software https://spectrumcomputing.co.uk/entry/4256/ZX-Spectrum/R-Type   5 Head over Heels - 1987 - Ocean https://spectrumcomputing.co.uk/entry/2259/ZX-Spectrum/Head_over_Heels 4 Stop the Express - 1983 - Hudson/Sinclair Research https://spectrumcomputing.co.uk/entry/4916/ZX-Spectrum/Stop_the_Express 3 All or Nothing - 1984 - Abbex Electronics Ltd https://spectrumcomputing.co.uk/entry/167/ZX-Spectrum/All_or_Nothing   2 Rebel Star - 1986 Firebird https://spectrumcomputing.co.uk/entry/4058/ZX-Spectrum/Rebelstar   1 Deathchase - 1983 - Micromega https://spectrumcomputing.co.uk/entry/1303/ZX-Spectrum/Deathchase   Show notes: The Hobbit 128K version: https://spectrumcomputing.co.uk/entry/30399/ZX-Spectrum/Hobbit_128 Deus Ex Machina on Steam https://store.steampowered.com/app/508910/Deus_Ex_Machina_Game_of_the_Year_30th_Anniversary_Collectors_Edition/ Lunar Jetman - the FAKE trailer http://www.carlylesmith.karoo.net/spectrum/gamefaq/gamefaq6.html Bill Barbison interview by RGDS https://retrogamingdailyshow.libsyn.com/171-an-interview-with-bill-harbison Bob Pape's excellent making of R-Type conversion for the Spectrum https://bizzley.42web.io/?i=1   Our interview with Jon Ritman https://retrogamingdailyshow.libsyn.com/213-the-john-ritman-interview    

Join Matt Watson and Alex Polyakov, CEO of Project Simple, as they talk about manage software projects. Listen to their entertaining discussion about conflicts between product development and engineering needs. Gain insights into effective productivity tracking and strategies for market persuasion. Plus, unravel the complexities of technical debts.     Find Startup Hustle Everywhere: https://gigb.co/l/YEh5   This episode is sponsored by Full Scale: https://fullscale.io   Learn more about Project Simple: www.projectsimple.aiSee omnystudio.com/listener for privacy information.

Some thoughts on the different ways you can run an open source software project, comparing projects like password-store, which are based on a mailing list and use a minimal forge platform, and others that are based on a fancy forge like Github. I think the fancy forge gives the open source software project a vibe that we're more used to, in our capitalist society. It's a more centralized structure that feels more like a service that's being offered to the public, mostly in one direction. Meanwhile software projects that don't have a platform for creating road maps, issues, pull requests etc actually foster a stronger and more open community structure, rather counter-intuitively, because the software is free and everyone is able to contribute and modify the software for their own use, and they in fact do. The idea of a canonical version of the software is only a convenience, not a defining feature of it. Let me know your thoughts on this.

Jay Harris is a speaker, software consultant, and owner of Arana Software. He has been developing on the web since 1995, when the Blink tag lured him away from Visual Basic 3, and has been awarded as a Microsoft Regional Director, ASPInsider, and Microsoft MVP. Recognizing that the greatest application performance bottleneck is a developer's time, Jay's continuing quest is for frameworks, modules, tools, and practices that make developers stronger, fitter, happier, and more productive.   Jay resides in Las Vegas, USA. Follow him on Twitter at @jayharris.   Topics of Discussion: [3:40] Jay gives a shout-out to a phenomenal manager, Larry, who had a profound impact on his career. [5:30] Advice for managing burnout in software development teams. [7:16] The importance of learning how to say no. [10:19] Respecting team limits and honoring downtime is crucial for long-term success. [16:06] Maintaining software team velocity through play and downtime. [18:23] The key to sustainable software delivery is collaboration, compromise, and empowering teams to be self-sufficient. [23:28] Pain points in user interfaces. [30:39] Overcoming the challenges of working with PDFs. [36:49] Jay walks us through the typical code flow.   Mentioned in this Episode: YARP Clear Measure Way Architect Forum Software Engineer Forum Programming with Palermo — New Video Podcast! Email us at programming@palermo.net. Clear Measure, Inc. (Sponsor) .NET DevOps for Azure: A Developer's Guide to DevOps Architecture the Right Way, by Jeffrey Palermo — Available on Amazon! Jeffrey Palermo's Twitter — Follow to stay informed about future events! Jay Harris on Distributed DevOps Glenn Burnside Managing Developers   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.

What is the most time consuming part of software projects?

Are you struggling to find the perfect systems integrator or software partner for your business? Look no further! Join us as we chat with Bonnie, founder and CEO of Raven Intelligence, a peer review site dedicated to helping decision-makers select the best partners for their software projects. Bonnie offers her expert insights on customer reviews, the importance of vetting potential partners, and how to choose the right fit for your enterprise.In our conversation, we dive into the data and explore how customer reviews in Q1 can be leading indicators for future budgeting. Bonnie also discusses the impact that system integrators can have on software companies and how a great experience can bring positive results. We then turn our attention to the crucial process of choosing a software implementation partner, discussing key questions to ask and how to navigate situations where a vendor has a preferred partner.Finally, Bonnie shares how Raven Intelligence can help you make an informed decision when selecting the right partner for your needs. Learn how to ask pointed questions and use customer feedback to back up your partner's claims. Discover the importance of doing your homework, trusting and verifying, and finding a partner with matching experience. Don't miss this enlightening conversation with Bonnie from Raven Intelligence as we explore the world of software reviews and integrators.Listen & Subscribe on your favorite platformApple | Spotify | Google | AmazonVisit us at RecruitingDaily for all of your recruiting, sourcing, and HR content.Follow on Twitter @RecruitingDaily Attend one of our #HRTX Events

https://mimetype.app/The Mom Test: https://www.amazon.com/The-Mom-Test-Rob-Fitzpatrick-audiobook/dp/B07RJZKZ7Fmeier.shMy Book - Foundations of High Performance Reactthereactshow.comhttps://twitter.com/TheReactShowMusic by DRKST DWN: https://soundcloud.com/drkstdwnThe Investor Friendly Real Estate AgentWelcome to the Investor Friendly Real Estate Agent Podcast where we look at real...Listen on: Apple Podcasts SpotifySupport the show

In this episode we cover "How to Lead a Project - as a Software Engineer" by Gergely Orosz. This is a practical, step-by-step guide on crushing the soft-skills portion of a project. We cover how to set a good foundation of communication, how to effectively manage risk, best practices for updates, and a whole lot more. No matter what level you are in your career, following this guide for your next project (big or small) will definitely set you apart as an effective leader. We get back to our roots and deliver some new learning and some great news to sail away on. Also, we are still tinkering with our into and outtro...so we're sorry about that. As always, visit Runtime Rundown to drop us a suggestion, listen, and comment on episodes. Thanks for listening!

Join our resident Business Ninja Andy together with the CEO of Kwan Technologies Daniel Castaneda, as they talk about staffing and recruitment that specializes and focuses in providing Latin American Software Engineers as Staff Augmentation to US tech firms, and focuses on nearshore outsourcing and software projects. They provide the profiles of the Software Engineers you are looking to hire and do the recruitment for you and provide suitable Engineers, who then integrate full-time into your team from their offices in Merida, Mexico. Find out more about them and their services by visiting their website at https://www.kwantec.com/.-----Do you want to be interviewed for your business?  Schedule time with us, and we'll create a podcast like this for your business:  https://www.WriteForMe.io/-----https://www.facebook.com/writeforme.iohttps://www.instagram.com/writeforme.io/https://twitter.com/writeformeiohttps://www.linkedin.com/company/writeforme/https://www.pinterest.com/andysteuer/Want to be interviewed on our Business Ninjas podcast? Schedule time with us now, and we'll make it happen right away! Check out WriteForMe, more than just a Content Agency! See the Faces Behind The Voices on our YouTube Channel!

Every software project is subject to a series of decisions and tradeoffs. One of the first decisions to make is which programming language to use. For companies where their product is software, this is a decision that can have significant impact on their overall success. In this episode Sean Knapp discusses the languages that his team at Ascend use for building a service that powers complex and business critical data workflows. He also explains his motivation to standardize on Python for all layers of their system to improve developer productivity.

Nikhil Krishna speaks to Bob DuCharme an experienced technical writer and author about how to write and maintain technical documentation for software products. In the episode different mediums to distribute documentation and tools to maintain documentation are discussed.

The Big Themes:• Setting clear project goals and timelines: This will help you measure your progress. Without clear goals and success metrics, it will be difficult to understand if you are on right track.• Make sure you have leadership buy-in: It's important to get these individuals on board. Leadership support can also ensure you have the right resources.• Select the right consulting partner: They wish they did more research on their consulting partner instead of simply using the first partner that their software vendor recommended.• How to recover: Identify what is happening in real-time and isolate the specific points of failure. Assess the impact on your project and organization.The Big Quotes:“So who knows where the next wave of technology will take us.”“Well, like the age old question, how do you eat an elephant? It's like one bite at a time.”“You want a partner who's not going to bait and switch you and give you wrong the team during the selection process.”This episode is brought to you by BMC Software.

On this week's episode of Business & Beers we chat with Jacques du Toit. Jacques shares his story from running his side hustle publication and textbook business called BookIt Books while being a full-time student at University of Pretoria. He shares his story of how the business was started by a massive gap in the market and we get introduced to ‘Mr Chang' who re-enforced the idea of the business. He goes into his story of being a natural explorer at heart, what drives him to succeed, how does he solve problems and identify gaps in the market with a passion for property. He was 1 of the first handfuls of properties to start an Airbnb in Cape Town with his mother's house that turned into other properties that he started managing. But with Jacques's passion and drive it was only time before he moved into his new venture of going into consulting and working with an international firm on systemizing the business and he discusses what he learnt along this new journey and how the relationships he built in that business led to his own consulting business called Source Consulting. Jacques's story is really inspiring to show what you can achieve with drive and passion and being able to be agile in identifying gaps in the market and chasing the opportunity. Jacques shares some interesting tips with our listeners that he has learnt along his journey: 1. Keep costs low which allows you to survive most storms. 2. Personal productivity and health must be a priority, get enough sleep. 3. Value your clients and your suppliers 4. Time blocking. “In the morning usually 2 hours my phone is off, and I do priority work with no distractions”. Follow Jacques on the below channels: LinkedIn o https://www.linkedin.com/in/jacques-du-toit/ Website o https://jacquesdutoit.com/ BookIt Books o https://www.bookitbooks.co.za/ ZA Homes o https://zahomes.co.za/ Source Consulting o https://sourceconsulting.co.za/#

In this episode, Andrew Rivers from 345 Technology is joined by Steve Pereira from Visible Value Stream Consulting - https://visible.is - talking about agile, lean and finding value in software projects.

Tim Ottinger has four questions that work great in many situations, from doing homework, to cooking, to writing code, to entire software projects. They are actually awesome questions to ask during a software project. We discuss the questions, where they came from, and look at some uses in software. The questions: What is it that needs to be done? What do we need in order to do it? Where can we get what we need? How can we tell if we’re doing it right? Bonus question that can be swapped out for #1: What's the most important thing that it doesn't do yet? Special Guest: Tim Ottinger.

Retainer Models For Technology And Custom Software Projects - Surge #116 Learn how monthly E-Commerce Custom Software maintenance retainers work and how these service retainers help you get more efficient. Move fast with low-cost monthly retainers for B2B Software Projects.

This week, the crew sits down to talk about interviewing, both from the side of the interviewer and from the side of interviewee. What are we looking for? What are the red flags? What kinds of questions should we be asking? Are we putting too much faith in the sanctity of the interview process? And, why the heck does Zappos offer to pay you $2,000 not to work there ( https://www.businessinsider.com/zappos-tony-hsieh-paid-new-workers-to-quit-the-offer-2020-11 ) ?! This discussion is particularly insightful because Carol shares her perspective as a female which includes things most men will have never considered. For example, did you know that you can ask ahead of time who will be interviewing you? And, that it's even OK to ask for a woman to be present on the interview panel? This underscores the importance of creating and hiring for a diverse team: everyone's perspective is different; and, everyone's perspective is valuable. And, when we only hire people that look and act like us, we only see the human experience through a small window. Each week, our top Patreon supporters get a sponsored shout-out. And, today's shout-out goes to Girls Who Code ( https://girlswhocode.com/ ) , an organization who's mission it is to close the gender gap in technology and to change the image of what a programmer looks like and does. Triumphs & Failures ------------------- * Adam's Triumph - In 2014, he wrote REST Assured ( https://restassuredbook.com/ ) , a no-nonsense ebook about architecting RESTful APIs. Now in 2021 - by popular demand - this digital work is finally coming to a paperback near you! And of course, we're all demanding signed copies! * Ben's Failure - this past week just left him feeling destroyed. Between the "Spring forward" clock change, an absurd number of meetings, and the abysmal performance of his ColdFusion custom tag DSL inside a Docker container, this whole week has felt like a kick in the gut. Not every week is going to be a winner; and, he just hopes that next week is better! * Carol's Triumph - she bought a daily-planer to help her keep track of what she's done today ; and, what she needs to get done tomorrow. Part optimization, part self-care, writing everything down allows her to see a clear record of what she's accomplished; which, in turn, allows her to embrace her own success and feel good about stepping away from her desk when she needs to take a break. * Tim's Triumph - his plan is really coming together! After months-and-months of consulting with customers, writing business plans, organizing marketing campaigns, collecting testimonials, obtaining budgets, running things by Legal, and working with Quality Assurance (QA), all the pieces are falling into place. And, for him, it's been a truly humbling experience. As engineers, we can be lulled into thinking that we are the center of the universe ; but, when one see just how many people are involved in bringing a product to market, it becomes clear that we are just small cogs in a massive, harmonious machine. Notes & Links ------------- * The MEGA Interview Guide ( https://github.com/danieldelcore/mega-interview-guide ) - a humble guide to give developers the tools they need to nail technical interviews! * Awesome Interview Questions ( https://github.com/DopplerHQ/awesome-interview-questions ) - a curated list of lists of technical interview questions. * Cracking the Coding Interview ( https://github.com/careercup/CtCI-6th-Edition ) - the 6th edition of the book's crowd-sourced solutions guide. * MOVA ( https://www.theregister.com/2021/03/10/fake_mova_programming ) - a fake programming language created to help weed-out nefarious recruiters and engineers. * How to Deal with Difficult People on Software Projects ( https://www.howtodeal.dev/ ) - a breakdown of different work personalities and how to work effectively with them. Follow the show! Our website is workingcode.dev ( https://workingcode.dev/ ) and we're @WorkingCodePod on Twitter ( https://twitter.com/WorkingCodePod ) and Instagram ( https://www.instagram.com/workingcodepod/ ). New episodes weekly on Wednesday. And, if you're feeling the love, support us on Patreon ( https://www.patreon.com/workingcodepod ).

Seasoned developer Kris Hofmans joins us to discuss why it is that many (or is it most?) software projects suck. We touch on topics such as budgets, (in)competencies, accountability, documentation, testing (or the lack thereof!).

Robby speaks with John Cech, Senior Ruby on Rails Engineer at Planet Argon. They discuss examples of technical debt, how John catapulted his professional development via mentoring, and the benefits of having consistent coding conventions as a team. John also talks about how he helped a software project increase test coverage while also reducing the speed to run them.Helpful LinksMore About John[Book Recommendation] 1Q84, Haruki Murakami Subscribe to Maintainable on:Apple PodcastsOvercastSpotifyOr search "Maintainable" wherever you stream your podcasts.

Quick meditation to listen to the stress center of our body and give it a thank you for all it does for us, but we are good without it freaking out all the time!!

Vita and I discuss her experience as an engagement manager, dealing with customers and developers and advocating for both. We also talk about common hangups and changes in software projects and the things customers and developers should know when dealing with each other. Vita is a gem and can be reached from the Inoxoft homepage https://inoxoft.com/ --- Send in a voice message: https://anchor.fm/remote-software-genius/message

It is inevitable: open source is how we will be developing software in the future. Nobody will pay for software, but only for services around it. You have to join this new market as soon as possible. The video is here: https://youtu.be/JBdtSAJjFaU

How can we avoid miscommunications between technical and non-technical people that cause software projects to fail? Software engineer and entrepreneur Morgan Lopes is here to help us try and figure it out.

Talking about digital transformation to an Microsoft community audience is a little like talking about gold medals to Olympic athletes. They all understand, they have all heard it a hundred times before. But few have a good chance to reach the goal. Fortunately, strategic IT is not a winner-take-all sport, and our returning guest for this episode, Guus Krabbenborg of Dynamics and More, has been spreading the message that all organizations have the opportunity to transform by shifting their thinking, re-focusing some IT priorities, and demanding a different kind of relationship with their technology partner. Guus has a new book that tackles these challenges. We dive into Guus's motivation to create the book and his experiences in the last few years that shaped his message to customers and partners. Show Notes: 2:30 - Guus's outlook on digital transformation broadly 6:45 - Executive sponsorship and the tension between IT projects, strategic vision, and responsibility for success 11:45 - Why companies must refocus on their customers and engineer their business model accordingly 14:00 - The challenge of having a conversation with executives vs IT, and how Microsoft partners can do better 17:00 - Should partners try to be both strategic and tactical? Would they be better off breaking apart these duties? 21:45 - Why change is so difficult for Dynamics partner organizations 25:30 - How do you encourage clients to take action? 30:00 - Guus's new book and his reasons for writing it 36:00 - An alternative book sales model 40:00 - How will Microsoft and partners address the topic of modernizing their ERP methodology guidance   LinkedIn: https://www.linkedin.com/in/guuskrabbenborg/ Email: gk@dynamicsandmore.com

In this episode, we're discussing the main differences between mobile and web development, the unique challenges of developing mobile apps, the main ideas behind Mobile DevOps, and the tools, processes, and technologies that can help teams adopt this new culture. Today's guest: Vladimir Ivanov, Solutions Architect at EPAM Systems from Saint Petersburg, Russia Hosts: Anna Bátki and Nóra Bézi from Bitrise Follow Vladimir on Twitter: https://twitter.com/vvsevolodovich?lang=en References: The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win by Gene Kim, Kevin Behr, and George Spafford Waltzing With Bears: Managing Risk on Software Projects by Tom Demarco Liquid Software: How to Achieve Trusted Continuous Updates in the DevOps World by Fred Simon, Yoav Landman, and Baruch Sadogursky Site Reliability Engineering: How Google Runs Production Systems by Niall Richard Murphy, Betsy Beyer, Chris Jones, and Jennifer Petoff Mobile People Talks podcast (in Russian): https://soundcloud.com/mobilepeopletalks Follow us on Twitter: https://twitter.com/bitrise

Today we’re breaking away from our typical Thoughtful Software Podcast format and going a little more technical. Experts in the tech industry, Andrew and Fahad, have compiled their top reasons as to why Software Projects Fail. This is a huge issue because software projects are costly and have a high failure rate. Here at Skiplist, we want to bring a thoughtful perspective to the way we build software for our clients and focus on the positive impact thoughtfully built software can have on society. We hope you enjoy this episode. Let’s go through the top 10 reasons why software projects fail.

If you’re like most software engineers and, especially, data scientists, you find it really hard to make accurate estimates of how long a project will take to complete. Don’t feel bad: statistics is most likely actively working against your best efforts to give your boss an accurate delivery date. This week, we’ll talk through a great blog post that digs into the underlying probability and statistics assumptions that are probably driving your estimates, versus the ones that maybe should be driving them. Relevant links: https://erikbern.com/2019/04/15/why-software-projects-take-longer-than-you-think-a-statistical-model.html

Video is here: https://www.youtube.com/edit?video_referrer=watch&video_id=IqnbG826Oyc

Host Jemma Cawood is joined by ROQ co-founder Mark Bargh to discuss the seven ingredients to successful software releases. Mark suggests that these areas have been ever-present for most people within the industry for a long time, but there seems to be little structure around them. He worked with his team to come up with seven questions which should be being asked by the person at the top prior to a project going live – giving us seven areas to focus on throughout the project and ensures that nothing surprises us at the last minute. The areas which he suggests should be focused on throughout the project to ensure stakeholders will have enough information to make a go live decisions are; functional readiness, performance, security, business readiness, operational readiness, data migration and implementation planning. Mark shares stories where a lack of attention in these areas has caused difficulties for the project as well as tips for success. He suggests that as testing professionals we need to lift our head up and assist the project and programme manager in looking to move towards those project outcomes. Mark encourages people not to get drawn into silos of activity, to raise your head, consider the overall project outcomes and don’t be afraid to make your voice heard if you feel that some areas are being neglected. You can find out more details on the services which ROQ offer and learn more about these seven areas by visiting their website: www.roq.co.uk

Sure, progress seems like an innocent thing to measure. *rolls eyes*

Programming Languages and Communication With Kerri Miller TableXI is now offering training for developers and products teams! For more info, email workshops@tablexi.com. Get your FREE career growth strategy information and techniques! (https://stickynote.game) Rails 5 Test Prescriptions (https://pragprog.com/book/nrtest3/rails-5-test-prescriptions) is updated, available, and shipping! Guest Kerri Miller (https://twitter.com/kerrizor): Senior Developer at TravisCI (https://travis-ci.org/) and Ruby Community Member. Co-Organizer of the Open Source and Feelings Conference (https://www.osfeels.com/). Blog (http://kerrizor.com/). Summary Why is Smalltalk the Elizabethan English of programming languages? Why has it been so influential, and how does the programming language you use affect the way you think about programming. On this episode, Kerri Miller and I talk about programming languages and communication, and what we've learned from our most recent programming language adventures. Notes 01:56 - Introduction Twitter Stream (https://twitter.com/kerrizor/status/974391130484752385) Creole Languages (https://en.wikipedia.org/wiki/Creole_language) Pidgin (https://en.wikipedia.org/wiki/Pidgin) 06:18 - SmallTalk is to Ruby as Elizabethan English is to Modern Day 08:11 - SmallTalk’s History Dealers of Lightning: Xerox PARC and the Dawn of the Computer Age (https://amzn.to/2JxTtss) Squeak (http://squeak.org/) By the way, I did get the Squeak history partially wrong. The original work was done at Apple, and when they went to Disney after that, they downloaded their Apple work as Open Source to continue. (It is possibly named Squeak because they were being wooed by Disney). The technical details are basically right, though. 17:55 - Thinking About Programming and Software Projects in a Flexible Way Sapir-Whorf Hypothesis (http://www.dictionary.com/browse/sapir-whorf-hypothesis) 22:01 - Object-Oriented Programming, Thinking, and Design The Overton Window (https://en.wikipedia.org/wiki/Overton_window) 28:37 - Learning New Programming Languages, Concepts, and Techniques The Silmarillion by Tolkien (https://en.wikipedia.org/wiki/The_Silmarillion) Nothing is Something by Sandi Metz (https://www.youtube.com/watch?v=OMPfEXIlTVE) Much Ado About Naught by Avdi Grimm (http://www.virtuouscode.com/introduction-to-much-ado-about-naught/) Related Episodes Back in the Testing Weeds with Sam Phippen and Justin Searls (http://www.techdoneright.io/33) Ruby Tapas and Avoiding Code with Avdi Grimm (http://www.techdoneright.io/24) The Elm Programming Language With Corey Haines (http://www.techdoneright.io/17) Special Guest: Kerri Miller.

Do your projects move forward with many assumptions that turn out to not be true as things progress? Today I'd like to share how learning of a team failure produces better software when you plan to exploit this ability. The overall assumption that most projects operate under is that the project will be successful. However there are several smaller assumptions upon which this one is built. Often these smaller assumptions need to be verified to make decisions that keep the overall state of progress moving in a sustainable direction for the product. Assumptions About The Skill Of The Team If the team isn’t as skilled as assumed, projects will take significantly longer and more brittle to change. Assumptions About The Quality Of The Release If the team hasn’t put the appropriate quality checks in place, changes assumed to have a certain level of quality that don’t cause rework. Assumptions About Full Understanding Of Scope If the team is assuming requirements are complete, they look at scope change as failure. Assumptions About Value Of Features & Changes If the team is assuming changes being released are valuable to customers, but there aren’t measurable ways to know whether that’s true, waste could be being released. Doing Less At One Time Is THE KEY To Learning Through Failure Overall, the key to learning that we’ve “failed” in some way and need to adjust direction based on what we’ve learned FASTER is to do less at one time! Doing Less Between Releases Minimizes Risk If we make a mistake to a small change, the impact of that change should be smaller than releasing a large change. This minimizes the impact of rework or breakages. Doing Less Between Releases Motivates Realignment If a team iterates on a backlog that hasn’t been significantly changed since the project starts; the business has low motivation to realign. If a team is taking action on the feedback of rapid releases, the business must be more responsive. Doing Less Between Releases Improves ROI For every day that development continues without a release, there’s no return on investment. By releasing more frequently, the team has the opportunity to provide value to the customer with less capital. Doing Less Between Releases Improves Skill If we do a production release every 6 months, how good are people going to be at it? Doing less between releases forces the entire team to practice release practices more often. This results in a team with higher delivery skill. Fail Faster By Having Artifacts That Provide Feedback Having tools and processes that give us the state of a change at any time lets people know a failure to some process has occurred early. This enables people to take action on issues as they emerge and catch them before the change makes it out to customers. Fail Faster By Using Cross Functional Teams The lag time that occurs between separate departments for disciplines needing something and sub-contracting “as a service” causes releases to take longer. If we want to fail faster, we need to have all the people needed to release the product dedicated to it and working together so there is no lag time to service outside of the immediate group. Fail Faster By Holding Retrospectives Have a meeting to talk about what went well and what didn’t over the past release (Scrum) or several releases (Kanban). This is an easy way to learn earlier that the team is failing to follow processes that are working for the project. Fail Faster By Releasing To A Limited Audience Rather than learning that there’s an issue with a release from a large number of voices from your customer base, have a system in place to release to only a small subset of total customers. This is known as ring releasing or canary releasing. Fail Faster By Having a Measurable Pass/Fail Many projects release a large number of features. If some KPI changes positively, it is difficult then to know which of those features or changes caused the positive change. Use A/B testing to verify that investments actually impacted a KPI. Fail Faster By Focusing On Valuable Outcomes Most projects have a large number of features. Rather than keeping everyone busy “burning down” a large list, figure out how much money the business is losing by NOT having each story (cost of delay). Work on the highest cost of delay ideas with FOCUS since those are the most economically viable! Fail Faster With Justin-In-Time Scoping If a team does detailed requirements on a large quantity of work, it creates psychological attachment and wastes money. Teams should instead only get the details of the top items on the list periodically. Fail Faster With Monthly Budgeting If we assume that we’ll learn we need to change what’s built every release, we need to re-budget every release with project % complete accounting. Rather, budget monthly to provide the capital needed to take action on changes to customer needs with less pain. You can also watch this episode on YouTube.  Related resources: How To A/B Software Development To Find What Customers Value   Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

Do you want to help the other people that work with you so they are more fulfilled, and get an opportunity to inspire them? Motivations To Consider Let’s start with some of the motivations I think it’s important to consider if you want to go about servant leadership. Improve Quality Of Delivery Ultimately, however you serve people still needs to result in improving the quality of delivery. While we’ll focus on how to be a servant leader on software projects by serving the needs of others, this fact is important to still keep front and center. Support Career Goals Of Colleagues As you go about serving others, you might adopt a motivation to see others’ careers advance. This doesn’t mean you stop caring about what happens to you, but that you share the burden for those around you being recognized. You Don’t Need A “Leadership” Title You don’t need an “official” leadership title to be a servant leader on software projects. You may be the boss of your colleagues already or not, either way, the goal is to inspire and help others – regardless of your job title. Don’t Rely On Skills To Inspire As you attempt to lead others by serving them, you may need to shift from relying on demonstrating how skilled you are as a primary motivator. Instead, utilize some of the other tips in this video to be a servant leader. Avoid “Siding” With Individuals Be wary of siding with individuals. Do whatever you can do to avoid being sucked into political games, or disputes between people on your team. This doesn’t mean to not have empathy – far from it, empathy is crucial. Rather, don’t be an ear to lend when someone wants to criticize someone else and join in on it with them. Detach From Personal Advancement You may find detaching from your personal advancement helpful if you want to be a servant leader on software projects. The moment you start considering whether your efforts are advancing your own career, conflict can arise that makes it harder to take altruistic actions. Tips For Better Servant Leadership So what are some of the things you could start doing immediately to demonstrate your desire to be a servant leader? Show More Than You Tell The first thing I’d recommend is to show more than tell. When you delegate work or information to others, taking the time to show them how its done will go further than just conveying the steps. You won’t always be able to do this, but err on the side of demonstration whenever possible. Get To Know Colleagues Personally Next I’d recommend you get to know your colleagues personally. More than just what technical or other work related skills they prefer, get to know what makes them tick personally. This will make it easier to support them and their needs and desires. Organize Opportunities To Socialize If you can organize opportunities to socialize with your immediate group, you will show your colleagues that you care about them as people and are willing to share of yourself outside of work. Don’t rely on company happy hours and events as the sole way for your immediate colleagues to get together. Recognize Individual Contributions It’s important to recognize individual contributions, and not attribute them always to the entire team. When providing status or communicating “wins” of the team, put a name to each gain and give props freely to those who did the work. Advocate For Solutions To Colleagues’ Pain Listen for pain and advocate for solutions. If you get to know your colleagues personally, they will share their struggles and whatever you can do to ease it or help shift the burden to someone else will help them be more fulfilled and effective. Advocate For Growth Of Your Colleagues As a servant leader, don’t rely on people with explicit management titles to be the only ones to look out for your colleagues careers. To avoid seeing great people you’ve built good relationships leave, do what you can to remove roadblocks and enable them to grow. If they want to leave because they aren’t getting the opportunities they need, support them in that as well. Get Excess Capacity To Support Serving You will need to negotiate excess capacity in your schedule so you have the time needed to be an effective servant leader. This may be difficult depending on the management style of your organization, but if you can do it – it’s well worth it. Struggle With Them It says more about you when others see how you help during times of stress than when things are going according to plan. Share in the struggles with your team. If you really want to demonstrate the attributes of a servant leader, this is an easy one. Be As Transparent And Open As Possible Though this can be controversial, I believe servant leaders should do what they can to be as transparent with their colleagues as possible. If you wish to serve others above the company, part of that is being open and honest with them about information you know. Do not divulge information you’ve been asked to keep private, as this is being dishonest – but I encourage you to get permission to be as open as possible with your colleagues from whoever you report to if necessary. You can also watch this episode on YouTube.   Visit me at JaymeEdwards.com Find me on Facebook at JaymeEdwardsMedia Find me on Twitter as @jaymeedwards

TP 031: Mathias Burton with ProQuest: Design Process When it Comes to Building Software Projects by Method Matters

Mike Peters is the General Manager of Software Projects, bit it's not a software company. Mike explains this Global Online Retailer selling thousands of software products, ebooks and software services.

02:07 - Pete Hodgson Introduction Twitter GitHub Blog Ruby Rogues Episode #176: Rails as an SOA Client with Pete Hodgson The iPhreaks Show Episodes with Pete Hodgson 03:13 - Feature Toggles, Flags, Bits, Etc. Trunk Based Development iPhreaks Show Episode #136: Efficient Engineering Practices for Software Projects with Neal Ford 06:17 - Merge Hell 08:10 - Branches 08:59 - Why not constantly rebase? Martin Fowler: FeatureBranch 10:48 - Why use feature toggles? Martin Fowler: Feature Toggles 12:29 - Making Code Configurable 16:37 - Approaching Feature Toggles 20:04 - A/B Testing 25:11 - Approaching Feature Toggles (Cont’d) snuffle ambient-spec rack-flags 34:37 - Implications for Testing 36:12 - Toggle Interaction; Nesting of Features 37:28 - Introducing Features Toggles to Teams Pushback 40:43 - Managing Code Reviews with No Feature Branches Picks Cryptic Ruby Global Variables and Their Meanings (Coraline) RailsBridge Installfest (Coraline) Concourse (Pete) Architectural Decision Records (Pete) Pete Hodgson: The Ultimate Traveler's Coffee Kit (Pete) Deschutes Red Chair NWPA (Pete)

02:07 - Pete Hodgson Introduction Twitter GitHub Blog Ruby Rogues Episode #176: Rails as an SOA Client with Pete Hodgson The iPhreaks Show Episodes with Pete Hodgson 03:13 - Feature Toggles, Flags, Bits, Etc. Trunk Based Development iPhreaks Show Episode #136: Efficient Engineering Practices for Software Projects with Neal Ford 06:17 - Merge Hell 08:10 - Branches 08:59 - Why not constantly rebase? Martin Fowler: FeatureBranch 10:48 - Why use feature toggles? Martin Fowler: Feature Toggles 12:29 - Making Code Configurable 16:37 - Approaching Feature Toggles 20:04 - A/B Testing 25:11 - Approaching Feature Toggles (Cont’d) snuffle ambient-spec rack-flags 34:37 - Implications for Testing 36:12 - Toggle Interaction; Nesting of Features 37:28 - Introducing Features Toggles to Teams Pushback 40:43 - Managing Code Reviews with No Feature Branches Picks Cryptic Ruby Global Variables and Their Meanings (Coraline) RailsBridge Installfest (Coraline) Concourse (Pete) Architectural Decision Records (Pete) Pete Hodgson: The Ultimate Traveler's Coffee Kit (Pete) Deschutes Red Chair NWPA (Pete)

02:07 - Pete Hodgson Introduction Twitter GitHub Blog Ruby Rogues Episode #176: Rails as an SOA Client with Pete Hodgson The iPhreaks Show Episodes with Pete Hodgson 03:13 - Feature Toggles, Flags, Bits, Etc. Trunk Based Development iPhreaks Show Episode #136: Efficient Engineering Practices for Software Projects with Neal Ford 06:17 - Merge Hell 08:10 - Branches 08:59 - Why not constantly rebase? Martin Fowler: FeatureBranch 10:48 - Why use feature toggles? Martin Fowler: Feature Toggles 12:29 - Making Code Configurable 16:37 - Approaching Feature Toggles 20:04 - A/B Testing 25:11 - Approaching Feature Toggles (Cont’d) snuffle ambient-spec rack-flags 34:37 - Implications for Testing 36:12 - Toggle Interaction; Nesting of Features 37:28 - Introducing Features Toggles to Teams Pushback 40:43 - Managing Code Reviews with No Feature Branches Picks Cryptic Ruby Global Variables and Their Meanings (Coraline) RailsBridge Installfest (Coraline) Concourse (Pete) Architectural Decision Records (Pete) Pete Hodgson: The Ultimate Traveler's Coffee Kit (Pete) Deschutes Red Chair NWPA (Pete)

02:04 - Mindaugas Mozūras Introduction Twitter GitHub Blog Vinted pronto 02:36 - Automating Code Reviews 03:17 - What is a code review and why do it? 03:39 - Styles of Code Reviews: What parts should be automated?     06:04 - pronto vs rubocop flay Brakeman metric_fu flog 08:26 - Workflow 10:14 - Runners 11:42 - Feedback 13:21 - Use Cases for Pronto 14:28 - How has pronto changed your codebase? 15:34 - Feelings and Code Reviews; Agreeing on Standards as a Team 17:38 - Return Values Ruby Rogues Episode #248: The Crystal Programming Language with Erik Michaels-Ober 19:43 - Reviewing Pull Requests and Code Review Ethics 25:56 - Feature Flags Martin Fowler: Feature Toggles iPhreaks Episode #136: Efficient Engineering Practices for Software Projects with Neal Ford 27:21 - Managing Open Source Projects and Communities 30:37 - What’s next for pronto? Bitbucket Support Picks Manic Panic Hair Dye (Jessica) Kenneth Reitz: MentalHealthError: an exception occurred. (Jessica) Frinkiac (Coraline) Erik Trautman: Why Learning to Code is So Damn Hard (Coraline) AppSumo (Chuck) AddThis (Chuck) CircleCI (Chuck) Freelance Remote Conf (Chuck) Ruby Remote Conf (Chuck) RescueTime (Mindaugas) Dan McKinley: Choose Boring Technology (Mindaugas) Brandon Sanderson (Mindaugas)

02:04 - Mindaugas Mozūras Introduction Twitter GitHub Blog Vinted pronto 02:36 - Automating Code Reviews 03:17 - What is a code review and why do it? 03:39 - Styles of Code Reviews: What parts should be automated?     06:04 - pronto vs rubocop flay Brakeman metric_fu flog 08:26 - Workflow 10:14 - Runners 11:42 - Feedback 13:21 - Use Cases for Pronto 14:28 - How has pronto changed your codebase? 15:34 - Feelings and Code Reviews; Agreeing on Standards as a Team 17:38 - Return Values Ruby Rogues Episode #248: The Crystal Programming Language with Erik Michaels-Ober 19:43 - Reviewing Pull Requests and Code Review Ethics 25:56 - Feature Flags Martin Fowler: Feature Toggles iPhreaks Episode #136: Efficient Engineering Practices for Software Projects with Neal Ford 27:21 - Managing Open Source Projects and Communities 30:37 - What’s next for pronto? Bitbucket Support Picks Manic Panic Hair Dye (Jessica) Kenneth Reitz: MentalHealthError: an exception occurred. (Jessica) Frinkiac (Coraline) Erik Trautman: Why Learning to Code is So Damn Hard (Coraline) AppSumo (Chuck) AddThis (Chuck) CircleCI (Chuck) Freelance Remote Conf (Chuck) Ruby Remote Conf (Chuck) RescueTime (Mindaugas) Dan McKinley: Choose Boring Technology (Mindaugas) Brandon Sanderson (Mindaugas)

02:04 - Mindaugas Mozūras Introduction Twitter GitHub Blog Vinted pronto 02:36 - Automating Code Reviews 03:17 - What is a code review and why do it? 03:39 - Styles of Code Reviews: What parts should be automated?     06:04 - pronto vs rubocop flay Brakeman metric_fu flog 08:26 - Workflow 10:14 - Runners 11:42 - Feedback 13:21 - Use Cases for Pronto 14:28 - How has pronto changed your codebase? 15:34 - Feelings and Code Reviews; Agreeing on Standards as a Team 17:38 - Return Values Ruby Rogues Episode #248: The Crystal Programming Language with Erik Michaels-Ober 19:43 - Reviewing Pull Requests and Code Review Ethics 25:56 - Feature Flags Martin Fowler: Feature Toggles iPhreaks Episode #136: Efficient Engineering Practices for Software Projects with Neal Ford 27:21 - Managing Open Source Projects and Communities 30:37 - What’s next for pronto? Bitbucket Support Picks Manic Panic Hair Dye (Jessica) Kenneth Reitz: MentalHealthError: an exception occurred. (Jessica) Frinkiac (Coraline) Erik Trautman: Why Learning to Code is So Damn Hard (Coraline) AppSumo (Chuck) AddThis (Chuck) CircleCI (Chuck) Freelance Remote Conf (Chuck) Ruby Remote Conf (Chuck) RescueTime (Mindaugas) Dan McKinley: Choose Boring Technology (Mindaugas) Brandon Sanderson (Mindaugas)

01:20 - Neal Ford Introduction Twitter GitHub Blog iPhreaks Episode #84: Building Your Technology Radar with Neal Ford iPhreaks Show Episode #119: Ambient Information and the Apple Watch with Neal Ford ThoughtWorks 02:16 - Efficient Engineering Practices for Software Projects Test-Driven Development Continuous Integration Continuous Integration Servers CruiseControl Continuous Delivery 08:42 - Feature Branching Martin Fowler: FeatureBranch 12:13 - Bad Things About Feature Branching Merge Ambush No Opportunistic Refactoring ClearCase Merge Conflicts 17:02 - Trunk Based Development Feature Toggles Martin Fowler: Feature Toggles 24:10 - Continuous Integration (Cont’d) 26:58 - Hypothesis-Driven Development (Experiment-Driven Development) Radiolab Podcast: The Trust Engineers 32:08 - Pull Requests 35:32 - Feature Branching (Cont’d) CircleCI 40:32 - Implementing Feature Toggles 44:47 - Automatic Machine Provisioning Unit Testing Functional Testing 49:15 - Consulting Judo - Michael Nygard “Demonstration trumps discussion.” 54:28 - Eliminating Pain Points; Automation & Delegation The Productive Programmer by Neal Ford Eventual Millionaire Podcast 01:00:33 - The Out-of-town Consultant Effect Picks Apple TV (Jaim) Pebble Time Steel (Chuck) iOS Remote Conf (Chuck) LaunchDarkly (Neal) Grasp (Neal)

01:20 - Neal Ford Introduction Twitter GitHub Blog iPhreaks Episode #84: Building Your Technology Radar with Neal Ford iPhreaks Show Episode #119: Ambient Information and the Apple Watch with Neal Ford ThoughtWorks 02:16 - Efficient Engineering Practices for Software Projects Test-Driven Development Continuous Integration Continuous Integration Servers CruiseControl Continuous Delivery 08:42 - Feature Branching Martin Fowler: FeatureBranch 12:13 - Bad Things About Feature Branching Merge Ambush No Opportunistic Refactoring ClearCase Merge Conflicts 17:02 - Trunk Based Development Feature Toggles Martin Fowler: Feature Toggles 24:10 - Continuous Integration (Cont’d) 26:58 - Hypothesis-Driven Development (Experiment-Driven Development) Radiolab Podcast: The Trust Engineers 32:08 - Pull Requests 35:32 - Feature Branching (Cont’d) CircleCI 40:32 - Implementing Feature Toggles 44:47 - Automatic Machine Provisioning Unit Testing Functional Testing 49:15 - Consulting Judo - Michael Nygard “Demonstration trumps discussion.” 54:28 - Eliminating Pain Points; Automation & Delegation The Productive Programmer by Neal Ford Eventual Millionaire Podcast 01:00:33 - The Out-of-town Consultant Effect Picks Apple TV (Jaim) Pebble Time Steel (Chuck) iOS Remote Conf (Chuck) LaunchDarkly (Neal) Grasp (Neal)

Most weeks on the podcast, Ryn talks about how Agile is used for writing code to deliver software. And different software of course runs all kinds of machinery from cars to cell phones, refrigerators, and everything else. A huge challenge in all business is how to get disciplined execution on a steady basis that is linked to innovative thinking. After all, innovative/creative thinkers are all undisciplined by definition, aren’t they? And discipline leaves no room for creativity, at all ever; or does it? The disciplined person does not ‘color outside the lines.’ But is it possible to implement Agile in non-code writing enterprises? To contact Ryn directly go to www.rynmelberg.com.

Special guest Guy English returns to the show to talk about iOS 8 quality concerns, and whether Apple’s annual software cycle is stretching the company too thin. Then things devolve into a bitter argument over the merits of file name extensions.

In this episode, we discuss the top software and services we recommend for project management.

Charles and Brandon argue about what to name the podcast. They talk about how "one more feature"-itis sinks many projects and startups, how you can recognize when you're caught in it, and patterns they've used to avoid it.

Information security, and the technologies that provide such security, are a very hot topic throughout the information technology and business communities today. This presentation opens with a consideration of the current network environment. It answers the questions "where are these technologies?" and "where are the gaps in the technologies that are being addressed?" especially as they impact security. Next, the presentation considers the field of network security technologies. It addresses the good, the bad and the undecided aspects of the field today. After setting the stage with this background information, the presentation identifies the most important trends that will impact the network security industry in the coming few years: the federal government finally cares, the vanishing network perimeter, and the opportunity to achieve ubiquitous encryption. Toward the end of the presentation, Dr. Reel presents two "killer" security-related applications. Finally, the presentation closes with a discussion of the major needs in the information security field. About the speaker: Dr. Reel has BS and Ph.D. degrees in Computer Science. He spent over 9 years with the National Security Agency developing network-based software for deployment around the world. In 1995, he joined Trident Data Systems (now Veridian Corporation) in their San Antonio operation. For 3.5 years, he worked in an advanced research and development facility dedicated to information security technology development and assessment. Since September 1998, he has been the Chief Technology Officer of Veridian's Information Security business unit. In 1998 he and five teammates were awarded a patent on a new technology to protect communications circuits from malicious use. In addition to his dissertation, "Radiant Object-Oriented Analysis and Design", he has had one article published by IEEE Software Magazine (Critical Success Factors in Software Projects, May/June 1999). Further, he has given numerous talks and authored many white papers on IA/IO/IW/IP/IS concepts and technologies. Dr. Reel represents Veridian on the External Advisory Board for the Center for Education and Research in Information Assurance and Security (CERIAS) at Purdue University. In addition, he serves as an advisor to the Security Panel of the President's Committee of Advisors on Science and Technology (PCAST) as well as the Emerging Technology Panel for the San Antonio Chamber of Commerce.