Keith and Christoph discuss bouncing from implementation details to business goals. Download MP3 

Flipping the Bozo Bit

Episode 17: Dialectical Trampolines

Keith and Christoph discuss the “fire” of what matters in software development vs the “shadow” of everything else. Download MP3 

Episode 16: Shadow Wars

Keith and Christoph discuss what “flexibility” might mean for an ongoing, evolving architecture. Download MP3 

Episode 15: Flexibility

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 

Episode 14: Set My Language Free!

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 

Episode 13: All Aboard

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 

Episode 12: Agile Design

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 

Episode 11: Functional Reactive Programming

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 

Episode 10: Javascriptocalypse

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 

Episode 9: Internalizing Open Source

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 improvisation over a chart of chord changes, right? Sax might work better than a symphony orchestra when you need to improvise. My secret weapon is Clojure. Banjo! “And then I come in with my ukulele and just get upset.” Ukulele! 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 euphemism? Turing complete config language. 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. On-boarding 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 

Episode 8: Clean Room Development

What if you can’t duplicate your production stack for testing and so on? For instance, factory software? I’m starting to think this whole podcast is, ultimately, about design. In This Episode: Steel mills Stackless programming (and we ain’t talkin' 'bout push/pop). What if you can’t run your software except in production? You can test but you can’t run. Your interfaces can never be too thin. Adapters outside the walled garden of perfection. The immutable log of perfection. What’s the difference between data streaming in from hardware, or replayed log data? The wall as observation post. You gotta go batch. The golden nugget and the matrix. Everybody gets a copy! How to engineer bugs for performance review goodness. “This whole things screams, ‘Messaging! Messaging!’” “This Facebook thing is confusing me a bit.” How many gamma bursts per angstrom? Human vs machine interface and the idea of a command protocol expressing user intention. Beep boop. Human type-able protocol, the ultimate human/machine interface. (Well, outside of brain implants. Maybe.) The Hardware shouldn’t know about the System, the System shouldn’t know about the Hardware. (Or Facebook.) If software devs and hardware devs agree on a simple protocol they can fake the rest. Any time you can remove dependencies from the system, it’s good. Hardware interfaces are one thing, but why not do the same thing with remote software interfaces? (Say, Facebook!) Facebook is hard. Ware. The footzy-boo camera, not that old whatever-whatever camera. System integration should be about intentions, not implementation details. Distributed adapters mean incremental upgrade. No down time! Erlang pretty much got all this right long ago. Everyone needs to learn to walk, even though “walking” has been solved. That’s right. Steel mills to data warehouses. We don’t build one-off lamps, we build lamps that morph and evolve. It’s about the data that flows, not the nodes it flows through. Does it come down to separation of expertise as well as concerns? “I thought we were experts on everything.” Download MP3 

Episode 7: Steel Mills to Data Warehouses

Thought experiments are all well and good, but sometimes you gotta try 'em out to see what’s what. In This Episode: Processing problematic log data using Clojure’s lazy sequences. Using Scala’s package objects to remove object oriented abstractions, and liking it! Download MP3 

Episode 6: Lazy Package Objects

Can’t change your variables once you assign a value? WTF? Surely, this is something up with which we cannot put! Or: a round-about introduction to some of the concerns addressed by the functional programming paradigm. In This Episode: “I’ve been thinking about Object Oriented Programming.” “And you survived.” Concurrency and shared state Changing the value of 2 What if we can’t change a variable’s value? Side effects: minus the sides. And the effects. A functional primer and the unit test No side effects? No dependency injection! Does dependency injection break the “encapsulation” contract? Lock the doors so we can invent windows. Mock object makes a mockery of … well …. Separating values from behavior The inversion of the inversion Apparently, we’re really interested in address books. What about side-effects, though? I mean, right? Separating side-effects from calculations A walled-off garden of perfection Don’t mock me Recursion When copying is not copying What’s the difference between antidote and poison? Mocking and Dependency Injection, a heretical view Rich Hickey, Simon Peyton Jones, Martin Ordesky Clojure: What if I only use blue? Scala: What if we add blue, and every other color, too? After all this, why OO ever? Simple Made Easy Download MP3 

Episode 5: A Walled Off Garden of Perfection

In this episode, we start with our conclusion and try to move on from there. In This Episode: What if we couldn’t use IDEs? Confessions What is an IDE anyway? Glade! The value is in the integration? IDE as antidote to problematic language choices. Metatool! The Bulldozer and the Treehouse Managing Java without an IDE How poor memory leads to simplicity Design patterns for the memory impaired PHP and the Abstraction Loving Programmer Football helmets and the damage they hide Implicitly magical Mutability causes debuggers or air planes or something IDEs can remember it for you IDE interface remains the same when the languages change Unix and Windows, reflections of their Eras in Tooling Wait for the tool maker, or be the tool maker? Weblogic Workbench: hooray! Rails: hooray! Did IDEs solve the problems of software complexity? Solve complexity by simplifying, not managing. Brazil! Managing CSS The Importance of Re-thinking Earnestly Creativity and Limitations What can I do with blue? Download MP3 

Episode 4: The March of IDEs

What if you were required to write a prototype for every significant development of your software system? In this episode: Prototypes as the only means of proposal New, bootstrappy architectures vs old, established architectures Prototype the non-code parts of the problem Prototypes as risk management for legacy, debt-encrusted systems Can you really prototype a monolithic mountain of madness? No prototyping without loose coupling? What is a prototype anyway? Distributed architectures and prototyping Prototype first as an antidote to the monolith A paper prototype is misleading Prototypes reveal the hidden horror beneath a beautiful diagram The value of a pre-prototype discussion Wherefore art thou estimation? Changing the meaning of change Prototypes: the enemy of status-quo or the safest way to grow? Download MP3 

Episode 3: Technical Debt On Wheels

A conversational podcast questioning everything there is to question about software development.

hubhopper

Flipping the Bozo Bit

hubhopper