Flipping the Bozo Bit

Flipping the Bozo Bit
By Keith Irwin, Christoph Neumann
About this podcast
A conversational podcast questioning everything there is to question about software development.
Latest episodes
Nov. 22, 2014
Keith and Christoph discuss bouncing from implementation details to business goals. Download MP3
Nov. 8, 2014
Keith and Christoph discuss the “fire” of what matters in software development vs the “shadow” of everything else. Download MP3
April 1, 2014
Keith and Christoph discuss what “flexibility” might mean for an ongoing, evolving architecture. Download MP3
Nov. 15, 2013
Christoph and Keith explore the intersection between the technological bedrock we take as given when we develop software systems, such as operating systems, TCP/IP networks, files, automatic memory management (and maybe even HTTP), and the free floating ideas we have before we ever write a line of code. Say ‘technological bedrock’ represents constraints (or the reality) you can’t change, and ideas represent imaginitive worlds you want to bring into being. If that’s the case, then programming languages become the means by which you move from imagination to reality. They’re artistic materials: the raw stuff out of which a representation is made. If so, why do language developers (and perhaps more earnestly, language users) insist on hardening languages to a sub-set of possibilities? This language requires built-in unit tests, that one doesn’t. The one over there insists that everything is an object, while this one insists that everything is a value. Finally, we have a language with a type system so rich it’s turing complete, while over there, a string is a number, depending on what it contains. Wouldn’t it be great to have a language in which you can build just the OO you needed, when you needed it? Or what about one in which compile-time static typing were optional for just those areas where it provides real benefit? What if we think of programming languages more like poets think of words, or painters of paint? This and more on Flipping the Bozo Bit Episode 14. Links! Some fun stuff mentioned (sometimes in spirit) in Episode 14: Pyret: A programming language in which unit tests are part of a function’s definition. Clojure: An expressive, minimilist Lisp for the JVM. Scala: A scalable, multi-paradigm language. Narcissism of small code differences:A wonderful post about how developers interact with each other and code. The comments are an excellent example of the principle in action. Narcissistic Design - Stuart Halloway:Stuart illustrates how, often, the “best practices” baked into our languages, techniques and assumptions are, in fact, worst practices. And finally: Download MP3
Nov. 1, 2013
In our last episode, we took as our starting point the notion that Scrum and/or Agile Software Development is more about how to manage tasks than about how to design software, both for quality, and for the humans who need to maintain and extend it. We explored ways of getting design into the process as much as possible. In this episode, we continue the theme by starting with the notion that Scrum/Agile, again, for all its success as a task management, estimation and communication strategy, has nothing to say about building and maintaining a great team. You might find yourself joining a team successfully leveraging Scrum for all its worth yet be at a loss as to how you can contribute. It’s not that you don’t understand the process. That part’s easy. It’s that, well, there’s the software, the ecosystem, the politics, the personalities, the design and the architecture. The technical debt. How might you onboard a team member when the project is complicated and the existing team are battle-hardened verterens? Does the nature of the project — its design — make this any easier? How do you define success for the new guy? Is there a place for ownership and responsibility? This and more on Flipping the Bozo Bit Episode 13. Download MP3
Oct. 15, 2013
What if we made design a part of the Agile Software Process? In This Episode: Emu Ranchers Agile Software Development Waterfall Model Design is how it works Download MP3
Oct. 1, 2013
What’s the deal with FRP? Christoph gives us the skinny on Functional Reactive Programming. In This Episode: The Observer Pattern Deprecating the Observer Pattern Functional Reactive Programming Conal Elliott The Spreadsheet Metaphor bacon.js Publish Subscribe Pattern Download MP3
Aug. 1, 2013
What if you wanted to write a fancy in-browser app but were less than enthusiastic about the Javascript ecosystem? In This Episode: Namespaces and the jQuery trick Punting on the whole issue and using (ahem) ClojureScript Javascript as the assembly of the web As Java begat JVM languages, so JavaScript begat JSVM languages? The appropriately named EcmaScript and its versions and implementations. Links: Clojure (I should just build this into the template.) Scala ClojureScript Scala.JS: » presentation, » infoq & » hackernews. CoffeeScript LispyScript: » hackernews. asm.js PhoneGap Building an iOS weather app with Angular and ClojureScript What is it with all this CamelCase. Aren’t we done with that yet? Download MP3
July 15, 2013
What if you ran your internal, closed-source, proprietary, mega-corporate projects like open source projects? Similar styles? Similar tools? In This Episode: First step in a software project? Meetings! But, but … what if we run internal projects like they were open source projects? Submitting patches to company projects, no matter where they are. IT departments: The people who say no. Internal utility projects? Or open source product products? Skunkworxing Pretending internally focussed apps are open source apps. The expensive barrier of entry for official projects. You can’t backlog an exploration. Feudalism and the company ownership of your skills. Toyota and the kanban thing. The Blue Ocean Notion Engineers, the trolls in the back room. The economy of getting things done. The meritocracy of things that work. We won’t discuss the merits of hard copy RSS. Open source repos as a way to avoid executive escalation. Branching another org’s project if they won’t play ball. An application built on two power structures. Babylonian dating service vs the dart method. Multiple project owners does not a happy project make. Super-printer-mega-comm vs printer chat. The economy of utility vs the economy of power. Dark Net: the response to authoritarianism. XMPP: It’s not a Best Practice on the Best Practice Blog Doing development on the sly is best done using open source development tools. The Resistance? Their office hours are posted here. When you’re not being managed, you end up using open source techniques when you want to get things done. Writing software professionally vs writing software as a professional. The chains are in our minds. In the open source world, you get to be Apple and say “no”. You go underground so you can, eventually, go above ground. Digging a trench around managers so they can’t help but fall where you want. Do you have to be an open-source kind of person? What if the engineering director forced open-source by fiat? Differently motivated developers. Developers and software as a continuum. Or the chasm. Or something. Aunt Mabel, Designer Intuition and the Ophthalmologist Story points as a measure of reluctance. Slides vs prototype, forced buy-in vs peer persuasion. Links: Skunk works Open source Kanban Clojure XMPP Ejabberd Download MP3
July 1, 2013
This one’s all about the music. What if you had to rewrite your software after every release? In This Episode: The conceptual difficulties of other peoples’ code, even when those other people are you. Legacy code and your own conceptual traps. Legacy code and demon possession. Legacy code and multiple personality disorder. What if you have to rewrite your code for each fix or deployment? “Write a new version of the code, minus the bug.” Lego oriented programming Binary vs texty interop ClassCastException vs sloppy parsers. “No, no. All shall match!” Log it and move on. Loosely coupled components vs statically-typed messages. The freedom to write crap code. The side-tracking concerns of the typical code review. “Okay, I’m having a connection.” Guitar! Writing code as performance. Improvisation, instruments, scores. Rewrite as process is kinda like jazz improv over a chart of chord changes, right? Sax might work better than a symphony orchestra when you need to improv. My secret weapon is Clojure. Banjo! “And then I come in with my ukelele and just get upset.” Ukelele! Guard rail programming (driving by unit tests). The interface docs are the app, not the code, not the implementation. The transitive nature of object oriented spaghetti How to decouple? Look to the data. State data vs event data (moments lost like tears in the rain vs the eternal). Injecting your dependencies. Is that a euphamism? Turing complete config langage. No! “All you get is English.” If all you have to spec components is English, components have got to be simple. Built-in monitoring over extensive testing, the app’s business logic is to test itself? Ultimately, design (the score or the changes) is king. Design is “how it works”. “I was hoping you were going to say something brilliant. Uh….” Nexi of information. What’s the difference between technical debt (bankruptcy) and not having the source code? “Technical debt is worse than having to rewrite from scratch every time.” “Whenever ‘c’ came along, I played ‘c’. Then I was silent.” The first thing to jettison with multiple rewrites are the pointless abstractions. Improvisation + experience. Onboarding new devs via rewriting. “The knife dropped itself from my hands.” “The code went off the deep end.” “We chained ourselves to the technical debt.” “The business didn’t let us fix it.” Download MP3