Matt Stine
Rocky Mountain Software Symposium
Denver · November 19 - 21, 2010
I Enable Early-Career Enterprise Software Engineers to Continuously Improve
My passion is taking a metaphysical approach to software engineering: what is the nature of the collaborative game that we continuously play, and are there better, more contextually-aware ways to play that game?
By day I lead a team tasked with taking a first-principles-centric approach to intentionally enabling programming language usage at the largest bank in the United States.
By night I write and teach my way through a masterclass in software engineering and architecture targeting early-career software engineers working in large-scale enterprise technology organizations.
What is the primary goal?
To win the game. More seriously: to get 1% better every day at providing business value through software.
Who am I?
I'm a 22-year veteran of the enterprise software industry. I've played almost every role I can imagine:
- Software Engineer
- Software Architect
- Technical Lead
- Engineering Manager
- Consultant
- Product Manager
- Field CTO
- Developer Advocate
- Conference Speaker
- Author
- Technical Trainer
- Technical Marketer
- Site Reliability Engineer
- Desktop Support Specialist
I've worked at Fortune 500 companies, a tenacious teal cloud startup, and a not-for-profit children's hospital. I've written a book, and I've hosted a podcast. I've learned a lot along the way, including many things I wish I'd known when I first got started. And so now I want to pass those learnings on to you, especially if you've only just begun your career.
Presentations
The Seven Wastes of Software Development
One of the first principles of lean software development is the elimination of waste. Shigeo Shingo identified seven types of manufacturing waste in his “A Study of the Toyota Production System.” Later, the Poppendieck's translated these to seven wastes of software development.
Yes You Kanban
Kanban. What is it? It is most certainly not just moving sticky notes around on a board. Far from that, it is a method for gradual, evolutionary improvement of existing software processes. That's right, existing software processes. There is no “Kanban Development Process.” Think you're “doing Kanban?” Think again.
Agile Development with OSGi
There isn't much said in typical Agile conversation about architecture and modularity. We will attempt to redress this omission by examining an agile approach to logical system architecture coupled with a potential implementation for the Java platform.
Tracer Bullet Development (TBD) is a technique that allows you to prove out the proposed architecture of your system by firing a “tracer bullet” through a vertical slice of your system that exercises all of its horizontal components. It has multiple benefits, including encapsulation, decoupled code, parallel code development, and more.
OSGi is a specification for a dynamic module system for Java with multiple open source implementations. It allows you to modularize your system into “bundles” which essentially firewall their own classloader space. Objects running within a bundle can only see types that they explicitly import and only expose types that they explicitly export. They interact with other bundles by expose and consuming services which are registered under a public interface.
At face value it seems that Tracer Bullet Development and OSGi are a match made in heaven!
The Agile Guerilla
So you discovered agile software development this weekend. You've finally found the tools that you're going to use to fix your team. Do you rush in to work Monday morning with a slide deck in one hand and a baseball bat in the other, ready to bludgeon the first person who checks in untested code? How do you think that's going to work out for you? I can tell you from personal experience that it doesn't play out too well. There is a better way.