Agile technology leader and dynamicist
Michael strives to raise the bar and ease the pain for developers across the country. He shares his passion and energy for improvement with everyone he meets, sometimes even with their permission. Michael has spent the better part of 20 years learning what it means to be a professional programmer who cares about art, quality, and craft. He's always ready to spend time with other developers who are fully engaged and devoted to their work--the "wide awake" developers. On the flip side, he cannot abide apathy or wasted potential.Michael has been a professional programmer and architect for nearly 20 years. During that time, he has delivered running systems to the U. S. Government, the military, banking, finance, agriculture, and retail industries. More often than not, Michael has lived with the systems he built. This experience with the real world of operations changed his views about software architecture and development forever.
He worked through the birth and infancy of a Tier 1 retail site and has often served as "roving troubleshooter" for other online businesses. These experiences give him a unique perspective on building software for high performance and high reliability in the face of an actively hostile environment.
Most recently, Michael wrote "Release It! Design and Deploy Production-Ready Software", a book that realizes many of his thoughts about building software that does more than just pass QA, it survives the real world. Michael previously wrote numerous articles and editorials, spoke at Comdex, and co-authored one of the early Java books.
Presentations by Michael Nygard
Design for Operations
If your software fails in production, nobody will care how great the development project was, or how well the system passed QA. Production operations, the domain of your systems' least-appreciated stakeholders, is where the rubber meets the road. Come learn how to build your systems to thrive in Operations."Failures Come In Flavors (part 1)
The typical JEE application does not reach the fabled "five nines" of availability. Far from it. It's more like "double eights". Come see why enterprise applications and web sites are only serving users 88% of the time instead of 99.999%.Part 1 of 2"
Failures Come In Flavors (part 2)
What can we do about the dismal uptime of typical applications? We are asked to provide "five nines", but only reach 88%, on average. Come learn how to prevent the Stability Antipatterns from biting you. Apply these Stability Patterns to contain damage, recover from shocks, and survive disasters.Part 2 of 2
"
The 90-Minute Startup
Cloud computing is taking the world by storm. Amazon's Web Services, EC2, and S3 provide completely virtual infrastructure, letting startup and existing companies create sites and web applications faster than ever before.In this session, Michael will use cloud computing to create and deploy a fully-functional web site. You will learn how to create and run your own virtual infrastructure in the clouds."
Failure Comes in Flavors: Part One
The typical JEE application does not reach the fabled "five nines" of availability. Far from it. It's more like "double eights". Come see why enterprise applications and web sites are only serving users 88% of the time instead of 99.999%.The bad news: applications are more complex and error-prone than ever. Site development projects are really enterprise application integration projects in disguise. SOA portends far-flung interdependencies among unreliable services. Failures will spread wider and wider, reaching across your company and even crossing boundaries between companies.
How do monumentally costly failures begin, develop, and spread?
Can they be averted?
Once you hit Release 1.0, your system will be living in the real world. It has to survive everything the messy, noisy real world can throw at it: from flash mobs to Slashdot. Once the public starts beating on your system, it has to survive--without you.
Did you know that just having your database behind a firewall can bring down your system? Ill show you that and many other risks to your system. You will learn the biggest risks to your system and how to counter them with stability design patterns. We'll talk about the best way to define the term "availability" and why the textbooks get it all wrong.
"
Failure Comes in Flavors: Part Two
What can we do about the dismal uptime of typical applications? We are asked to provide "five nines", but only reach 88%, on average. Come learn how to prevent the Stability Antipatterns from biting you. Apply these Stability Patterns to contain damage, recover from shocks, and survive disasters.In part 1, we looked at common sources of system failure: those commonly created structures that exacerbate problems.
Now, we'll take on Stability Patterns that not only stop the antipatterns, but also add resilience to your system. Apply your new failure-oriented mindset to unchain yourself from the pager and save your company from embarrassing--and costly--disasters.
These patterns combat entire classes of failure modes, making your system robust against even unforeseen problems.
"
Clouds, Grids, and Fog
Servers, storage, networking, backups... they're all vanishing into the "clouds". Cloud Computing is the emerging architecture for massive, scalable infrastructure that your company doesn't have to own or operate.From the "zero servers" web startup to the corporate IT department battling server-sprawl, cloud computing has many manifestations. This session will differentiate among the various types of cloud computing and describe applicable use cases.
"
Books by Michael Nygard
by Michael Nygard (co-author)
-
Published in 1996, this early Java book took the reader deeper into Java than any other single volume on the market.
Michael co-authored several chapters including explorations of the Observer pattern--which later became the foundation of the JavaBeans event model--and the Java-to-C bridging tool "javah".
- Available At:
by Michael Nygard
-
Whether it's in Java, .NET, or Ruby on Rails, getting your application ready to ship is only half the battle. Did you design your system to survive a sudden rush of visitors from Digg or Slashdot? Or an influx of real world customers from 100 different countries? Are you ready for a world filled with flaky networks, tangled databases, and impatient users?
If you're a developer and don't want to be on call at 3AM for the rest of your life, this book will help. - Available At: http://pragmaticprogrammer.com/titles/mnee/index.html
Wide Awake Developers
An ongoing examination of what it means to be an IT professional in today's world.
Sunday, August 24, 2008
A short while back, I did a brief series on the value of "dirty data"---copious amounts of unstructured, non-relational data created by the many interactions user have with your site and each other.
ReadWriteWeb has a post up about Four Ad-Free Ways that Mined Data Can Make Money, along very similar lines. Well worth a read.
Tuesday, August 19, 2008
O'Reilly is creating a new line of "community-authored" books. One of them is called "97 Thing Every Software Architect Should Know".
All of the "97 Things" books will be created by wiki, with the best entries being selected from all the wiki contributions.
I've contributed several axioms that have been selected for the book:
- Talk about the arch, but see the scaffolding beneath it
- You're negotiating more often than you think
- Software architecture has ethical consequences
- Everything will ultimately fail
- Engineer in the white spaces
Long-time readers of this blog may recognize some of these themes.
You can see the whole wiki here.
Tuesday, August 19, 2008
Stewart Brand's famous book How Buildings Learn
The finished-looking model and visually obsessive renderings dominate the let's-do-it meeting, so that shallow guesses are frozen as deep decisions. All the design intelligence gets forced to the earliest part of the building process, when everyone knows the least about what is really needed.
Wow. It's hard to tell what industry he's talking about there. It could easily apply to software development. No wonder Brand is so well-regarded in the Agile community!
Another wonderful parallel is between what Brand calls "Low Road" and "High Road" buildings. A Low Road building is one that is flexible, cheap, and easy to modify. It's hackable. Lofts, garages, old factory floors, warehouses, and so on. Each new owner can gut and modify it without qualms. A building where you can drill holes through the walls, run your own cabling, and rip out every interior wall is a Low Road building.
High Road buildings evolve gradually over time, through persistent care and love. There doesn't necessarily have to be a consistent--or even coherent--vision, but each own does need to feel a strong sense of preservation. High Road buildings become monuments, but they aren't made that way. They just evolve in that direction as each generation adds their own character.
Then there are the buildings that aren't High or Low Road. Too static to be Low Road, but not valued enough to be High Road. Resistant to change, bureaucratic in management. Diffuse responsibility produces static (i.e., dead) buildings. Deliberately setting out to design a work of art, paradoxically, prevents you from creating a living, livable building.
Again, I see some clear parallels to software architecture here. On the one hand, we've got Low Road architecture. Easy to glue together, easy to rip apart. Nobody gets bent out of shape if you blow up a hodge-podge of shoestring batch jobs and quick-and-dirty web apps. CGI scripts written in perl are classic Low Road architecture. It doesn't mean they're bad, but they're probably not going to go a long time without being changed in some massive ways.
High Road architecture would express a conservativism that we don't often see. High Road is not "big" architecture. Rather, High Road means cohesive systems lovingly tended. Emacs strikes me as a good example of High Road architecture. Yes, it's accumulated a lot of bits and oddments over the years, but it's quite conservative in its architecture.
Enterprise SOA projects, to me, seem like dead buildings. They're overspecified and too focused on the moment of rollout. They're the grand facades with leaky roofs. They're the corporate office buildings that get gerrymandered into paralysis. They preach change, but produce stasis.
Sunday, August 17, 2008
Dan Pritchett is a man after my own heart. His latest post talks about the path to availability enlightenment. The obvious path--reliable components and vendor-supported commercial software--leads only to tears.
You can begin on the path to enlightenment when you set aside dreams of perfect software running on perfect hardware, talking over perfect networks. Instead, embrace the reality of fallible components. Don't design around them, design for them.
How do you design for failure-prone components? That's what most of Release It! is all about.
Friday, August 8, 2008
There seems to be something inherently contradictory about "Enterprise" agile tool vendors. There's never been a tool invented that's as flexible in use or process as the 3x5 card. No matter what, any tool must embed some notion of a process, or at least a meta-process.
I've looked at several of the "agile lifecycle management" and "agile project management" tools this week. To me, they all look exactly like regular project management tools. They just have some different terminology and ajax-y web interfaces.
Vendors listen: just because you've got a drag-and-drop rectangle on a web page doesn't make it agile!
The point of agile tools isn't to move cards around the board in ever-cooler ways. It isn't to automatically generate burndown graphs and publish them for management.
The point of agile tools is this: at any time, the team can choose to rip up the pavement and do it differently next iteration.
What happens once you've paid a bunch of money for some enterprise lifecycle management tool from one of these outfits? (Name them and they appear; so I won't.) Investment requires use. Once you've paid for something---or once your boss has paid for it---you'll be stuck using it.
Now look, I'm not against tools. I use them as force multipliers all the time. I just don't want to get stuck with some albatross of a PLM, ALM, LFCM, or LEM, just because we paid a gob of money for it.
The only agile tools I want are those I can throw away without qualm when the team decides it doesn't fit any more. If the team cannot change its own processes and tools, then it cannot adapt to the things it learns. If it cannot adapt, it isn't agile. Period.
