Podcasts about mythical man month

# Note dell'episodioIn questa puntata ci addentriamo nel mondo delle startup, del software open source e dell'innovazione con Matteo Collina e Paolo Insonnia di Platformatic. Insieme, riflettiamo sulla differenza tra lavoro in consulenza e sviluppo di prodotto, dove il rischio è alto, ma le possibilità di crescita e impatto sono altrettanto grandi. Matteo condivide la sua esperienza nell'avviare una startup, evidenziando i rischi finanziari e il "countdown" che ogni realtà imprenditoriale affronta fino a raggiungere la sostenibilità economica.Parliamo dell'open source, delle sfide etiche e commerciali che comporta e di come bilanciare la libertà del codice aperto con la necessità di sostenibilità economica. Matteo ci guida attraverso i tre assi fondamentali per interpretare l'open source in un contesto aziendale: la licenza, la governance, e la commerciabilità, facendo esempi pratici come Node.js, Chromium e React. Paolo aggiunge un quarto asse: l'autonomia funzionale del software rispetto alla versione commerciale, evidenziando come l'open source possa essere usato strategicamente per attrarre utenti.Abbiamo anche esplorato Watt, il nuovo application server di Platformatic, progettato per superare i limiti di scalabilità e performance di Node.js. Watt permette di eseguire più applicazioni nello stesso processo, eliminando il bisogno di comunicazioni di rete e riducendo il consumo di risorse. I nostri ospiti ci raccontano come Watt rivoluzioni l'esperienza degli sviluppatori e delle operazioni DevOps, integrando funzionalità di monitoraggio avanzate e strumenti di logging per ridurre drasticamente il consumo di memoria e ottimizzare la gestione delle risorse.Infine, riflettiamo sull'importanza dell'apprendimento continuo per gli sviluppatori, un tema caro a Matteo e Paolo, che ricordano come sia fondamentale uscire dalla propria comfort zone e rimanere curiosi, seguendo talk tecnici e approfondendo concetti fondamentali come l'event loop di Node.js.# Paese dei BalocchiLibro consigliato: “The Mythical Man-Month” di Frederick P. BrooksTool di logging: PinoFramework di documentazione: Diataxis# Supportaci suhttps://www.gitbar.it/support# Link amazon affiliato https://amzn.to/3XDznm1# Per favore ascoltaci usando una di queste app:https://podcastindex.org/apps# ContattiCi trovate su Twitter come @brainrepo oppure potete scriverci via mail su https://gitbar.it.# CreditiLe sigle sono state prodotte da MondoComputazionaleLe musiche da Blan Kytt - RSPNSweet Lullaby by Agnese ValmaggiaMonkeys Spinning Monkeys by Kevin MacLeod

In this special episode of Book Overflow, Carl Brown (of the YouTube channel Internet of Bugs) joins Carter and Nathan to share some of his favorite books! Carl is incredibly well read and shares which books have influenced him over his very impressive 35 year career. 00:00 Intro 02:17 How did Internet of Bugs come to be? 06:03 Why still read tech books? 08:32 Mythical Man-Month 14:40 Philosophy of Software Design, TCL/TK, 25:56 Advanced Programming in Unix and TCP/IP Illustrated 32:32 How important is it to be well-versed in Unix? 42:27 Freelance, Business, and Consulting book recommendations 52:57 Lightning Round: Managing your programming career, philosophy, and general advice 01:02:34 Final Thoughts -- Books Mentioned in this Episode -- Note: As an Amazon Associate, we earn from qualifying purchases. ---------------------------------------------------------- App Accomplished: Strategies for App Development Success 1st Edition, Kindle Edition by Carl Brown https://amzn.to/473mG9C (paid link) Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition Anniversary Edition by Frederick Brooks Jr. https://amzn.to/3XnDhlm (paid link) A Philosophy of Software Design, 2nd Edition by John Ousterhout https://amzn.to/473OISA (paid link) Tcl and the Tk Toolkit 1st Edition by John K. Ousterhout https://amzn.to/3X7sdHX (paid link) Advanced Programming in the Unix Environment by W. Richard Stevens https://amzn.to/477PayZ (paid link) TCP/IP Illustrated, Vol. 1: The Protocols by W. Richard Stevens https://amzn.to/3T6ZFgo (paid link) {Carl says Volumes 2 and 3 are great, too} Sun Performance and Tuning: Java and the Internet (2nd Edition) Subsequent Edition by Adrian Cockcroft, Richard Pettit https://amzn.to/3Xkczdt (paid link) Free Agent Nation: How America's New Independent Workers Are Transforming the Way We Live by Daniel H. Pink https://amzn.to/47mhDBD (paid link) The Computer Consultant's Guide: Real-Life Strategies for Building a Successful Consulting Career 2nd Edition by Janet Ruhl https://amzn.to/3T9IT0d (paid link) Getting Started in Consulting by Alan Weiss https://amzn.to/3T7INpY (paid link) The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt and David Thomas https://amzn.to/3T6lvk9 (paid link) The Pragmatic Programmer: 20th Anniversary Edition, 2nd Edition: Your Journey to Mastery by David Thomas, Andrew Hunt, et al. https://amzn.to/3TafdQp (paid link) My Job Went to India (and All I Got Was This Lousy Book): 52 Ways to Save Your Job (Pragmatic Programmers) 1st Edition by Chad Fowler https://amzn.to/3T8ubGu (paid link) Programming Perl by Tom Christiansen, Randal L. Schwartz, et al. https://amzn.to/4g32KYy (paid link) Speed Reading: Third Edition by Tony Buzan https://amzn.to/3X7qCla (paid link) The 7 Habits of Highly Effective People: 30th Anniversary Edition (The Covey Habits Series) by Stephen R. Covey , Jim Collins, et al. https://amzn.to/4geWVYm (paid link) Don't Make Me Think, Revisited: A Common Sense Approach to Web Usability (3rd Edition) by Steve Krug | Dec 24, 2013 https://amzn.to/3X1RRxD (paid link) Database in Depth: Relational Theory for Practitioners by C. J. Date | May 15, 2005 https://amzn.to/3z055D4 (paid link) Joe Celko's SQL for Smarties: Advanced SQL Programming by Joe Celko | Dec 16, 2014 https://amzn.to/4geWYn0 (paid link) Problem Frames and Methods: Analysing and Structuring Software Development Problems Paperback – January 1, 2001 by Michael A. Jackson https://amzn.to/4g6sdjO (paid link) Learning to Classify Text Using Support Vector Machines 2nd Edition by Thorsten Joachims https://amzn.to/3ACf95y (paid link) Driving Technical Change: Why People On Your Team Don't Act On Good Ideas, and How to Convince Them They Should by Terrence Ryan | Dec 28, 2010 https://amzn.to/3MoUpRC (paid link) Understanding Deep Learning by Simon J.D. Prince https://amzn.to/3TafqTH (paid link) As an Amazon Associate, we earn from qualifying purchases.

Bio Luke Hohmann is Chief Innovation Officer of Applied Frameworks. Applied Frameworks helps companies create more profitable software-enabled solutions. A serial entrepreneur, Luke founded, bootstrapped, and sold the SaaS B2B collaboration software company Conteneo to Scaled Agile, Inc. Conteneo's Weave platform is now part of SAFe Studio. A SAFe® Fellow, prolific author, and trailblazing innovator, Luke's contributions to the global agile community include contributing to SAFe, five books, Profit Streams™, Innovation Games®, Participatory Budgeting at enterprise scale, and a pattern language for market-driven roadmapping. Luke is also co-founder of Every Voice Engaged Foundation, where he partnered with The Kettering Foundation to create Common Ground for Action, the world's first scalable platform for deliberative decision-making. Luke is a former National Junior Pairs Figure Skating Champion and has an M.S.E. in Computer Science and Engineering from the University of Michigan. Luke loves his wife and four kids, his wife's cooking, and long runs in the California sunshine and Santa Cruz mountains.    Interview Highlights 01:30 Organisational Behaviour & Cognitive Psychology 06:10 Serendipity 09:30 Entrepreneurship 16:15 Applied Frameworks 20:00 Sustainability 20:45 Software Profit Streams 23:00 Business Model Canvas 24:00 Value Proposition Canvas 24:45 Setting the Price 28:45 Customer Benefit Analysis 34:00 Participatory Budgeting 36:00 Value Stream Funding 37:30 The Color of Money 42:00 Private v Public Sector 49:00 ROI Analysis 51:00 Innovation Accounting    Connecting   LinkedIn: Luke Hohmann on LinkedIn Company Website: Applied Frameworks    Books & Resources   ·         Software Profit Streams(TM): A Guide to Designing a Sustainably Profitable Business: Jason Tanner, Luke Hohmann, Federico González ·         Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers (The Strategyzer series): Alexander Osterwalder, Yves Pigneur ·         Value Proposition Design: How to Create Products and Services Customers Want (The Strategyzer Series): Alexander Osterwalder, Yves Pigneur, Gregory Bernarda, Alan Smith, Trish Papadakos ·         Innovation Games: Creating Breakthrough Products Through Collaborative Play: Luke Hohmann ·         The ‘Color of Money' Problem: Additional Guidance on Participatory Budgeting - Scaled Agile Framework ·         The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses, Eric Ries ·         Extreme Programming Explained: Embrace Change 2, Kent Beck, Cynthia Andres ·         The Mythical Man-Month: Essays on Software Engineering: Brooks, Frederick Phillips ·         Understanding Comics: The Invisible Art, Scott McCloud ·         Ponyboy: A Novel, Eliot Duncan ·         Lessons in Chemistry: A Novel, Bonnie Garmus, Miranda Raison, Bonnie Garmus, Pandora Sykes ·         What Happened to You?: Conversations on Trauma, Resilience, and Healing, Oprah Winfrey, Bruce D. Perry ·         Training | Applied Frameworks   Episode Transcript Intro: Hello and welcome to the Agile Innovation Leaders podcast. I'm Ula Ojiaku. On this podcast I speak with world-class leaders and doers about themselves and a variety of topics spanning Agile, Lean Innovation, Business, Leadership and much more – with actionable takeaways for you the listener.  Ula Ojiaku   So I have with me Luke Hohmann, who is a four time author, three time founder, serial entrepreneur if I say, a SAFe fellow, so that's a Skilled Agile Framework fellow, keynote speaker and an internationally recognised expert in Agile software development. He is also a proud husband and a father of four. So, Luke, I am very honoured to have you on the Agile Innovation Leaders podcast. Thank you for making the time. Luke Hohmann Thank you so much for having me, I'm very happy to be here, and hi everyone who's listening. Ula Ojiaku Yes, I'm sure they're waving back at you as well. I always start my conversations with my guests to find out about them as individuals, you know, so who is Luke? You have a BSc in Computer Science and an MSc in Computer Science and Engineering, but you also studied Cognitive Psychology and Organisational Behaviour in addition to Data Structures and Artificial Intelligence. AI is now making waves and is kind of at the forefront, which is interesting, you had the foresight to also look into these. So my question is, what took you down this path? Luke Hohmann Sure. I had a humble beginning in the world of technology. I worked for a large company, Electronic Data Systems, and it was founded in the mid 60s by a gentleman named Ross Perot, and it became a very, very large company. So my first job at Electronic Data Systems was working in a data centre, and we know what data centres are, but back then, data centres were different because they were predominantly mainframe-based data centres, and I would crawl underneath the floor, cabling the computers and cabling networking equipment. Now, when we think networking, we're really thinking one of two kinds of networking. We think of wireless networking or we think of some form of internet networking, but back in those days, there were varieties of network protocols, literally the standards that we use now weren't invented yet. So it was mainframe networking protocols and dial ups and other forms of networking protocols. From there, I worked my way from beneath the ground up. I had some great managers who saw someone who was worthy of opportunity and they gave me opportunity and it was great. And then eventually I started working in electronic data systems and there was, the first wave of AI came in the mid 80s and that's when we were doing things like building expert systems, and I managed to create with a colleague of mine, who's emerged as my best friend, a very successful implementation of an expert system, an AI-based expert system at EDS, and that motivated me to finish off my college degree, I didn't have my college degree at the time. So EDS supported me in going to the University of Michigan, where as you said, I picked up my Bachelor's and Master's degree, and my advisor at the time was Elliot Soloway, and he was doing research in how programmers program, what are the knowledge structures, what are the ways in which we think when we're programming, and I picked up that research and built programming environments, along with educational material, trying to understand how programmers program and trying to build educational material to teach programming more effectively. That's important because it ignited a lifelong passion for developing education materials, etc. Now the cognitive psychology part was handled through that vein of work, the organisational behaviour work came as I was a student at Michigan. As many of us are when we're in college, we don't make a lot of money, or at university we're not wealthy and I needed a job and so the School of Organisational Behaviour had published some job postings and they needed programmers to program software for their organisational behaviour research, and I answered those ads and I became friends and did the research for many ground-breaking aspects of organisational behaviour and I programmed, and in the process of programming for the professors who were in the School of Organisational Behaviour they would teach me about organisational behaviour and I learned many things that at the time were not entirely clear to me, but then when I graduated from university and I became a manager and I also became more involved in the Agile movement, I had a very deep foundation that has served me very well in terms of what do we mean when we say culture, or what do we mean when we talk about organisational structures, both in the small and in the large, how do we organise effectively, when should we scale, when should we not scale, etc. So that's a bit about my history that I think in terms of the early days helped inform who I am today. Ula Ojiaku Wow, who would have thought, it just reminds me of the word serendipity, you know, I guess a happy coincidence, quote unquote, and would there be examples of where the cognitive psychology part of it also helped you work-wise? Luke Hohmann Yeah, a way to think about cognitive psychology and the branch that, I mean there's, psychology is a huge branch of study, right? So cognitive psychology tends to relate to how do we solve problems, and it tends to focus on problem solving where n = 1 and what I mean by n is the number of participants, and where n is just me as an individual, how do I solve the problems that I'm facing? How do I engage in de-compositional activities or refinement or sense making? Organisational behaviour deals with n > 1. So it can deal with a team of, a para-bond, two people solving problems. It can deal with a small team, and we know through many, many, many decades of research that optimal team structures are eight people or less. I mean, we've known this for, when I say decades I mean millennia. When you look at military structure and military strategy, we know that people need to be organised into much smaller groups to be effective in problem solving and to move quickly. And then in any organisational structure, there's some notion of a team of teams or team engagement. So cognitive psychology, I think, helps leaders understand individuals and their place within the team. And now we talk about, you know, in the Agile community, we talk about things like, I want T-shaped people, I want people with common skills and their area of expertise and by organising enough of the T's, I can create a whole and complete team. I often say I don't want my database designer designing my user interface and I don't want my user interface designer optimising my back end database queries, they're different skills. They're very educated people, they're very sophisticated, but there's also the natural feeling that you and I have about how do I gain a sense of self, how do I gain a sense of accomplishment, a sense of mastery? Part of gaining a sense of mastery is understanding who you are as a person, what you're good at. In Japanese, they would call that Ikigai, right, what are the intersections of, you know, what do I love, what am I good at, what can I make a living at and what do people need, right? All of these intersections occur on an individual level, and then by understanding that we can create more effective teams. Ula Ojiaku Thank you. I've really learned something key here, the relationship between cognitive psychology and organisational behaviour, so thanks for breaking it down. Now, can we go quickly to your entrepreneurship? So there must be three times you started three times a company and you've been successful in that area. What exactly drives you when it comes to establishing businesses and then knowing when to move on? Luke Hohmann Sure. I think it's a combination of reflecting on my childhood and then looking at how that informs someone when they're older, and then opportunities, like you said, serendipity, I think that's a really powerful word that you introduced and it's a really powerful concept because sometimes the serendipity is associated with just allowing yourself to pursue something that presents itself. But when I was young, my father died and my mum had to raise six kids on her own, so my dad died when I was four, my mum raised six kids on her own. We were not a wealthy family, and she was a school teacher and one of the things that happened was, even though she was a very skilled school teacher, there were budget cuts and it was a unionised structure, and even though she was ranked very highly, she lost her job because she was low on the hiring totem pole in terms of how the union worked. It was very hard and of course, it's always hard to make budget cuts and firing but I remember when I was very young making one of those choices saying, I want to work in a field where we are more oriented towards someone's performance and not oriented on when they were hired, or the colour of their skin, or their gender or other things that to me didn't make sense that people were making decisions against. And while it's not a perfect field for sure, and we've got lots of improvement, engineering in general, and of course software engineering and software development spoke to me because I could meet people who were diverse or more diverse than in other fields and I thought that was really good. In terms of being an entrepreneur, that happened serendipitously. I was at the time, before I became an entrepreneur in my last job, was working for an Israeli security firm, and years and years ago, I used to do software anti-piracy and software security through physical dongles. This was made by a company called Aladdin Knowledge Systems in Israel, and I was the head of Engineering and Product Management for the dongle group and then I moved into a role of Business Development for the company. I had a couple of great bosses, but I also learned how to do international management because I had development teams in Israel, I had development teams in Munich, I had development teams in Portland, Oregon, and in the Bay Area, and this was in the 2000s. This is kind of pre-Agile, pre-Salt Lake City, pre-Agile Manifesto, but we were figuring things out and blending and working together. I thought things were going pretty well and I enjoyed working for the Israelis and what we were doing, but then we had the first Gulf War and my wife and I felt that maybe traveling as I was, we weren't sure what was going to happen in the war, I should choose something different. Unfortunately, by that time, we had been through the dot-bomb crisis in Silicon Valley. So it's about 2002 at the time that this was going on, and there really weren't jobs, it was a very weird time in Silicon Valley. So in late 2002, I sent an email to a bunch of friends and I said, hey, I'm going to be a consultant, who wants to hire me, that was my marketing plan, not very clever, and someone called me and said, hey, I've got a problem and this is the kind of thing that you can fix, come consult with us. And I said, great. So I did that, and that started the cleverly named Luke Hohmann Consulting, but then one thing led to another and consulting led to opportunities and growth and I've never looked back. So I think that there is a myth about people who start companies where sometimes you have a plan and you go execute your plan. Sometimes you find the problem and you're solving a problem. Sometimes the problem is your own problem, as in my case I had two small kids and a mortgage and I needed to provide for my family, and so the best way to do that at the time was to become a consultant. Since then I have engaged in building companies, sometimes some with more planning, some with more business tools and of course as you grow as an entrepreneur you learn skills that they didn't teach you in school, like marketing and pricing and business planning etc. And so that's kind of how I got started, and now I have kind of come full circle. The last company, the second last company I started was Conteneo and we ended up selling that to Scaled Agile, and that's how I joined the Scaled Agile team and that was lovely, moving from a position of being a CEO and being responsible for certain things, to being able to be part of a team again, joining the framework team, working with Dean Leffingwell and other members of the framework team to evolve the SAFe framework, that was really lovely. And then of course you get this entrepreneurial itch and you want to do something else, and so I think it comes and goes and you kind of allow yourself those opportunities. Ula Ojiaku Wow, yours is an inspiring story. And so what are you now, so you've talked about your first two Startups which you sold, what are you doing now? Luke Hohmann Yeah, so where I'm at right now is I am the Chief Innovation Officer for a company, Applied Frameworks. Applied Frameworks is a boutique consulting firm that's in a transition to a product company. So if this arm represents our product revenue and this arm represents our services revenue, we're expanding our product and eventually we'll become a product company. And so then the question is, well, what is the product that we're working on? Well, if you look at the Agile community, we've spent a lot of time creating and delivering value, and that's really great. We have had, if you look at the Agile community, we've had amazing support from our business counterparts. They've shovelled literally millions and millions of dollars into Agile training and Agile tooling and Agile transformations, and we've seen a lot of benefit from the Agile community. And when I say Agile, I don't mean SAFe or Scrum or some particular flavour of Agile, I just mean Agile in general. There's been hundreds of millions of dollars to billions of dollars shoved into Agile and we've created a lot of value for that investment. We've got fewer bugs in our software because we've got so many teams doing XP driven practices like Test Driven Development, we've got faster response times because we've learned that we can create smaller releases and we've created infrastructure that lets us do deployments automatically, even if you're doing embedded systems, we figured out how to do over the air updates, we've figured out how to create infrastructure where the cars we're driving are now getting software updates. So we've created for our business leaders lots of value, but there's a problem in that value. Our business leaders now need us to create a profit, and creating value and creating a profit are two different things. And so in the pursuit of value, we have allowed our Agile community to avoid and or atrophy on skills that are vital to product management, and I'm a classically trained Product Manager, so I've done market segmentation and market valuation and market sizing, I've done pricing, I've done licensing, I've done acquisitions, I've done compliance. But when you look at the traditional definition of a Product Owner, it's a very small subset of that, especially in certain Agile methods where Product Owners are team centric, they're internal centric. That's okay, I'm not criticising that structure, but what's happened is we've got people who no longer know how to price, how to package, how to license products, and we're seeing companies fail, investor money wasted, too much time trying to figure things out when if we had simply approached the problem with an analysis of not just what am I providing to you in terms of value, but what is that value worth, and how do I structure an exchange where I give you value and you give me money? And that's how businesses survive, and I think what's really interesting about this in terms of Agile is Agile is very intimately tied to sustainability. One of the drivers of the Agile Movement was way back in the 2000s, we were having very unsustainable practices. People would be working 60, 80, death march weeks of grinding out programmers and grinding out people, and part of the Agile Movement was saying, wait a minute, this isn't sustainable, and even the notion of what is a sustainable pace is really vital, but a company cannot sustain itself without a profit, and if we don't actually evolve the Agile community from value streams into profit streams, we can't help our businesses survive. I sometimes ask developers, I say, raise your hand if you're really embracing the idea that your job is to make more money for your company than they pay you, that's called a profit, and if that's not happening, your company's going to fail. Ula Ojiaku They'll be out of a job. Luke Hohmann You'll be out of a job. So if you want to be self-interested about your future, help your company be successful, help them make a profit, and so where I'm at right now is Applied Frameworks has, with my co-author, Jason Tanner, we have published a bold and breakthrough new book called Software Profit Streams, and it's a book that describes how to do pricing and packaging for software enabled solutions. When we say software enabled solution, we mean a solution that has software in it somehow, could be embedded software in your microwave oven, it could be a hosted solution, it could be an API for a payment processor, it could be the software in your car that I talked about earlier. So software enabled solutions are the foundation, the fabric of our modern lives. As Mark Andreessen says software is eating the world, software is going to be in everything, and we need to know how to take the value that we are creating as engineers, as developers, and convert that into pricing and licensing choices that create sustainable profits. Ula Ojiaku Wow. It's as if you read my mind because I was going to ask you about your book, Software Profit Streams, A Guide to Designing a Sustainably Profitable Business. I also noticed that, you know, there is the Profit Stream Canvas that you and your co-author created. So let's assume I am a Product Manager and I've used this, let's assume I went down the path of using the Business Model Canvas and there is the Customer Value Proposition. So how do they complement? Luke Hohmann How do they all work together? I'm glad you asked that, I think that's a very insightful question and the reason it's so helpful is because, well partly because I'm also friends with Alex Osterwalder, I think he's a dear, he's a wonderful human, he's a dear friend. So let's look at the different elements of the different canvases, if you will, and why we think that this is needed. The Business Model Canvas is kind of how am I structuring my business itself, like what are my partners, my suppliers, my relationships, my channel strategy, my brand strategy with respect to my customer segments, and it includes elements of cost, which we're pretty good at. We're pretty good at knowing our costs and elements of revenue, but the key assumption of revenue, of course, is the selling price and the number of units sold. So, but if you look at the book, Business Model Generation, where the Business Model Canvas comes from, it doesn't actually talk about how to set the price. Is the video game going to be $49? Is it going to be $59, or £49 or £59? Well, there's a lot of thought that goes into that. Then we have the Value Proposition Canvas, which highlights what are the pains the customer is facing? What are the gains that the customer is facing? What are the jobs to be done of the customer? How does my solution relate to the jobs? How does it help solve the pain the customer is feeling? How does it create gain for the customer? But if you read those books, and both of those books are on my shelf because they're fantastic books, it doesn't talk about pricing. So let's say I create a gain for you. Well, how much can I charge you for the gain that I've created? How do I structure that relationship? And how do I know, going back to my Business Model Canvas, that I've got the right market segment, I've got the right investment strategy, I might need to make an investment in the first one or two releases of my software or my product before I start to make a per unit profit because I'm evolving, it's called the J curve and the J curve is how much money am I investing before I well, I have to be able to forecast that, I have to be able to model that, but the key input to that is what is the price, what is the mechanism of packaging that you're using, is it, for example, is it per user in a SAS environment or is it per company in a SAS environment? Is it a meter? Is it like an API transaction using Stripe or a payment processor, Adyen or Stripe or Paypal or any of the others that are out there? Or is it an API call where I'm charging a fraction of a penny for any API call? All of those elements have to be put into an economic model and a forecast has to be created. Now, what's missing about this is that the Business Model Canvas and the Value Proposition Canvas don't give you the insight on how to set the price, they just say there is a price and we're going to use it in our equations. So what we've done is we've said, look, setting the price is itself a complex system, and what I mean by a complex system is that, let's say that I wanted to do an annual license for a new SAS offering, but I offer that in Europe and now my solution is influenced or governed by GDPR compliance, where I have data retention and data privacy laws. So my technical architecture that has to enforce the license, also has to comply with something in terms of the market in which I'm selling. This complex system needs to be organised, and so what canvases do is in all of these cases, they let us take a complex system and put some structure behind the choices that we're making in that complex system so that we can make better choices in terms of system design. I know how I want this to work, I know how I want this to be structured, and therefore I can make system choices so the system is working in a way that benefits the stakeholders. Not just me, right, I'm not the only stakeholder, my customers are in this system, my suppliers are in this system, society itself might be in the system, depending on the system I'm building or the solution I'm building. So the canvases enable us to make system level choices that are hopefully more effective in achieving our goals. And like I said, the Business Model Canvas, the Value Proposition Canvas are fantastic, highly recommended, but they don't cover pricing. So we needed something to cover the actual pricing and packaging and licensing. Ula Ojiaku Well, that's awesome. So it's really more about going, taking a deeper dive into thoughtfully and structurally, if I may use that word, assessing the pricing. Luke Hohmann Yeah, absolutely. Ula Ojiaku Would you say that in doing this there would be some elements of, you know, testing and getting feedback from actual customers to know what price point makes sense? Luke Hohmann Absolutely. There's a number of ways in which customer engagement or customer testing is involved. The very first step that we advocate is a Customer Benefit Analysis, which is what are the actual benefits you're creating and how are your customers experiencing those benefits. Those experiences are both tangible and intangible and that's another one of the challenges that we face in the Agile community. In general, the Agile community spends a little bit more time on tangible or functional value than intangible value. So we, in terms of if I were to look at it in terms of a computer, we used to say speeds and feeds. How fast is the processor? How fast is the network? How much storage is on my disk space? Those are all functional elements. Over time as our computers have become plenty fast or plenty storage wise for most of our personal computing needs, we see elements of design come into play, elements of usability, elements of brand, and we see this in other areas. Cars have improved in quality so much that many of us, the durability of the car is no longer a significant attribute because all cars are pretty durable, they're pretty good, they're pretty well made. So now we look at brand, we look at style, we look at aesthetics, we look at even paying more for a car that aligns with our values in terms of the environment. I want to get an EV, why, because I want to be more environmentally conscious. That's a value driven, that's an intangible factor. And so our first step starts with Customer Benefit Analysis looking at both functional or tangible value and intangible value, and you can't do that, as you can imagine, you can't do that without having customer interaction and awareness with your stakeholders and your customers, and that also feeds throughout the whole pricing process. Eventually, you're going to put your product in a market, and that's a form itself of market research. Did customers buy, and if they didn't buy, why did they not buy? Is it poorly packaged or is it poorly priced? These are all elements that involve customers throughout the process. Ula Ojiaku If I may, I know we've been on the topic of your latest book Software Profit Streams. I'm just wondering, because I can't help but try to connect the dots and I'm wondering if there might be a connection to one of your books, Innovation Games: Creating Breakthrough Products Through Collaborative Play, something like buy a feature in your book, that kind of came to mind, could there be a way of using that as part of the engagement with customers in setting a pricing strategy? I may be wrong, I'm just asking a question. Luke Hohmann I think you're making a great connection. There's two forms of relationship that Innovation Games and the Innovation Games book have with Software Profit Streams. One is, as you correctly noted, just the basics of market research, where do key people have pains or gains and what it might be worth. That work is also included in Alex Osterwalder's books, Value Proposition Design for example, when I've been doing Value Proposition Design and I'm trying to figure out the customer pains, you can use the Innovation Games Speed Boat. And when I want to figure out the gains, I can use the Innovation Game Product Box. Similarly, when I'm figuring out pricing and licensing, a way, and it's a very astute idea, a way to understand price points of individual features is to do certain kinds of market research. One form of market research you can do is Buy-a-Feature, which gives a gauge of what people are willing or might be willing to pay for a feature. It can be a little tricky because the normal construction of Buy-a-Feature is based on cost. However, your insight is correct, you can extend Buy-a-Feature such that you're testing value as opposed to cost, and seeing what, if you take a feature that costs X, but inflate that cost by Y and a Buy-a-Feature game, if people still buy it, it's a strong signal strength that first they want it, and second it may be a feature that you can, when delivered, would motivate you to raise the price of your offering and create a better profit for your company. Ula Ojiaku Okay, well, thank you. I wasn't sure if I was on the right lines. Luke Hohmann It's a great connection. Ula Ojiaku Thanks again. I mean, it's not original. I'm just piggybacking on your ideas. So with respect to, if we, if you don't mind, let's shift gears a bit because I know that, or I'm aware that whilst you were with Scaled Agile Incorporated, you know, you played a key part in developing some of their courses, like the Product POPM, and I think the Portfolio Management, and there was the concept about Participatory Budgeting. Can we talk about that, please? Luke Hohmann I'd love to talk about that, I mean it's a huge passion of mine, absolutely. So in February of 2018, I started working with the framework team and in December of 2018, we talked about the possibility of what an acquisition might look like and the benefits it would create, which would be many. That closed in May of 2019, and in that timeframe, we were working on SAFe 5.0 and so there were a couple of areas in which I was able to make some contributions. One was in Agile product delivery competency, the other was in lean portfolio management. I had a significant hand in restructuring or adding the POPM, APM, and LPM courses, adding things like solutions by horizons to SAFe, taking the existing content on guardrails, expanding it a little bit, and of course, adding Participatory Budgeting, which is just a huge passion of mine. I've done Participatory Budgeting now for 20 years, I've helped organisations make more than five billions of dollars of investment spending choices at all levels of companies, myself and my colleagues at Applied Frameworks, and it just is a better way to make a shared decision. If you think about one of the examples they use about Participatory Budgeting, is my preferred form of fitness is I'm a runner and so, and my wife is also a fit person. So if she goes and buys a new pair of shoes or trainers and I go and buy a new pair of trainers, we don't care, because it's a small purchase. It's frequently made and it's within the pattern of our normal behaviour. However, if I were to go out and buy a new car without involving her, that feels different, right, it's a significant purchase, it requires budgeting and care, and is this car going to meet our needs? Our kids are older than your kids, so we have different needs and different requirements, and so I would be losing trust in my pair bond with my wife if I made a substantial purchase without her involvement. Well, corporations work the same way, because we're still people. So if I'm funding a value stream, I'm funding the consistent and reliable flow of valuable items, that's what value stream funding is supposed to do. However, if there is a significant investment to be made, even if the value stream can afford it, it should be introduced to the portfolio for no other reason than the social structure of healthy organisations says that we do better when we're talking about these things, that we don't go off on our own and make significant decisions without the input of others. That lowers transparency, that lowers trust. So I am a huge advocate of Participatory Budgeting, I'm very happy that it's included in SAFe as a recommended practice, both for market research and Buy-a-Feature in APM, but also more significantly, if you will, at the portfolio level for making investment decisions. And I'm really excited to share that we've just published an article a few weeks ago about Participatory Budgeting and what's called The Color of Money, and The Color of Money is sometimes when you have constraints on how you can spend money, and an example of a constraint is let's say that a government raised taxes to improve transportation infrastructure. Well, the money that they took in is constrained in a certain way. You can't spend it, for example, on education, and so we have to show how Participatory Budgeting can be adapted to have relationships between items like this item requires this item as a precedent or The Color of Money, constraints of funding items, but I'm a big believer, we just published that article and you can get that at the Scaled Agile website, I'm a big believer in the social power of making these financial decisions and the benefits that accrue to people and organisations when they collaborate in this manner. Ula Ojiaku Thanks for going into that, Luke. So, would there be, in your experience, any type of organisation that's participatory? It's not a leading question, it's just genuine, there are typically outliers and I'm wondering in your experience, and in your opinion, if there would be organisations that it might not work for? Luke Hohmann Surprisingly, no, but I want to add a few qualifications to the effective design of a Participatory Budgeting session. When people hear Participatory Budgeting, there's different ways that you would apply Participatory Budgeting in the public and private sector. So I've done citywide Participatory Budgeting in cities and if you're a citizen of a city and you meet the qualifications for voting within that jurisdiction, in the United States, it's typically that you're 18 years old, in some places you have to be a little older, in some places you might have other qualifications, but if you're qualified to participate as a citizen in democratic processes, then you should be able to participate in Participatory Budgeting sessions that are associated with things like how do we spend taxes or how do we make certain investments. In corporations it's not quite the same way. Just because you work at a company doesn't mean you should be included in portfolio management decisions that affect the entire company. You may not have the background, you may not have the training, you may be what my friends sometimes call a fresher. So I do a lot of work overseas, so freshers, they just may not have the experience to participate. So one thing that we look at in Participatory Budgeting and SAFe is who should be involved in the sessions, and that doesn't mean that every single employee should always be included, because their background, I mean, they may be a technical topic and maybe they don't have the right technical background. So we work a little bit harder in corporations to make sure the right people are there. Now, of course, if we're going to make a mistake, we tend to make the mistake of including more people than excluding, partly because in SAFe Participatory Budgeting, it's a group of people who are making a decision, not a one person, one vote, and that's really profoundly important because in a corporation, just like in a para-bond, your opinion matters to me, I want to know what you're thinking. If I'm looking in, I'll use SAFe terminology, if I'm looking at three epics that could advance our portfolio, and I'm a little unsure about two of those epics, like one of those epics, I'm like, yeah, this is a really good thing, I know a little bit about it, this matters, I'm going to fund this, but the other two I'm not so sure about, well, there's no way I can learn through reading alone what the opinions of other people are, because, again, there's these intangible factors. There's these elements that may not be included in an ROI analysis, it's kind of hard to talk about brand and an ROI analysis - we can, but it's hard, so I want to listen to how other people are talking about things, and through that, I can go, yeah, I can see the value, I didn't see it before, I'm going to join you in funding this. So that's among the ways in which Participatory Budgeting is a little different within the private sector and the public sector and within a company. The only other element that I would add is that Participatory Budgeting gives people the permission to stop funding items that are no longer likely to meet the investment or objectives of the company, or to change minds, and so one of the, again, this is a bit of an overhang in the Agile community, Agile teams are optimised for doing things that are small, things that can fit within a two or three week Sprint. That's great, no criticism there, but our customers and our stakeholders want big things that move the market needle, and the big things that move the market needle don't get done in two or three weeks, in general, and they rarely, like they require multiple teams working multiple weeks to create a really profoundly new important thing. And so what happens though, is that we need to make in a sense funding commitments for these big things, but we also have to have a way to change our mind, and so traditional funding processes, they let us make this big commitment, but they're not good at letting us change our mind, meaning they're not Agile. Participatory Budgeting gives us the best of both worlds. I can sit at the table with you and with our colleagues, we can commit to funding something that's big, but six months later, which is the recommended cadence from SAFe, I can come back to that table and reassess and we can all look at each other, because you know those moments, right, you've had that experience in visiting, because you're like looking around the table and you're like, yeah, this isn't working. And then in traditional funding, we keep funding what's not working because there's no built-in mechanism to easily change it, but in SAFe Participatory Budgeting, you and I can sit at the table and we can look at each other with our colleagues and say, yeah, you know, that initiative just, it's not working, well, let's change our mind, okay, what is the new thing that we can fund? What is the new epic? And that permission is so powerful within a corporation. Ula Ojiaku Thanks for sharing that, and whilst you were speaking, because again, me trying to connect the dots and thinking, for an organisation that has adopted SAFe or it's trying to scale Agility, because like you mentioned, Agile teams are optimised to iteratively develop or deliver, you know, small chunks over time, usually two to three weeks, but, like you said, there is a longer time horizon spanning months, even years into the future, sometimes for those worthwhile, meaty things to be delivered that moves the strategic needle if I may use that buzzword. So, let's say we at that lean portfolio level, we're looking at epics, right, and Participatory Budgeting, we are looking at initiatives on an epic to epic basis per se, where would the Lean Startup Cycle come in here? So is it that Participatory Budgeting could be a mechanism that is used for assessing, okay, this is the MVP features that have been developed and all that, the leading indicators we've gotten, that's presented to the group, and on that basis, we make that pivot or persevere or stop decision, would that fit in? Luke Hohmann Yeah, so let's, I mean, you're close, but let me make a few turns and then it'll click better. First, let's acknowledge that the SAFe approach to the Lean Startup Cycle is not the Eric Ries approach, there are some differences, but let's separate how I fund something from how I evaluate something. So if I'm going to engage in the SAFe Lean Startup Cycle, part of that engagement is to fund an MVP, which is going to prove or disprove a given hypothesis. So that's an expenditure of money. Now there's, if you think about the expenditure of money, there's minimally two steps in this process - there's spending enough money to conduct the experiments, and if those experiments are true, making another commitment to spend money again, that I want to spend it. The reason this is important is, let's say I had three experiments running in parallel and I'm going to use easy round numbers for a large corporation. Let's say I want to run three experiments in parallel, and each experiment costs me a million pounds. Okay. So now let's say that the commercialisation of each of those is an additional amount of money. So the portfolio team sits around the table and says, we have the money, we're going to fund all three. Okay, great. Well, it's an unlikely circumstance, but let's say all three are successful. Well, this is like a venture capitalist, and I have a talk that I give that relates the funding cycle of a venture capitalist to the funding cycle of an LPM team. While it's unlikely, you could have all three become successful, and this is what I call an oversubscribed portfolio. I've got three great initiatives, but I can still only fund one or two of them, I still have to make the choice. Now, of course, I'm going to look at my economics and let's say out of the three initiatives that were successfully proven through their hypothesis, let's say one of them is just clearly not as economically attractive, for whatever reason. Okay, we get rid of that one, now, I've got two, and if I can only fund one of them, and the ROI, the hard ROI is roughly the same, that's when Participatory Budgeting really shines, because we can have those leaders come back into the room, and they can say, which choice do we want to make now? So the evaluative aspect of the MVP is the leading indicators and the results of the proving or disproving of the hypotheses. We separate that from the funding choices, which is where Participatory Budgeting and LPM kick in. Ula Ojiaku Okay. So you've separated the proving or disproving the hypothesis of the feature, some of the features that will probably make up an epic. And you're saying the funding, the decision to fund the epic in the first place is a different conversation. And you've likened it to Venture Capital funding rounds. Where do they connect? Because if they're separate, what's the connecting thread between the two? Luke Hohmann The connected thread is the portfolio process, right? The actual process is the mechanism where we're connecting these things. Ula Ojiaku OK, no, thanks for the portfolio process. But there is something you mentioned, ROI - Return On Investment. And sometimes when you're developing new products, you don't know, you have assumptions. And any ROI, sorry to put it this way, but you're really plucking figures from the air, you know, you're modelling, but there is no certainty because you could hit the mark or you could go way off the mark. So where does that innovation accounting coming into place, especially if it's a product that's yet to make contact with, you know, real life users, the customers. Luke Hohmann Well, let's go back to something you said earlier, and what you talked earlier about was the relationship that you have in market researching customer interaction. In making a forecast, let's go ahead and look at the notion of building a new product within a company, and this is again where the Agile community sometimes doesn't want to look at numbers or quote, unquote get dirty, but we have to, because if I'm going to look at building a new idea, or taking a new idea into a product, I have to have a forecast of its viability. Is it economically viable? Is it a good choice? So innovation accounting is a way to look at certain data, but before, I'm going to steal a page, a quote, from one of my friends, Jeff Patton. The most expensive way to figure this out is to actually build the product. So what can I do that's less expensive than building the product itself? I can still do market research, but maybe I wouldn't do an innovation game, maybe I'd do a formal survey and I use a price point testing mechanism like Van Westendorp Price Point Analysis, which is a series of questions that you ask to triangulate on acceptable price ranges. I can do competitive benchmarking for similar products and services. What are people offering right now in the market? Now that again, if the product is completely novel, doing competitive benchmarking can be really hard. Right now, there's so many people doing streaming that we look at the competitive market, but when Netflix first offered streaming and it was the first one, their best approach was what we call reference pricing, which is, I have a reference price for how much I pay for my DVDs that I'm getting in the mail, I'm going to base my streaming service kind of on the reference pricing of entertainment, although that's not entirely clear that that was the best way to go, because you could also base the reference price on what you're paying for a movie ticket and how many, but then you look at consumption, right, because movie tickets are expensive, so I only go to a movie maybe once every other month, whereas streaming is cheap and so I can change my demand curve by lowering my price. But this is why it's such a hard science is because we have this notion of these swirling factors. Getting specifically back to your question about the price point, I do have to do some market research before I go into the market to get some forecasting and some confidence, and research gives me more confidence, and of course, once I'm in the market, I'll know how effective my research matched the market reality. Maybe my research was misleading, and of course, there's some skill in designing research, as you know, to get answers that have high quality signal strength. Ula Ojiaku Thanks for clarifying. That makes perfect sense to me. Luke Hohmann It's kind of like a forecast saying, like there's a group of Agile people who will say, like, you shouldn't make forecasts. Well, I don't understand that because that's like saying, and people will say, well, I can't predict the future. Well, okay, I can't predict when I'm going to retire, but I'm planning to retire. I don't know the date of my exact retirement, but my wife and I are planning our retirement, and we're saving, we're making certain investment choices for our future, because we expect to have a future together. Now our kids are older than yours. My kids are now in university, and so we're closer to retirement. So what I dislike about the Agile community is people will sometimes say, well, I don't know the certainty of the event, therefore, I can't plan for it. But that's really daft, because there are many places in like, you may not for the listeners, her daughter is a little younger than my kids, but they will be going to university one day, and depending on where they go, that's a financial choice. So you could say, well, I don't know when she's going to university, and I can't predict what university she's going to go to, therefore I'm not going to save any money. Really? That doesn't make no sense. So I really get very upset when you have people in the agile community will say things like road mapping or forecasting is not Agile. It's entirely Agile. How you treat it is Agile or not Agile. Like when my child comes up to me and says, hey, you know about that going to university thing, I was thinking of taking a gap year. Okay, wait a minute, that's a change. That doesn't mean no, it means you're laughing, right? But that's a change. And so we respond to change, but we still have a plan. Ula Ojiaku It makes sense. So the reason, and I completely resonate with everything you said, the reason I raised that ROI and it not being known is that in some situations, people might be tempted to use it to game the budget allocation decision making process. That's why I said you would pluck the ROI. Luke Hohmann Okay, let's talk about that. We actually address this in our recent paper, but I'll give you my personal experience. You are vastly more likely to get bad behaviour on ROI analysis when you do not do Participatory Budgeting, because there's no social construct to prevent bad behaviour. If I'm sitting down at a table and that's virtual or physical, it doesn't matter, but let's take a perfect optimum size for a Participatory Budgeting group. Six people, let's say I'm a Director or a Senior Director in a company, and I'm sitting at a table and there's another Senior Director who's a peer, maybe there's a VP, maybe there's a person from engineering, maybe there's a person from sales and we've got this mix of people and I'm sitting at that table. I am not incented to come in with an inflated ROI because those people are really intelligent and given enough time, they're not going to support my initiative because I'm fibbing, I'm lying. And I have a phrase for this, it's when ROI becomes RO-lie that it's dangerous. And so when I'm sitting at that table, what we find consistently, and one of the clients that we did a fair amount of Participatory Budgeting for years ago with Cisco, what we found was the leaders at Cisco were creating tighter, more believable, and more defensible economic projections, precisely because they knew that they were going to be sitting with their peers, and it didn't matter. It can go both ways. Sometimes people will overestimate the ROI or they underestimate the cost. Same outcome, right? I'm going to overestimate the benefit, and people would be like, yeah, I don't think you can build that product with three teams. You're going to need five or six teams and people go, oh, I can get it done with, you know, 20 people. Yeah, I don't think so, because two years ago, we built this product. It's very similar, and, you know, we thought we could get it done with 20 people and we couldn't. We really needed, you know, a bigger group. So you see the social construct creating a more believable set of results because people come to the Participatory Budgeting session knowing that their peers are in the room. And of course, we think we're smart, so our peers are as smart as we are, we're all smart people, and therefore, the social construct of Participatory Budgeting quite literally creates a better input, which creates a better output. Ula Ojiaku That makes sense, definitely. Thanks for sharing that. I've found that very, very insightful and something I can easily apply. The reasoning behind it, the social pressure, quote unquote, knowing that you're not just going to put the paper forward but you'd have to defend it in a credible, believable way make sense. So just to wrap up now, what books have you found yourself recommending to people the most, and why? Luke Hohmann It's so funny, I get yelled at by my wife for how many books I buy. She'll go like “It's Amazon again. Another book. You know, there's this thing called the library.” Ula Ojiaku You should do Participatory Budgeting for your books then sounds like, sorry. Luke Hohmann No, no, I don't, I'd lose. Gosh, I love so many books. So there's a few books that I consider to be my go-to references and my go-to classics, but I also recommend that people re-read books and sometimes I recommend re-reading books is because you're a different person, and as you age and as you grow and you see things differently and in fact, I'm right now re-reading and of course it goes faster, but I'm re-reading the original Extreme Programming Explained by Kent Beck, a fantastic book. I just finished reading a few new books, but let me let me give you a couple of classics that I think everyone in our field should read and why they should read them. I think everyone should read The Mythical Man-Month by Fred Brooks because he really covers some very profound truths that haven't changed, things like Brooks Law, which is adding programmers to a late project, makes it later. He talks about the structure of teams and how to scale before scaling was big and important and cool. He talks about communication and conceptual integrity and the role of the architect. The other book that I'm going to give, which I hope is different than any book that anyone has ever given you, because it's one of my absolute favourite books and I give them away, is a book called Understanding Comics by Scott McCloud. Comics or graphic novels are an important medium for communication, and when we talk about storytelling and we talk about how to frame information and how to present information, understanding comics is profoundly insightful in terms of how to present, share, show information. A lot of times I think we make things harder than they should be. So when I'm working with executives and some of the clients that I work with personally, when we talk about our epics, we actually will tell stories about the hero's journey and we actually hire comic book artists to help the executives tell their story in a comic form or in a graphic novel form. So I absolutely love understanding comics. I think that that's really a profound book. Of course you mentioned Alex Osterwalder's books, Business Model Generation, Business Model Canvas. Those are fantastic books for Product Managers. I also, just looking at my own bookshelves, of course, Innovation Games for PMs, of course Software Profit Streams because we have to figure out how to create sustainability, but in reality there's so many books that we love and that we share and that we grow together when we're sharing books and I'll add one thing. Please don't only limit your books to technical books. We're humans too. I recently, this week and what I mean recent I mean literally this weekend I was visiting one of my kids in Vermont all the way across the country, and so on the plane ride I finished two books, one was a very profound and deeply written book called Ponyboy. And then another one was a very famous book on a woman protagonist who's successful in the 60s, Lessons in Chemistry, which is a new book that's out, and it was a super fun light read, some interesting lessons of course, because there's always lessons in books, and now if it's okay if I'm not overstepping my boundaries, what would be a book that you'd like me to read? I love to add books to my list. Ula Ojiaku Oh my gosh, I didn't know. You are the first guest ever who's twisted this on me, but I tend to read multiple books at a time. Luke Hohmann Only two. Ula Ojiaku Yeah, so, and I kind of switch, maybe put some on my bedside and you know there's some on my Kindle and in the car, just depending. So I'm reading multiple books at a time, but based on what you've said the one that comes to mind is the new book by Oprah Winfrey and it's titled What Happened to You? Understanding Trauma, because like you said, it's not just about reading technical books and we're human beings and we find out that people behave probably sometimes in ways that are different to us, and it's not about saying what's wrong with you, because there is a story that we might not have been privy to, you know, in terms of their childhood, how they grew up, which affected their worldview and how they are acting, so things don't just suddenly happen. And the question that we have been asked and we sometimes ask of people, and for me, I'm reading it from a parent's perspective because I understand that even more so that my actions, my choices, they play a huge, you know, part in shaping my children. So it's not saying what's wrong with you? You say, you know, what happened to you? And it traces back to, based on research, because she wrote it with a renowned psychologist, I don't know his field but a renowned psychologist, so neuroscience-based psychological research on human beings, attachment theory and all that, just showing how early childhood experiences, even as early as maybe a few months old, tend to affect people well into adulthood. So that would be my recommendation. Luke Hohmann Thank you so much. That's a gift. Ula Ojiaku Thank you. You're the first person to ask me. So, my pleasure. So, before we go to the final words, where can the audience find you, because you have a wealth of knowledge, a wealth of experience, and I am sure that people would want to get in touch with you, so how can they do this please? Luke Hohmann Yeah, well, they can get me on LinkedIn and they can find me at Applied Frameworks. I tell you, I teach classes that are known to be very profound because we always reserve, myself and the instructors at Applied Frameworks, we have very strong commitments to reserving class time for what we call the parking lot or the ask me anything question, which are many times after I've covered the core material in the class, having the opportunity to really frame how to apply something is really important. So I would definitely encourage people to take one of my classes because you'll not get the material, you'll get the reasons behind the material, which means you can apply it, but you'll also be able to ask us questions and our commitment as a company is you can ask us anything and if we don't know the answer, we'll help you find it. We'll help you find the expert or the person that you need talk to, to help you out and be successful. And then, and I think in terms of final words, I will simply ask people to remember that we get to work in the most amazing field building things for other people and it's joyful work, and we, one of my phrases is you're not doing Agile, if you're not having fun at work, there's something really wrong, there's something missing, yeah we need to retrospect and we need to improve and we need to reflect and all those important things, absolutely, but we should allow ourselves to experience the joy of serving others and being of service and building things that matter. Ula Ojiaku I love the concept of joyful Agile and getting joy in building things that matter, serving people and may I add also working together with amazing people, and for me it's been a joyful conversation with you, Luke, I really appreciate you making the time, I am definitely richer and more enlightened as a result of this conversation, so thank you so much once more. Luke Hohmann Thank you so much for having me here, thank you everyone for listening with us. Ula Ojiaku  My pleasure. That's all we have for now. Thanks for listening. If you liked this show, do subscribe at www.agileinnovationleaders.com or your favourite podcast provider. Also share with friends and do leave a review on iTunes. This would help others find this show. I'd also love to hear from you, so please drop me an email at ula@agileinnovationleaders.com Take care and God bless!   

We're joined by Bob Sutton, an organizational psychologist and best-selling author, and Rebecca Hinds, the head of the work innovation lab at Asana. Bob and Rebecca highlight the need to shift from an addition mindset to a subtraction mindset to combat workplace overwhelm. They delve into the effectiveness of combining bottom-down and top-up strategies in creating changes in the workplace. Lastly, they emphasize the importance of continuously evaluating your work practices, especially with the rapidly changing tech landscape.02:55 Understanding Corporate Overwhelm04:10 The Exhaustion of Leadership Positions06:14 The Role of Technology in Overwhelm06:24 The Impact of the Pandemic on Tech Investments08:44 The Importance of a People-First Strategy11:38 The Balance Between Bottom-Up and Top-Down Strategies11:53 The Role of Meetings and Collaboration Tools21:18 The Importance of Team Resets and Refreshes27:00 The Mythical Man Month and the Problem of Overstaffing27:29 Apple's Unique Approach to Team Management27:48 The Consequences of Overhiring in Tech28:09 The Pitfalls of Spending Money as a Substitute for Action28:37 The Human Tendency Towards Addition and Its Impact on Organizations30:05 The Problem of Rewarding Addition Over Subtraction31:02 Maintaining a Successful Subtraction Mindset40:16 The Power of Constraints in Organizational Change42:39 The Importance of Continuously Evaluating Work PracticesEpisode ResourcesVisual GuideYouTubeTo learn more about our guests and their work:Bob SuttonRebecca HindsThe Friction podcastBook (available for pre-order):The Friction Project: How Smart Leaders Make the Right Things Easier and the Wrong Things HarderThe original HBR articles: Are Collaboration Tools Overwhelming Your Team?Meeting Overload is a Fixable ProblemProducer: Podrick Sonicson To learn more about New Rules for Work:WebsiteLabs NewsletterEvent: 2024 Intent to Impact in Austin, TX

Jupyter Notebooks and Jupyter Lab have to be one of the most important parts of Python when it comes to bring new users to the Python ecosystem and certainly for the day to day work of data scientists and general scientists who have made some of the biggest discoveries of recent times. And that platform has recently gotten a major upgrade with JupyterLab 4 released and Jupyter Notebook being significantly reworked to be based on the changes from JupyterLab as well. We have an excellent panel of guests, Sylvain Corlay, Frederic Collonval, Jeremy Tuloup, and Afshin Darian here to tell us what's new in these and other parts of the Jupyter ecosystem. Links from the show Guests Sylvain Corlay Frederic Collonval Jeremy Tuloup Afshin Darian JupyterLab 4.0 is Here: blog.jupyter.org Announcing Jupyter Notebook 7: blog.jupyter.org JupyterCon 2023 Videos: youtube.com Jupyterlite: github.com Download JupyterLab Desktop: github.com Mythical Man Month Book: wikipedia.org Blender in Jupyter: twitter.com Watch this episode on YouTube: youtube.com Episode transcripts: talkpython.fm --- Stay in touch with us --- Subscribe to us on YouTube: youtube.com Follow Talk Python on Mastodon: talkpython Follow Michael on Mastodon: mkennedy Sponsors Phylum Python Tutor Talk Python Training

Welcome back to Season 2 of ByteSized RSE, a program supported by Universe-HPC http://www.universe-hpc.ac.uk .The subject for this session is: Software Estimation and some ideas on how to approach it. Things mentioned in this episode:The Mythical Man Month, Frederick Brooks, 1975, Software Estimation, Steve McConnell, https://www.google.co.uk/books/edition/Software_Estimation/U5VCAwAAQBAJ?hl=en&gbpv=0https://rclayton.silvrback.com/software-estimation-is-a-losing-game a critical view on software estimation by Richard Claytonhttps://www.stepsize.com/blog/the-best-software-estimation-techniques an overview of some estimation techniqueshttps://en.wikipedia.org/wiki/Planning_poker The Planning Pokerhttps://en.wikipedia.org/wiki/Three-point_estimation 3-point estimationByte-sized RSE is presented in collaboration with the UNIVERSE-HPC project.https://www.imperial.ac.uk/computational-methods/rse/events/byte-sized-rse/ByteSized RSE link to Imperial CollegeAudio clips:Frying sound: https://www.fesliyanstudios.com/royalty-free-sound-effects-download/frying-cooking-food-34"Golden Girls" S6E15:  one of the many YouTube videos with Bea Arthur's (aka Dorothy Zbornak) best lines. Support the Show.Thank you for listening and your ongoing support. It means the world to us! Support the show on Patreon https://www.patreon.com/codeforthought Get in touch: Email mailto:code4thought@proton.me UK RSE Slack (ukrse.slack.com): @code4thought or @piddie US RSE Slack (usrse.slack.com): @Peter Schmidt Mastadon: https://fosstodon.org/@code4thought or @code4thought@fosstodon.org LinkedIn: https://www.linkedin.com/in/pweschmidt/ (personal Profile)LinkedIn: https://www.linkedin.com/company/codeforthought/ (Code for Thought Profile) This podcast is licensed under the Creative Commons Licence: https://creativecommons.org/licenses/by-sa/4.0/

In this episode, we speak with Steven Sinofsky, currently a board partner at Andreessen Horowitz and previously of Microsoft. We discuss what it was like shipping code at Microsoft in the early days, what he learned from Bill Gates, how it applies to software development today, what the big Windows 8 rewrite was like, and why the Copilot AI naysayers are completely wrong. Although the software landscape has changed dramatically since Steven's early days at Microsoft in the 80s, he shares some of the lessons he learned along the way which are still as relevant today as they were back then. Hosted by David Mytton (Console) and Jean Yang (Akita Software).Things mentioned:MicrosoftWindows 8Copilot Cornell UniversityIBMHalt and Catch FireAppleJon DeVaanWebflowMythical Man-Month, The: Essays on Software EngineeringBill Gates“A Hard Line on Software” (Video)Jensen HarrisHardcore SoftwareChatGPTBingChatGPT on 60 MinutesM2 Mac MiniMacBook AirOne Strategy: Organization, Planning, and Decision MakingSubstackABOUT STEVEN SINOFSKYSteven Sinofsky is an investor, a board partner at Andreessen Horowitz, a general advisor, and a self-described “person-about-town” in Silicon Valley. Shortly after he graduated from Cornell University, he became a software design engineer at Microsoft back in 1989. In his time at the company, he oversaw six major releases of the full range of Office apps and servers in his role as a senior executive. He also worked on Windows 7 and the Windows 8 rewrite as the president of the Windows division. He is a co-author of the book One Strategy: Organization, Planning, and Decision Making, as well as the writer of Hardcore Software, a Substack newsletter about the rise and fall of the PC revolution.Highlights:Steven Sinofsky: Bill was super interesting. He was, in a sense, this very interesting combination of business strategy, product strategy, and technology strategy. And whenever he would really push it, he was most comfortable trying to be a technology strategist. And to him, that was all about architecture. And so architecture, if you read a book like Fred Brooks, Mythical Man-Month, architecture is everything. Architecture in software is like this Nirvana.— [0:22:37 - 0:23:08]Steven Sinofsky: And the beauty of how Apple managed their operating system was they just didn't add a lot of features. But we had a team five times as big, adding features every release, and it was just not getting— My measure of success is not “Did we get the release done?” but “Was it making people do new things with the product?” And Windows had long stopped doing that. The ecosystem of software and hardware had probably died around 2000. And so when it came time to do Windows 8 — and obviously Hardcore Software has the whole timeline and all this stuff — but the thing we really wanted to do was take the product and build on it and all the things that were great about it, but bring it into a new era of computing from top to bottom or what we said was “from the chipset to the experience".— [0:28:43 - 0:29:34]Let us know what you think on Twitter:https://twitter.com/consoledotdevhttps://twitter.com/davidmyttonhttps://twitter.com/jeanqasaurOr by email: hello@console.dev

Jimmy and I have each read this paper a handful of times, and each time our impressions have flip-flopped between "hate it so much" and "damn that's good". There really are two sides to this one. Two reads, both fair, both worth discussing: one of them within "the frame", and one of them outside "the frame". So given that larger-than-normal surface for discursive traversal, it's no surprise that this episode is, just, like, intimidatingly long. This one is so, so long, friends. See these withered muscles and pale skin? That's how much time I spent in Ableton Live this month. I just want to see my family. No matter how you feel about Brooks, our thorough deconstruction down to the nuts and bolts of this seminal classic will leave you holding a ziplock bag full of cool air and wondering to yourself, "Wait, this is philosophy? And this is the future we were promised? Well, I guess I'd better go program a computer now before it's too late and I never exist." For the next episode, we're reading a fish wearing a bathrobe. Sorry, it's late and I'm sick, and I have to write something, you know? Links: Fred Brooks also wrote the Mythical Man-Month, which we considered also discussing on this episode but thank goodness we didn't. Also, Fred Brooks passed away recently. We didn't mention it on the show, but it's worth remarking upon. RIP, and thanks for fighting the good fight, Fred. I still think you're wrong about spatial programming, but Jimmy agrees with you, so you can probably rest easy since between the two of us he's definitely the more in touch with the meaning of life. The Oxide and Friends podcast recorded an episode of predictions. Jimmy's Aphantasia motivates some of his desire for FoC tools. Don't miss the previous episode on Peter Naur's Programming as Theory Building, since Ivan references it whilst digging his own grave. Jimmy uses Muse for his notes, so he can highlight important things in two colors — yes, two colors at the same time. Living in the future. For the Shadow of the Colossus link, here's an incredible speedrun of the game. Skip to 10:20-ish for a great programming is like standing on the shoulders of a trembling giant moment. Mu is a project by Kartik Agaram, in which he strips computing down to the studs and rebuilds it with a more intentional design. “Running the code you want to run, and nothing else.” “Is it a good-bad movie, a bad-bad movie, or a movie you kinda liked?” Ivan did some research. Really wish Marco and Casey didn't let him. Jimmy did an attack action so as to be rid of Brook's awful invisibility nonsense. Awful. As promised, here's a link in the show notes to something something Brian Cantrill, Moore's Law, Bryan Adams, something something. Dynamicland, baby! Here's just one example of the racist, sexist results that current AI tools produce when you train them on the internet. Garbage in, garbage out — a real tar pit. AI tools aren't for deciding what to say; at best, they'll help with how to say it. Gray Crawford is one of the first people I saw posting ML prompts what feels like an eternity ago, back when the results all looked like blurry goop but like… blurry goop with potential. Not sure of a good link for Jimmy's reference that Age of Empires II used expert systems for the AI, but here's a video that talks about the AI in the game and even shows some Lisp code. Idris is a language that has a bit of an “automatic programming” feel. The visual programming that shall not be named. When people started putting massive numbers of transistors into a single chip (eg: CPU, RAM, etc) they called that process Very Large Scale Integration (VLSI). Also, remember that scene in the first episode of Halt and Catch Fire when the hunky Steve Jobs-looking guy said "VLSI" to impress the girl from the only good episode of Black Mirror? I'm still cringing. Sally Haslanger is a modern day philosopher and feminist who works with accident and essence despite their problematic past. Music featured in this episode: Never, a song I wrote and recorded on Tuesday after finally cleaning my disgusting wind organ. It was like Hollow Knight in there. Get in touch, ask us questions, send us old family recipes: Ivan: Mastodon • Email Jimmy: Mastodon • Twitter Or just DM us in the FoC Slack. futureofcoding.org/episodes/062See omnystudio.com/listener for privacy information.

Mike, Seth, & Tommy dive back into the Mythical Man-Month series and tackle the idea of the Second System Effect and how it relates to Power BI development. The Second System Effect is the tendency for a developer to "err on the side of over embellishment when planning their second project". This usually occurs when small, elegant, and successful systems can become over-developed and bloated due to inflated expectations and overconfidence. How does this relate to our development and report lifecycle? Links: https://cszy.medium.com/the-second-system-problem-and-a-practical-solution-c2514d67a7d6 https://robertgreiner.com/the-second-system-effect/ https://medium.com/holes/second-system-effect-1a4a1cf76836 Get in touch: Send in your questions or topics you want us to discuss by tweeting to @PowerBITips with the hashtag #empMailbag or submit on the PowerBI.tips Podcast Page. Visit PowerBI.tips: https://powerbi.tips/ Watch the episodes live every Tuesday and Thursday morning at 730am CST on YouTube: https://www.youtube.com/powerbitips Subscribe on Spotify: https://open.spotify.com/show/230fp78XmHHRXTiYICRLVv Subscribe on Apple: https://podcasts.apple.com/us/podcast/explicit-measures-podcast/id1568944083‎ Check Out Community Jam: https://jam.powerbi.tips Follow Mike: https://www.linkedin.com/in/michaelcarlo/ Follow Seth: https://www.linkedin.com/in/seth-bauer/ Follow Tommy: https://www.linkedin.com/in/tommypuglia/

The guys go back to the Mythical Man Month and speaking on an important topic: Plan to Throw One Away. The idea back in the day and still true now is why do not focus enough on a prototype, both in design and in modeling. https://course.ccs.neu.edu/cs5500f14/Notes/Prototyping1/planToThrowOneAway.html Get in touch: Send in your questions or topics you want us to discuss by tweeting to @PowerBITips with the hashtag #empMailbag or submit on the PowerBI.tips Podcast Page. Visit PowerBI.tips: https://powerbi.tips/ Watch the episodes live every Tuesday and Thursday morning at 730am CST on YouTube: https://www.youtube.com/powerbitips Subscribe on Spotify: https://open.spotify.com/show/230fp78XmHHRXTiYICRLVv Subscribe on Apple: https://podcasts.apple.com/us/podcast/explicit-measures-podcast/id1568944083‎ Check Out Community Jam: https://jam.powerbi.tips Follow Mike: https://www.linkedin.com/in/michaelcarlo/ Follow Seth: https://www.linkedin.com/in/seth-bauer/ Follow Tommy: https://www.linkedin.com/in/tommypuglia/

Programming has transitioned from machine code to punch cards, from assembly to high-level languages, and from C to dynamic languages, then to Python. Now, we are heading into the next frontier with artificial intelligence (AI) technology, and today's guest, Amjad Masad, is one of the leaders designing the future of software engineering. During this episode, Amjad explains how the challenges he came up against during his early days as a programmer inspired him to make programming more accessible and how he is turning that dream into a reality through his privately-held company, Replit. Among other things, you'll hear why Replit might appeal to both novice and highly experienced programmers, their “code as data” approach, the exponential growth that the company has experienced since its founding in 2016, and why Amjad believes that in the coming years, a single software developer might have the same productivity level as a 100 software developers today! “Our mission is to power the next generation of software development and rebuild something that is collaborative by default, instance ubiquitous and AI-powered.” — @amasad Key Points From This Episode: Amjad Masad, the co-founder and CEO of Replit, shares what the company does and the vision that drives them. The problem with the programming world that inspired Amjad to found Replit. What the Replit prototype was like in its infancy. Amjad's breakthrough that went viral. The early years of Amjad's career. How Replit has grown since its founding in 2016. Value that Replit aims to provide to beginner and senior programmers. Where the idea of using code as data originated. How Replit acquired its name. Impacts of the Transformer revolution. How Transformers are programmed. Amjad explains what his Ghostwriter program does. Valuable lessons Amjad learned from The Mythical Man-Month. Software engineering's latest “silver bullet.” What Amjad sees as the role of software engineers in the future. A high-level overview of the history of programming and the developments that Amjad expects to see in the coming years. Factors that might make Replit stand out from its competitors. What Amjad wishes he knew from day one of building Replit.

Based on a link from Paul Turley's blog (and an episode on getting your data into shape). The idea behind this is observations from software engineers not delivering on time despite adding more resources, with the possibility of measuring quality work in "man-months" is a myth. How much of this relates to Power BI development and data integration struggles? When we are so deep in the technical specs, data management, and modeling, is the solution more BI resources? Link to reference page: https://en.wikipedia.org/wiki/The_Mythical_Man-Month Get in touch: Send in your questions or topics you want us to discuss by tweeting to @PowerBITips with the hashtag #empMailbag or submit on the PowerBI.tips Podcast Page. Visit PowerBI.tips: https://powerbi.tips/ Watch the episodes live every Tuesday and Thursday morning at 730am CST on YouTube: https://www.youtube.com/powerbitips Subscribe on Spotify: https://open.spotify.com/show/230fp78XmHHRXTiYICRLVv Subscribe on Apple: https://podcasts.apple.com/us/podcast/explicit-measures-podcast/id1568944083‎ Check Out Community Jam: https://jam.powerbi.tips Follow Mike: https://www.linkedin.com/in/michaelcarlo/ Follow Seth: https://www.linkedin.com/in/seth-bauer/ Follow Tommy: https://www.linkedin.com/in/tommypuglia/

Do high budgets for films and television series lead to high-quality productions? Or does spending too much money actually make the end product worse? In this week's podcast, we discuss big budgets. We use Amazon's Rings of Power series to question whether a large budget is a necessary condition for success in film and television. We discuss the economic theory of resource scarcity, hubristic planning, white elephants, the Mythical Man-Month, and the Swedish warship Vasa. We widen the lens of the conversation to ask how large budgets affect decision-making and even draw an analogy between large film budgets and military spending. Finally, we share some of our favourite high and low-budget films. A few things we mentioned in this podcast: - Big-budget films are getting worse — and we can prove it https://www.vox.com/2016/4/4/11351788/batman-v-superman-terrible-reviews - Why movies cost so much to make (Investopedia) https://www.investopedia.com/financial-edge/0611/why-movies-cost-so-much-to-make.aspx - Movies Decoded: The complex relationship between budgets, box office and ratings https://medium.com/cinenation-show/2009-movie-correlations-between-ratings-box-office-and-production-budget-2dc68ce7db27 - The Mythical Man-Month https://en.wikipedia.org/wiki/The_Mythical_Man-Month For more information on Aleph Insights visit our website https://alephinsights.com or to get in touch about our podcast email podcast@alephinsights.com Image: Peter J Vost via Wikimedia Commons

Stephen Wolfram answers questions from his viewers about the history science and technology as part of an unscripted livestream series, also available on YouTube here: https://wolfr.am/youtube-sw-qa Questions include: Are you familiar with Norbert Wiener's work? Is it relevant to current computer science at all? - Do you have any interesting stories/comments about Frederick P. Brooks? - What did you learn from The Mythical Man Month? (and when did you first read it?) - Dear Dr. Wolfram, what is your opinion on John Backus' lecture from 1977: "Can Programming be Liberated from the von Neumann Style?"? - Was it even one cornerstone for your thinking? - Did general system theory and systems theory die out and why? - Does functional programming count as liberation from von Neumann style? - Do you think scientific software development has a very different development practice? - Are you saying that flowchart descriptions of algorithms and computations originate from systems theory/general systems theory? I always thought that is just a part of modern computer science. - Regarding what you just mentioned about education and teaching programming, what are your thoughts generally on how far our higher level languages are abstracting more and more away from the core metal? Do you worry about future generations of programmers not understanding core fundamentals and that we might come become stunted in terms of coming up with new languages and computing paradigms due to a lack of expertise? - Were you ever involved in the development of a kind of software that you now think might actually be morally questionable in some sense?

Help your team become more efficient by splitting up their tasks more effectively. Casey Stanton is bringing the concept of partitionable and unpartitionable tasks to the center stage to show how you may be wasting time and effort on tasks while actually making them take longer to finish. You'll learn how to recognize the different types of tasks, plan for a more efficient quarter and choose the right clients to serve as a Fractional CMO.   Takeaways: Brook's Law demonstrates that adding more capacity to a project that's failing actually extends the timeline it takes to produce a quality product. There are two main types of tasks, partitionable and unpartitionable. Unpartitionable tasks do not see an increased acceleration in completion with added manpower. Whereas, partitionable tasks are completed faster with more hands involved.  Some tasks, like writing persuasive copy, are unpartitionable because they require a singular voice and vision. When you add more people to a team, you increase the amount of necessary intercommunication within the team exponentially. As a Fractional CMO, you should know what tasks are unpartitionable and how you can help the people working on those tasks without getting in their way. When doing quarterly planning, consider what tasks are partitionable or not and what the time needed to complete them actually is.  As a Fractional CMO, the Three C's you need to know a potential client has are cash, capability, and capacity.   Quote of the Show: “It's the unpartitionable tasks that are the tasks that do not scale with more human capacity”  - Casey Stanton   Links: Twitter: https://twitter.com/CaseyStanton LinkedIn: https://www.linkedin.com/in/caseystanton/ Website: https://cmox.co/call   Shout Outs: The Mythical Man-Month by Fred Brooks   Ways to Tune In: Amazon Music: https://music.amazon.com/podcasts/039bc2d6-c1b5-4ced-ac2a-437e69546e7c/fractional-cmo-show Apple Podcast: https://podcasts.apple.com/us/podcast/fractional-cmo-show/id1592740671 Spotify: https://open.spotify.com/show/1HGwnjsXA4c4gYQvj4w53E?si=bd6e0908e25749ec Google Podcast: https://podcasts.google.com/feed/aHR0cHM6Ly9mcmFjdGlvbmFsY21vLmxpYnN5bi5jb20vcnNz?sa=X&ved=2ahUKEwjlpNDTveb0AhUXEFkFHaZcDtYQ9sEGegQIARAC YouTube: https://youtu.be/ydFEPv40vts

Description: Squirrel and Jeffrey ponder the seemingly forgot lore of their younger days and ask how those lessons will make it to the next generation. Or does such a fast moving industry have no time to learn from the past? SHOW LINKS: - Livestream: https://squirrelsquadron.com/events/2022/04-21-continuous-integration.html - Doing the impossible 50 times a day: http://timothyfitz.com/2009/02/10/continuous-deployment-at-imvu-doing-the-impossible-fifty-times-a-day/ - Refactoring Databases book: https://www.databaserefactoring.com - Working Effectively with Legacy Code: https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052 - Mythical Man-Month: https://en.wikipedia.org/wiki/The_Mythical_Man-Month - Peopleware: https://bookshop.org/books/peopleware-productive-projects-and-teams-revised/9780321934116 - Code complete: https://bookshop.org/books/code-complete/9780735619678 - Pragmatic programmer: https://en.wikipedia.org/wiki/The_Pragmatic_Programmer - Agile Conversations Slack: https://join.slack.com/t/agile-conversations/shared_invite/zt-17ut4px4y-gvPXpbYhf2tf0nvzZN1u5A --- Our book, Agile Conversations, is out now! See https://agileconversations.com where you can order your copy and get a free video when you join our mailing list! We'd love to hear any thoughts, ideas, or feedback you have about the show. 
 Email us at info@agileconversations.com

In this episode, we are talking with Mickey W Mantle about how programming managers should manage upward, outward and inward to become more effective.  Mickey is the co-author of Managing the Unmanageable: Rules, Tools, and Insights for managing software people and teams. He has been developing software for more than forty years as a software and hardware product creator, manager, and executive for companies that include Evans & Sutherland, Pixar, Broderbund, and Gracenote. He currently develops mobile/tablet applications, writes, and consults. Managing The Unmanageable Frederick Brooks, The Mythical Man-Month  

The phrasal template random acts of ________ is clearly one of my favorites. I seem to have used it 20+ times on Twitter in the last few years. Here are the actual instances: random acts of ontolog… https://www.ribbonfarm.com/2022/01/06/random-acts-of-x/ used it 20+ times on Twittertweeted a promptThe Science of Muddling ThroughObliquitywhat theory is not, theorizing isFrederick Brooks’ idea that you should “plan to throw one away”counter-argument

In this week's pod, we welcomed Fred Schebesta to talk about whether blockchain can improve project delivery! Fred Schebesta is the epitome of entrepreneurialism. An obsession for hyper success, Fred is passionate about disruptive innovation and inspires the startup community through his achievements and learnings. The Australian-born entrepreneur is the co-founder of Finder, a global personal finance comparison website, which attracts over 10 million visitors each month, over 400 staff across six offices, and can be found in over 80 countries. For the past 2 years, Fred has been leading the Finder App, which is an Australian-first innovation that combines personal finance management with automated comparison. It connects a user's bank accounts, analyses insights and sends automated alerts on when they can compare products and potentially save money. Launched in March 2020 with plans to roll out in the USA and UK early next year. The main topics we discussed on the podcast were as follows: · In its simplest form, a blockchain is an internet-based database that anyone can access · Most projects shouldn't use blockchain. It's expensive, slow, cumbersome and emerging! · Blockchains are useful where you need to prove project data to the public · A database is a cheaper, more effective solution for projects · Bitcoin could change the way we incentivise people working on projects · Blockchain could be used to create smart contracts (self-executing contracts). This may not work on qualitative outcomes that occur on major construction projects. It works better where there are binary outcomes. · Be remarkable! Make sure people are willing and want to comment to their friends about ti · In most businesses, the rational idea is not to innovate and keep doing what they're good at. At some stage businesses will experience disruption Blockchain is most relevant on airplane and train manufacturing projects, high value but process-driven projects · Plenty of major engineering projects have been delivered without technology but with solid project management principles. Have Project Management skills ever really changed since the Pyramids were built? · Technology isn't necessarily an enabler for good project management · Innovation gets killed by antibodies within organisations! · When creating new technology, you need to ignore the KPI's. Deliver or don't! · We're likely to see digital industrial revolutions in the next year ` · Write down what a project will do, also write down what the project won't do Here are some links to the topics we discussed: · Finder - https://www.finder.com.au/ · Mythical Man-Month - https://www.amazon.co.uk/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959 · Phoenix Project - https://itrevolution.com/the-phoenix-project/ Book recommendation: Common Stocks and Uncommon Profits https://www.amazon.co.uk/Uncommon-Profits-Writings-Investment-Classics/dp/0471445509 Tune in next week when we're re-joined by Paul Goodge and Warren Beardall to discuss the philosophy of project management. For more information, blogs or to support our charities visit www.projectchatterpodcast.com If you'd like to sponsor the podcast get in touch via our website. You can also leave us a voice message via our anchor page and let us know if there's something or someone specific that you would like on the podcast. Proudly sponsored by: PlanAcademy.com | InEight.com | JustDo.com Stay safe, be disruptive, and have fun doing it! #ProjectManagement #Blockchain #PMO #ProjectControls #Leadership #Culture #ProjectCertifications --- Send in a voice message: https://anchor.fm/project-chatter-podcast/message

This interview was recorded for the GOTO Book Club.http://gotopia.tech/bookclubAdam Tornhill - Author of "Software Design X-Rays" and Founder & CTO at CodeSceneSven Johann - Senior Consultant at INNOQ and Podcast Host at CaSEDESCRIPTIONThere's a link between how organizations write code and how teams work together. Adam Tornhill can make this link visible to help improve your team's code and your organization's work. The interview is based on Adam's book "Software Design X-Rays": https://amzn.to/3DEeEnIRead the full transcription of the interview here:https://gotopia.tech/bookclub/episodes/behavioral-code-analysishttps://gotopia.tech/bookclub/episodes/behavioral-code-analysis-part2RECOMMENDED BOOKSAdam Tornhill • Software Design X-Rays • https://amzn.to/3DEeEnIAdam Tornhill • Your Code as a Crime Scene • https://amzn.to/3FI5E2VAdam Tornhill • Lisp for the Web • https://leanpub.com/lispwebAdam Tornhill • Patterns in C • https://leanpub.com/patternsincMatthew Skelton & Manuel Pais • Team Topologies • http://amzn.to/3sVLyLQJohn Ousterhout • A Philosophy of Software Design • https://amzn.to/3DBP9DCDave Thomas & Andy Hunt • The Pragmatic Programmer • https://amzn.to/3azvUy3Fred Brooks Jr. • The Mythical Man-Month • https://amzn.to/31NJc5Chttps://twitter.com/GOTOconhttps://www.linkedin.com/company/goto-https://www.facebook.com/GOTOConferencesLooking for a unique learning experience?Attend the next GOTO conference near you! Get your ticket at https://gotopia.techSUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted almost daily.https://www.youtube.com/user/GotoConferences/?sub_confirmation=1

This time the title says it all: The best books about software engineers, and for software engineers, from timeless classics to books that everybody knows and nobdy reads, to books that are not about software development at all but still highly recommended for programmers.   The giant list of links to all the recommended software engineering books mentioned: https://bignerdranch.com/books/ios-programming-the-big-nerd-ranch-guide-7th-edition/ https://www.newline.co/ng-book/2/ https://www.oreilly.com/library/view/effective-java/9780134686097/ http://therubyway.io/ https://git-scm.com/book/en/v2 https://pragprog.com/titles/utj2/pragmatic-unit-testing-in-java-8-with-junit/ https://www.postgresql.org/docs/ https://pragprog.com/titles/pwrdata/seven-databases-in-seven-weeks-second-edition/ https://nostarch.com/howlinuxworks3 http://regex.info/book.html https://www.algorist.com/ https://www.oreilly.com/library/view/code-complete-second/0735619670/ https://pragprog.com/titles/tpp20/the-pragmatic-programmer-20th-anniversary-edition/ https://www.goodreads.com/book/show/3735293-clean-code https://martinfowler.com/books/refactoring.html https://www.goodreads.com/book/show/85009.Design_Patterns https://www.oreilly.com/library/view/head-first-design/9781492077992/ https://www.oreilly.com/library/view/head-first-object-oriented/0596008678/ https://www.dddcommunity.org/book/evans_2003/ https://www.infoq.com/minibooks/domain-driven-design-quickly/ https://www.oreilly.com/library/view/domain-driven-design-distilled/9780134434964/ https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://martinfowler.com/architecture/ https://pragprog.com/titles/mnee2/release-it-second-edition/ https://dataintensive.net/ https://hpbn.co/ https://www.joelonsoftware.com/category/uibook/ https://www.goodreads.com/book/show/41790.User_Interface_Design_for_Programmers https://sensible.com/dont-make-me-think/ https://www.oreilly.com/library/view/the-non-designers-design/9780133966350/ https://en.wikipedia.org/wiki/The_Mythical_Man-Month https://en.wikipedia.org/wiki/Peopleware:_Productive_Projects_and_Teams https://www.pearson.com/us/higher-education/product/Pindyck-Microeconomics-9th-Edition/9780134184241.html https://freakonomics.com/books/ https://timharford.com/books/undercovereconomist/ https://www.kalzumeus.com/greatest-hits/ https://twitter.com/patio11 https://news.ycombinator.com/user?id=patio11 https://stripe.com/en-de/guides https://press.stripe.com/

In this episode we talk about estimations ... again. Managing Up: Where Everything is Made Up and the Points Don't Matter (https://managingup.show/episodes/ae6a210b) The Mythical Man Month (https://www.goodreads.com/book/show/13629.The_Mythical_Man_Month) by Frederick P. Brooks Jr. Waltzing with Bears (https://www.goodreads.com/book/show/665153.Waltzing_with_Bears) by Tom DeMarco, Timothy R. Lister Software estimation without guessing (https://www.goodreads.com/book/show/53104134-software-estimation-without-guessing) by George Dinwiddie How to Measure Anything (https://www.goodreads.com/book/show/444653) by Douglas W. Hubbard You can reach us via email at hosts@expandingbeyond.it (mailto:hosts@expandingbeyond.it). You can follow us on Twitter at @podcast_eb (https://twitter.com/podcast_eb). Where to find Monica on the internet: Website: monicag.me (https://monicag.me/) Twitter: @KFMolli (https://twitter.com/KFMolli) Github: @nirnaeth (https://github.com/nirnaeth) Blog: dev.to/nirnaeth (https://dev.to/nirnaeth) Where to find Urban on the internet: Twitter: @ujh (https://twitter.com/ujh) Github: @ujh (https://github.com/ujh/) Blog: urbanhafner.com (https://urbanhafner.com/) The intro and outro music is Our Big Adventure (https://freemusicarchive.org/music/Scott_Holmes/Happy_Music/Our_Big_Adventure) by Scott Holmes (https://freemusicarchive.org/music/Scott_Holmes). It's licensed under Attribution-NonCommercial 4.0 International (CC BY-NC 4.0) (https://creativecommons.org/licenses/by-nc/4.0/).

We discuss estimations, what they are good for as well as legacy code. 2000 downloads Tweet (https://twitter.com/ujh/status/1437659817527627778?s=20) 2000 downloads on LinkedIn (https://www.linkedin.com/feed/update/urn:li:activity:6843425340065357824/) The Mythical Man Month (https://en.wikipedia.org/wiki/The_Mythical_Man-Month) How can a developer estimate time and effort? (https://forasoft.medium.com/how-can-a-developer-estimate-time-and-effort-eef2904d301c) https://www.howtomeasureanything.com/ (https://www.howtomeasureanything.com/) You can reach us via email at hosts@expandingbeyond.it (mailto:hosts@expandingbeyond.it). You can follow us on Twitter at @podcast_eb (https://twitter.com/podcast_eb). Where to find Monica on the internet: Website: monicag.me (https://monicag.me/) Twitter: @KFMolli (https://twitter.com/KFMolli) Github: @nirnaeth (https://github.com/nirnaeth) Blog: dev.to/nirnaeth (https://dev.to/nirnaeth) Where to find Urban on the internet: Twitter: @ujh (https://twitter.com/ujh) Github: @ujh (https://github.com/ujh/) Blog: urbanhafner.com (https://urbanhafner.com/) The intro and outro music is Our Big Adventure (https://freemusicarchive.org/music/Scott_Holmes/Happy_Music/Our_Big_Adventure) by Scott Holmes (https://freemusicarchive.org/music/Scott_Holmes). It's licensed under Attribution-NonCommercial 4.0 International (CC BY-NC 4.0) (https://creativecommons.org/licenses/by-nc/4.0/).

Colin is Co-founder and CEO at LayerCI, a company which helps software developers efficiently review changes to websites. He graduated with a triple major (math, stats, computer science) from the University of Toronto and has worked as a tech executive for five years. LinkedIn: https://www.linkedin.com/in/colinchartier/ Website: https://layerci.com/ --- Support this podcast: https://anchor.fm/geeksofthevalley/support

I often think of companies in relation to their contribution to the next evolution in the forking and merging of disciplines in computing that brought us to where we are today. Many companies have multiple contributions. Few have as many such contributions as Apple. But there was a time when they didn't seem so innovative.  This lost decade began about half way through the tenure of John Sculley and can be seen through the lens of the CEOs. There was Sculley, CEO from 1983 to 1993. Co-founders and spiritual centers of Apple, Steve Jobs and Steve Wozniak, left Apple in 1985. Jobs to create NeXT and Wozniak to jump into a variety of companies like making universal remotes, wireless GPS trackers, and and other adventures.  This meant Sculley was finally in a position to be fully in charge of Apple. His era would see sales 10x from $800 million to $8 billion. Operationally, he was one of the more adept at cash management, putting $2 billion in the bank by 1993. Suddenly the vision of Steve Jobs was paying off. That original Mac started to sell and grow markets. But during this time, first the IBM PC and then the clones, all powered by the Microsoft operating system, completely took the operating system market for personal computers. Apple had high margins yet struggled for relevance.  Under Sculley, Apple released HyperCard, funded a skunkworks team in General Magic, arguably the beginning of ubiquitous computing, and using many of those same ideas he backed the Newton, coining the term personal digital assistant. Under his leadership, Apple marketing sent 200,000 people home with a Mac to try it out. Put the device in the hands of the people is probably one of the more important lessons they still teach newcomers that work in Apple Stores.  Looking at the big financial picture it seems like Sculley did alright. But in Apple's fourth-quarter earnings call in 1993, they announced a 97 drop from the same time in 1992. This was also when a serious technical debt problem began to manifest itself.  The Mac operating system grew from the system those early pioneers built in 1984 to Macintosh System Software going from version 1 to version 7. But after annual releases leading to version 6, it took 3 years to develop system 7 and the direction to take with the operating system caused a schism in Apple engineering around what would happen once 7 shipped. Seems like most companies go through almost the exact same schism. Microsoft quietly grew NT to resolve their issues with Windows 3 and 95 until it finally became the thing in 2000. IBM had invested heavily into that same code, basically, with Warp - but wanted something new.  Something happened while Apple was building macOS 7. They lost Jean Lois Gasseé who had been head of development since Steve Jobs left. When Sculley gave everyone a copy of his memoir, Gasseé provided a copy of The Mythical Man-Month, from Fred Brooks' experience with the IBM System 360. It's unclear today if anyone read it. To me this is really the first big sign of trouble. Gassée left to build another OS, BeOS.  By the time macOS 7 was released, it was clear that the operating system was bloated, needed a massive object-oriented overhaul, and under Sculley the teams were split, with one team eventually getting spun off into its own company and then became a part of IBM to help with their OS woes. The team at Apple took 6 years to release the next operating system. Meanwhile, one of Sculley's most defining decisions was to avoid licensing the Macintosh operating system. Probably because it was just too big a mess to do so. And yet everyday users didn't notice all that much and most loved it.  But third party developers left. And that was at one of the most critical times in the history of personal computers because Microsoft was gaining a lot of developers for Windows 3.1 and released the wildly popular Windows 95.  The Mac accounted for most of the revenue of the company, but under Sculley the company dumped a lot of R&D money into the Newton. As with other big projects, the device took too long to ship and when it did, the early PDA market was a red ocean with inexpensive competitors. The Palm Pilot effectively ended up owning that pen computing market.  Sculley was a solid executive. And he played the part of visionary from time to time. But under his tenure Apple found operating system problems, rumors about Windows 95, developers leaving Apple behind for the Windows ecosystem, and whether those technical issues are on his lieutenants or him, the buck stocks there. The Windows clone industry led to PC price wars that caused Apple revenues to plummet. And so Markkula was off to find a new CEO.  Michael Spindler became the CEO from 1993 to 1996. The failure of the Newton and Copland operating systems are placed at his feet, even though they began in the previous regime. Markkula hired Digital Equipment and Intel veteran Spindler to assist in European operations and he rose to President of Apple Europe and then ran all international. He would become the only CEO to have no new Mac operating systems released in his tenure. Missed deadlines abound with Copland and then Tempo, which would become Mac OS 8.  And those aren't the only products that came out at the time. We also got the PowerCD, the Apple QuickTake digital camera, and the Apple Pippin. Bandai had begun trying to develop a video game system with a scaled down version of the Mac. The Apple Pippin realized Markkula's idea from when the Mac was first conceived as an Apple video game system.  There were a few important things that happened under Spindler though. First, Apple moved to the PowerPC architecture. Second, he decided to license the Macintosh operating system to companies wanting to clone the Macintosh. And he had discussions with IBM, Sun, and Philips to acquire Apple. Dwindling reserves, increasing debt. Something had to change and within three years, Spindler was gone. Gil Amelio was CEO from 1996 to 1997. He moved from the board while the CEO at National Semiconductor to CEO of Apple. He inherited a company short on cash and high on expenses. He quickly began pushing forward OS 8, cut a third of the staff, streamline operations, dumping some poor quality products, and releasing new products Apple needed to be competitive like the Apple Network Server.  He also tried to acquire BeOS for $200 million, which would have Brough Gassée back but instead acquired NeXT for $429 million. But despite the good trajectory he had the company on, the stock was still dropping, Apple continued to lose money, and an immovable force was back - now with another decade of experience launching two successful companies: NeXT and Pixar.  The end of the lost decade can be seen as the return of Steve Jobs. Apple didn't have an operating system. They were in a lurch soy-to-speak. I've seen or read it portrayed that Steve Jobs intended to take control of Apple. And I've seen it portrayed that he was happy digging up carrots in the back yard but came back because he was inspired by Johnny Ive. But I remember the feel around Apple changed when he showed back up on campus. As with other companies that dug themselves out of a lost decade, there was a renewed purpose. There was inspiration.  By 1997, one of the heroes of the personal computing revolution, Steve Jobs, was back. But not quite… He became interim CEO in 1997 and immediately turned his eye to making Apple profitable again. Over the past decade, the product line expanded to include a dozen models of the Mac. Anyone who's read Geoffrey Moore's Crossing the Chasm, Inside the Tornado, and Zone To Win knows this story all too well. We grow, we release new products, and then we eventually need to take a look at the portfolio and make some hard cuts.  Apple released the Macintosh II in 1987 then the Macintosh Portable in 1989 then the Iicx and II ci in 89 along with the Apple IIgs, the last of that series. By facing competition in different markets, we saw the LC line come along in 1990 and the Quadra in 1991, the same year three models of the PowerBook were released. Different printers, scanners, CD-Roms had come along by then and in 1993, we got a Macintosh TV, the Apple Newton, more models of the LC and by 1994 even more of those plus the QuickTake, Workgroup Server, the Pippin and by 1995 there were a dozen Performas, half a dozen Power Macintosh 6400s, the Apple Network Server and yet another versions of the Performa 6200 and we added the eMade and beige G3 in 1997. The SKU list was a mess. Cleaning that up took time but helped prepare Apple for a simpler sales process. Today we have a good, better, best with each device, with many a computer being build-to-order.  Jobs restructured the board, ending the long tenure of Mike Markkula, who'd been so impactful at each stage of the company so far. One of the forces behind the rise of the Apple computer and the Macintosh was about to change the world again, this time as the CEO. 

In his seminal work, The Mythical Man-Month, Frederick Brooks Jr. tells us that software development is homologous to a tar pit where many efforts flounder regardless of the appealing nature of the task or the relative tractability of the underlying physical medium. In what he calls one of the "woes of the craft", the author goes on to explain that the pervasive optimism among programmers regarding the conception of a software project is rarely maintained after we take into account the set of complex interdependencies commensurate with others' skills and objectives. With the understanding that security concerns are a fairly recent addition to the development lifecycle—at least to someone akin to the inherent programming paradigms of the late seventies like Dr. Brooks, one aspect remains unequivocal: programmers are commissioned with the sort of creative work that is unrelentingly attached to the pursuit of perfect usability. This is true, for example, when designing Application Programming Interfaces (APIs)—the set of exposed, intermediary function calls and routines responsible for providing high-level access to predefined software resources and applications whose latticework of dissimilar technologies can be notoriously difficult to secure. It is also common knowledge that to acquire even a subtle resemblance of functionality, software projects must first be anchored to an adequate test environment whereby code isolation can be properly conducted and application behavior safely observed. To the developers, these test environments usually present a number of additional advantages such as access to a broader collection of user data, or to specific backend system logs that would normally be under tighter scrutiny and more robust security controls. This blog post will explore some of the cyber risks associated with insecure development environments and the challenges and trade-offs that system architects must be willing to face in safeguarding them, along with some quick tips and recommendations for the road ahead. Risks of dev environments, and why they get hacked There is no doubt that test environments are a necessary evil. The very tools and applications we've all come to know and love can attribute their primordial existence to one or more of these ecosystems as they relate to the Software Development Life Cycle, SDLC. The staggering rate at which organizations are pushing the software development envelope, and the multitude of choices they face when it comes to hosting platforms or container alternatives, demands evermore careful planning and consideration. Think about iterative approaches like Agile—conceived against the backdrop of the requirement for businesses to deliver results more quickly and more safely in consumable but manageable increments. Think also of the myriad refinements, use cases, code reviews, fuzzing techniques and, more recently, chaos engineering practices modern distributed applications must endure to be deemed production-ready. None of this would be achievable, at the proper scale, without the controlled conditions that exist in a test development environment. That much flexibility and observability, however, comes at a price. For example, test environments are known to have less rigorous security measures and granular controls than a typical 'live' environment would—all under the aforementioned banner of agility. Very frequently, providing developers with this much-desired flexibility is a convoluted effort: too narrow, the privileges and programmers can be trapped in an endless barrage of access woes leading to loss of productivity and missed deadlines; too much access, and the possibility of a data breach increases dramatically. This is similar to what took place in 2018 when Shutterfly, an image sharing and printing company, warned that an employee's credentials had been leveraged by an unauthorized source to gain access to test environments storing a treasure trove of pers...

Luke Hohmann: Innovation through games, Agile doing vs Agile being and teaching kids financial skills. In this episode, William Laitinen is joined by Luke Hohmann, Founder and CEO at Tilliden, internationally recognized expert in Agile Software Development and author of Innovation Games: Creating Breakthrough Products Through Collaborative Play. They discuss team dynamics, mental models, how play helps with innovation and the mission of his latest venture, Tilliden, which is committed to creating financially literate children capable of transforming their communities as they become financially independent adults.William Laitinen YouTube: https://www.youtube.com/channel/UC4znfBsKevmb8u7v4WrCg0Q/ LinkedIn: https://www.linkedin.com/showcase/search-with-purpose-insurtech-&-fintech/ LinkedIn: https://www.linkedin.com/in/william-laitinen-93282/ Website: https://www.exigeinternational.com/Luke Hohmann LinkedIn: https://www.linkedin.com/in/lukehohmann/ Website Tilliden: https://join.tilliden.com/ Website Innovation Games: https://www.innovationgames.com/Luke Hohmann's recommended reads The Mythical Man-Month by Fred Brooks Understanding Comics: The Invisible Art by S. McCloud The Social Psychology of Organizing by Karl E. Weick See acast.com/privacy for privacy and opt-out information.

Join V. Lee Henson, President and Founder of AgileDad as we explore items that will help you grow as a ScrumMaster. Today we will discuss the mythical man month. Throwing more people at the problem does not always make things better. Explore how we can work together to better organize work instead of constantly adding people. 

Desenvolver usando banco de dados é um diferente de desenvolver o banco de dados. Fabrízio Mello é um PostgreSQL Developer na Ongres e também sócio da Timbira, duas empresas dão suporte para o PostreSQL. Também falamos um pouco sobre carreira e como começar a desenvolver para ele. Twitter: @fabriziomello Linkedin: @fabriziomello Referências: Stackgres - https://stackgres.io/ Ongres - https://ongres.com/ Mythical-Man Month - https://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959 Exemplo de PostgreSQL Operator - https://github.com/zalando/postgres-operator CRD - https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/ Áudios "I Know Where You've Been" de Forget the Whales Ultradémon de Sors --- Send in a voice message: https://anchor.fm/pontocafe/message

Petra Manos joins the Freelancers' Show to talk about hiring and managing remote workers and subcontractors. Petra runs a consultancy that manages Google Analytics, Google Tag Manager, and Google Ads. She hires and manages people to help manage the workload for her clients. Chuck has also hired VA's. The panel dives into the ins-and-outs of growing teams, hiring consultants, and working with people who don't necessarily start out with the skills you need. Panelists Brad Large Brooks Forsyth Charles Max Wood Guest Petra Manos Sponsors G2i | Enjoy the luxuries of freelancing Sentry Use code "devchat" for $100 credit CacheFly ____________________________________________________________ "The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood is now available on Amazon. Get Your Copy Today! ____________________________________________________________ Links The Mythical Man-Month OnlineJobs SweetProcess Trainual Clockwork Upwork Picks Brad Large: Zapier FinancialMentor Brooks Forsyth: Logitech K480 Keyboard Petra Manos: Virtual Freedom Monday.com

Episode Summary In this week’s episode of The Freelancers Show the panel discusses the importance of defining success. Jeremy Green explains why this concept of defining what success means to you is so important. Without success behind defined you might put your nose to the grindstone and miss your own success. Inversely you might be grinding away, missing the signs that what you are doing isn’t taking you to success and you need to stop and reevaluate.    The panel considers some of the obvious signs of success like key performance indicators. Are you making enough to pay your bills, save and play? It is easy to think success is making a million dollars. If that is your definition of success, the panel explains that you will all your success along the way. They invite everyone to sit down and really think of what success means to you. How do you want to spend your time? Are you doing something you love? Do you want to spend more time with friends and family?    Jeremy explains why he wanted to talk about this topic. He went to a conference and this seemed to come up a lot during talks at the conference. It can be hard to reconcile how you feel about success when looking at other people and their circumstances. Deciding what success means to you can help guide your life and get rid of some of that uncertainty.   Erik explains the hedonic treadmill, which shows a phenomenon that says highs from successes wear off fasters than the pain of failure. No matter how high you climb there is always someone higher and your success of getting where you are is forgotten as you attempt to catch the person above you. If you set goals then you can more easily see the success as the come along.     Jeremy shares some of his success criteria. He realized at this conference that he was doing well enough in freelancing and consulting that could pull back and focus more on other things he has been wanting to improve. He realized he got sidetracked and started grinding towards saving as much money as he could for retirement. By figuring out his goals, he saw that was actually doing much better than he thought and didn’t need to grind so much.     Erik describes a similar moment of realization for him at the end of 2016. He was feeling pretty burnt out from traveling, so he sat down and quantified all his work for that year and decide what he wanted out of his lifestyle and made goals in his work life to help him reach that lifestyle.    Erik explains that by not having explicit goals, implicit goals be pressed on us by our surroundings. The panel considers how in this world there is never enough money, but by defining our earning goals and deciding what is enough for us, we can find success in more than one way.    The panel considers how easily freelancers can get carried away overworking and pushing themselves. Employees have an employer that won’t let them overwork, employees have gaurd rails that protect them from this sort of abuse. Freelancers constantly feel that pressure to use their time wisely, to do more. By defining success, you give yourself a way to take an objective look and say I am doing well, I can’t take the night off.    Erik shares his approach to this process. He explains that he starts by looking at his life and what will make him happy and work his goals back to work from there. He gives tips on how to quantify qualitative things in your life so you can evaluate your success.    The definition you give to success is very personal and will differ for each person. The panel considers it from a Maslow’s Hierarchy of business standpoint. The survival needs being are you staying afloat and the different needs moving up a pyramid all the way up to self-actualization or success.    Finally, the panel discusses the need to define failure as well as success. It’s important to know when to bail out or reevaluate a situation. Panelists Jeremy Green Erik Dietrich Sponsors   Sentry– use the code “devchat” for two months free on Sentry’s small plan Adventures in DevOps Views on Vue CacheFly Links https://www.facebook.com/freelancersshow/ Picks Jeremy Green: Company of One The Mythical Man Month Erik Dietrich: The 4-Hour Workweek Hit Subscribe

Welcome to the History of Computing Podcast, where we explore the history of information technology. Because understanding the past prepares us for the innovations of the future! Todays episode is about the IBM System/360. System/360 was a family of mainframes. IBM has done a great job over the decades following innovations rather than leading them, but there might not be another single innovation that was as influential on computing as the System/360. But it's certainly hard to think of one. IBM had been building mainframes with the 700 and 7000 series of systems since 1952, so they weren't new to the concept in 1964 when the S360 was announced (also when Disney released Mary Poppins and ). But they wanted to do something different. They were swimming in a red ocean of vendors who had been leading the technology and while they had a 70 percent market share, they were looking to cement a long-term leadership position in the emerging IT industry. So IBM decided to take a huge leap forward and brought the entire industry with them. This was a risky endeavor. Thomas Watson Jr, son of the great IBM business executive Thomas Watson Sr, bet the proverbial farm on this. And won that bet. In all, IBM spent 5 billion dollars in mid-1960s money, which would be $41B today with a cumulative 726.3% rate of inflation. To put things in context around the impact of the mainframe business, IBM revenues were at $3.23 B in 1964 and more than doubled to $7.19 B by 1970 when the next edition, the 370, was released. To further that context, the Manhattan Project, which resulted in the first atomic bomb, cost $2 B. IBM did not have a project this large before the introduction of the S360 and has not had one in the more than 50 years since then. Further context, the total value of all computers deployed at the start of the project was only $10B. These were huge. They often occupied a dedicated room. The front panel had 12 switches, just to control the electricity that flowed through them. They had over 250 lights. It was called “System” 360 because it was a system, meaning you could hook disk drives, printers, and other peripherals up to them. It had 16 32 bit registers and four 64 bit floating point registers for the crazy math stuffs. The results were fast, with over 1000 orders in the first month and another 1000 by years end. IBM sales skyrocketed and computers suddenly showing up in businesses large and small. The total inventory of computers in the world jumped to a $24B value in just 5 years. A great example of the impact they had can be found in the computer the show Mad Men featured, where the firm got an S360 and it served as a metaphor for how the times were about to change - the computer was analytical, where Don worked through inspiration. Just think, an interactive graphics display that let business nerds do what only computer nerds could do before. This was the real start to “data driven” decision making. By 1970 IBM had deployed 35k mainframes throughout the US. They spawned enough huge competitors that the big mainframe players were referred to as Snow White and the 7 dwarfs and later just “The Bunch” which consisted of Burroughs, NCR, Control Data, Honeywell, and the Univac Division of Sperry Rand. If you remember the earlier episode on Grace Hopper, she spent some time there. Thomas Watson Jr. retired the following year in 1971 after suffering a heart attack, leaving behind one of the greatest legacies of anyone in business. He would serve as an ambassador to Russia from 79 to 81, and remain an avid pilot in retirement. He passed away in 1993. A lot of things sell well. But sales and revenue aren't the definition that shapes a legacy. The S360 created so many standards and pushed technology forward that the business legacy is almost a derivative of the technical legacy. What standards did the S360 set? Well, the bus was huge. Stndardizing I/O would allow vendors to build expansion and would ultimately become the standard later. The 8-bit byte is still used today and bucked the trend of accessing variable sized arbitrary bit addressing. To speed up larger and larger transactions, the S360 also gave us Byte-addressable memory with 24 bit addressing and 32-bit words. The memory was small and fast with control code stored there permanently, known as microcode memory. This meant you didn't have to hand wire each memory module into the processor. The control store also lead to emulators, as you could emulate a previous IBM model, the 1401, in the control store. IBM spent $13 M on the patent for the tech that came out of MIT to get access to the best memory on the market. The S360 made permanent store a main-stay. IBM had been using tape storage since 1952. 14 inch disk drives were smaller than 24 inch disk drives used in previous models, had 100x the storage capacity and accessed data 10 times faster. The S360 also brought with it new programming paradigms. We got hexadecimal Floating Point Architectures. These would be important to New Drug Applications to the FDA, weather predicting, geophysics, and graphics databases. We also got Extended Binary Coded Decimal Interchange Code or EBCDIC for short is character encoding in the 8th bit. This came from moving punch cards to persistent storage on the computers. That 8th bit was from two zone and number punches on cards which made up two bits and another to indicate a small s or a large S. EBCDIC was not embraced by the rest of the computer hacker culture. One example was: "So the American government went to IBM to come up with an encryption standard, and they came up with… EBCDIC!" ASCII has mostly been accepted as the standard for encoding characters (before and after EBCDIC). Solid Logic Technology (or SLT) also came with the S360. These flip chip-mounted packages contained transistors, diodes and resistors in a ceramic substrate that had sockets on one edge and could be plugged into the backplane of a computer. Think of these as a precursor to the microchip and the death of vacuum tubes. The central processor could run machine language programs. It ran OS/360, officially known as IBM System/360 Operating System. You could load programs written in COBOL and FORTRAN with many organizations still running code written way back then. The way we saw computers and they way they were made also changed. Architecture vs implementation was another substantial innovation. Before the S360, computers were built for specific use cases. They were good at business and they were good at business or they were good at science. But one system wasn't typically good at both tasks. In fact, IBM had 7 mainframe lines at this point, sometimes competing with each other. The S360 allowed them to unify that into the size and capacity of a machine rather than the specific use case. We went from: “here's your scientific mainframe” or “here's your payroll mainframe” to “here's your computer”. But the Model 30 was Introduced in 1965, along with 5 other initial models, the 40, 50, 60, 62, and 70. The tasks were not specific to each model and a customer could grow into additional models, or if the needs weren't growing, could downgrade to a lower model in the planned 5 year obscelence cycle that computers seem to have. Given all of this, the project was huge. So big that it led to Thomas Watson forcing his own brother Dick Watson out of IBM and moving the project to be managed by Fred Brooks, who worked with Chief Architect Gene Amdahl. John Opel managed the launch in 1964. In large part due to his work on the S360 project, Brooks would go on to write a book called The Mythical Man Month, which brought us what's now referred to as Brooks' Law, which states that adding additional developers does not speed up a software project, but instead makes it take longer. Amdahl would go on to found his own computer company. In all, there were twenty models of the S360, although only 14 shipped - and IBM had sold 35,000 by 1970. While the 60 in S360 would go on to refer to the decade and the follow-on S370 would define computing in the 70s, the S360 was sold until 1978. With a two-thirds market share came anti-trust cases, which saw software suddenly being sold separately and leasing companies extending that 5 year obscelecence - thus IBM leassors becoming the number one competition. Given just how much happened in the 13 year life of the System/360, even the code endures in some cases. The System Z servers are still compatible with many applications written for the 360. The S360 is iconic. The S360 was bold. It set IBM on a course that would shape their future and the future of the world. But most importantly, before the S360 computers were one thing used for really big jobs - after the S360, they were everywhere and people started to think about business in terms of a new lexicon like “data” and “automation.” It lead to no one ever getting fired for buying IBM and set the IT industry on a course to become what it is today. The revolution was coming no matter what. But not being afraid to refactor everything in such a big, bold demonstration of market dominance made IBM the powerhouse it is even today. So next time you have to refactor something, think of the move you're making - and ask yourself What Would Watson Do? Or just ask Watson.

Lumina Desktop 1.3 is out, we show you a Plasma 5 on FreeBSD tutorial, explore randomness, and more. This episode was brought to you by Headlines Lumina Desktop v1.3 released (https://lumina-desktop.org/version-1-3-0-released/) Notable Changes: New Utility: lumina-mediaplayer. Lumina Media Player is a graphic interface for the Qt QMediaPlayer Class, with Pandora internet radio streaming integration. Lumina Media Player supports many audio formats, including .ogg, .mp3, .mp4, .flac, and .wmv. It is also possible to increase the number of playable formats by installing gstreamer-plugins. This utility is found in the Applications → Utilities section, or opened by typing lumina-mediaplayer in a command line. New Utility: lumina-xdg-entry. This is another simple utility designed to help users create .desktop entries and shortcuts. Find it in the Utilities application category, or open it by typing lumina-xdg-entry in a command line. Lumina Desktop: Desktop folders are integrated, and can now be manipulated directly from the desktop. Added the automatic settings migration of a desktop monitor (single monitor only, for now). Numerous speed and performance improvements with how icons load and the system interacts with the desktop. Lumina-FM: Now fully integrated with lumina-archiver. A “System directory” tree pane is available. Options to enable/disable it are being added later, as it is on by default. Numerous speed improvements with caching and loading icons. Lumina Texteditor: There is a new json manifest file format for syntax highlighting support. Users can open this file, customize their highlighting options, and immediately see their changes without rebuilding the utility. The text editor now supports more than 10 different file formats. Added options for file-wide preferences in syntax files. Options include: word wrap, character per line limits, excess whitespace highlighting, font style restrictions, and tab-width settings. LTE supports tabs with detach, drag'n'drop, and location customization with the View menu option. Add checkable menu option to show the “unsaved changes” dialogue box on close. Lumina Screenshot: Adjustments to the lumina-screenshot interface. Add an adjustable warning to lumina-screenshot when closing with an unsaved image. Add functionality to select a specific area of the screen for screenshots. Lumina Archiver: Functionality improvements. Bug fixes. Interface changes. General Improvements: Permission checks for settings files (all utilities). When launched with sudo, all tools use or create a root-permissioned copy of the user's settings file. This prevents a settings file being locked by root. UI text reworks to help re-unify style. Add hooks to update the desktop with icons for the /media directory when a system uses USB automounting functionality. Fix Fluxbox bug with windows workspace assignments. Work on new utility lumina-notify (not fully functional yet). Fix panel reporting error crashing lumina-config. Bug fix for dbus-send calls for Gentoo. Clean up automatic DPI scaling support. Bug fix for the panel clock. Compton compositor is now disabled by default (but can be manually enabled). Translation file updates. Documentation updates. *** FreeBSD 11.0 and Plasma 5 HowTo (https://euroquis.nl/bobulate/?p=1609) Here's a step-by-step guide to getting a machine with FreeBSD 11 in it, running X, and KDE Plasma 5 Desktop and KDE Applications. It's the latest thing! (Except that 11-STABLE is in the middle of the pack of what's supported .. but the KDE bits are fresh. I run 10.3 with KDE4 or Plasma 5 on my physical machines, myself, so the FreeBSD version isn't that important except that packages are readily available for 11-STABLE, not for 10-STABLE.) We skip the part about installing FreeBSD (it's in there if you need it) and get right to the important parts that you need: An X Server and a backup X11 environment (ancient): pkg install xorg xterm twm Desktop technologies (modern): pkg install hal dbus echo haldenable=YES >> /etc/rc.conf echo dbusenable=YES >> /etc/rc.conf Next up, test whether the X server works by running startx and exiting out of twm. If running with ZFS, it's a good idea to snapshot now, just so you can easily roll back to the it-works-with-basic-X11 setup you have now. zfs snapshot -r zroot@x11 Now swap out the default FreeBSD package repository, for the KDE-FreeBSD community one. This is documented also on the Area51 page (https://community.kde.org/FreeBSD/Setup/Area51). mkdir -p /usr/local/etc/pkg/repos cd /usr/local/etc/pkg/repos cat > FreeBSD.conf > /etc/rc.conf Log in as your test user, and set up .xinitrc to start Plasma 5: cat > .xinitrc

Episode 10 of the Modern Agile Show begins with a small passage from The Mythical Man-Month, by Frederick P. Brooks, Jr, followed by an interview about agile leadership with agile coach, David Lokietz.

In this episode, I have a fireside chat with internationally recognized PHP expert, and all around good fella Paul M. Jones, about one of his all-time favorite books - The Mythical Man Month.

This episode was recorded 22 May 2013 live and in person at Adobe's offices in Fremont in Seattle. You can download the m4a file or subscribe in iTunes. (Or subscribe to the podcast feed.) John Nack is Principal Product Manager, Adobe Digital Video. He has a blog (definitely worth reading, especially if you use Photoshop) and is @jnack on Twitter. This episode is sponsored by Microsoft Azure Mobile Services. One of the cooler features recently added is the ability to create custom APIs. Originally you were limited to standard operations on your database tables — but now you can design any API you want. This allows you to create a full REST/JSON API that's tailored to your app, that works as efficiently as possible. (And it's all in JavaScript. Mobile Services runs Node.js. Write your apps in your favorite text editor on your Mac.) Things we mention, in order of appearance (pretty much): Adobe LiveMotion Photoshop John's Blog Kurt Vonnegut Granfalloons despair.com Cocoa 64-bit Carbon 64-bit Unfrozen Cave Man Olive Garden South Bend, Indiana Tiramisu St. Sebastian Breadsticks Monkeys 2005 Movable Type DeBabelizer GifBuilder Anarchie 1984 Mac 2001 Algonquin Hotel Apple II PCjr ASCII Art Clip Art Googly Eyes Bill Atkinson MacPaint Rorschach Test Apple II GS Great Books Quadra 840AV Quadra Ad Director SuperCard Søren Kierkegaard Immanuel Kant Notre Dame Football Windows NT HTML New York City 1998 Flash Macromedia Illustrator Navy ROTC San Francisco GoLive NetNewsWire After Effects Thomas Knoll Camera Raw Photoshop Touch Germany Philistinism Perfectionism Volkswagen Carbon-dating Web Standards SVG CSS Gus Mueller Acorn Neven Mrgan Khoi Vinh Croatia Portland JDI Healing Brush Buck Rogers Creative Cloud Facebook Smugmug WWDC Jetta Ketchup Death-march Comic Book Guy John Gruber “If you see a stylus, they blew it.” Microsoft Surface Metro UI Rahm Emmanuel: “You never want a serious crisis to go to waste.” The Mythical Man-Month Content-Aware Fill Shawshank InDesign Adobe Magazine Nike PageMaker Postscript SLR Lightroom Black & Decker Dr. Evil Loren Brichter Instagram Kickstarter NGO Tumblr Acquisition Troy Gaul Blurb The Onion: Report: 98 Percent Of U.S. Commuters Favor Public Transportation For Others Data T-1000 Syria MacApp Resource Manager John Knoll Industrial Light & Magic QuickTime OpenDoc Corba OLE SnapSeed Mac System 6 Apple events AppleScript Audio Bus 1992 “The only time you should start worrying about a soldier is when they stop bitchin'” Alan Kay: “The Mac is the first computer good enough to be criticized.” TapBots Tweetbot 2 Android Kai's Power Tools Kai Krause Fremont RUN DMC Porsche Boxster Flavawagon Google Glass Robert Scoble

Protecting computer from malicious guests, installing a desktop PC power supply, upgrading Blackberry Storm OS, Profiles in IT (Frederick Phillips Brooks, father of the IBM System 360 and author of the The Mythical Man Month), Congressional security breach embarrasses Ethics Committee (file was shared inadvertently by Gnutella peer-to-peer file sharing client, staffer fired), Internet celebrates 40th anniversary (first message went 400 miles between UCLA and SRI, first three letters were LOG, network designed to share computer power between research labs), ICANN will permit non-Latin characters in domain names after 16 November, and Blooms cognitive taxonomy (anatomy of learning, six levels, remembering, understanding, applying, analyzing, evaluating, creating). This show originally aired on Saturday, October 31, 2009, at 9:00 AM EST on WFED (1500 AM).