"It's just a detail." Have you ever said that or been told that? Whether it's about implementation or requirements, we often use the word detail to suggest that something is not important enough to worry about. There are so many things to worry about in software development that we need to prioritize—too much detail, not enough focus. The problem is that in software, the details matter because that is what software is: lots of details brought together in combination. If we don't focus on the details, we get debt, defects, and delays.
Mission-critical and even safety-critical applications have crept into the Internet of Things (IoT). In these applications, failure might lead to injury and even loss of life. This talk will present the architectural challenges that come with deploying mission-critical IoT systems in hazardous industries. Attendees will learn about hazardous industries, some of their challenges, and how the IoT can help. We will dive into new challenges that have emerged in the IoT, the need for trustworthy software, impacts on software architecture, and finally how to mitigate the threats from common mode failures, human error, and even malware. These things must be addressed before we have problems, not as a post-mortem of a capsized system.
I wrote my first program in the Spring of 2001, around the same time Mr. Agile moved into my neighborhood. I didn’t get to know him until early 2004 when his entourage grew into a dedicated community of fans and followers. Back then, I had one trusted mentor and an old friend, Mr. Architecture. Becoming friends with Mr. Agile was new and exciting but brought challenges to my relationship with my old friend. Therefore, growing up as a software professional was about learning how I could maintain friendships with both, reconcile their differences, and become better at what I do because of it. In a nutshell, I grew up in Mr. Agile’s world.
In this DEV@SATURN talk, I’ll narrate the story about growing up as friends with Mr. Agile and Mr. Architecture. I don’t intend to indulge the “agile vs. architecture” debate. On the contrary, I’ll annotate my story with examples from our journeys together, sharing experiences with some of Mr. Agile’s friends who advocated architecture sabotage as well as situations where the outcomes were better because I had a foot in both neighborhoods and had won the internal struggle about how to reconcile them. Join me in this talk—I’m sure you’ll find resemblances to your own journey.
The microservice architecture is becoming increasingly popular. However, frequent references to using “a microservice to solve a problem” suggest that the concept is not universally well understood. In this talk, I define the microservice architecture as an architectural style and explain what that actually means. I also describe how the primary goal of the microservice architecture is to enable continuous delivery and deployment, and how it achieves that. You will learn why the architecture that you pick for your application matters. And you will learn how to solve key challenges with decomposing an application into microservices. This talk explains why there is no such thing as a microservice!
Passionate individuals and businesses both try to create successful Communities of Practice (CoPs) for myriad reasons, from honest desire to networking to a financially driven goal of sharpening worker skills. Why do some well-funded efforts fail while rag-tag startups succeed? In this session, hear the story of my struggles and successes to grow a networked community of architects that now stretches across the globe. There is no single formula to creating a successful community. But if you've got passion and take the time to really ask "Why?" your journey will start off on the right foot! Choose vision-driven techniques over old-school mechanics to jump-start new groups or resurrect ailing ones. You will walk away energized and ready to try a few of the techniques that worked, such as
Software is an increasing part of our everyday lives. From the phones we carry, to the cars we drive, the thermostats that regulate our homes, even our lightbulbs, software is everywhere. But how much do we know about it? How secure is the banking app you use? What bugs might turn your home into a tropical paradise during your next winter trip? How convoluted is the code that runs your car? The last plane you took? The last traffic light you went through? As consumers, we take nutrition labels on food for granted. A few simple, standard numbers let us make smart choices about the food we consume. Similarly, quality numbers should be routinely available for software, which is omnipresent and unavoidable in modern life. As consumers, we should have the data to make smart choices. After all, candy bars will only kill you slowly. Bad code could kill you very quickly.
Enterprise IT organizations attract and foster mediocrity. This is a fundamental reason why large enterprises don’t outperform leaner organizations even though they have more resources. This talk describes a fictional organization (albeit slightly inspired from reality) with huge cultural problems to illustrate how bad enterprise IT can be and how it came to be this way. In the first half of this session, we describe the mess we're in and how we got there; in the second half, we consider how we could have avoided this situation and how we can get out of it. Our premise is that a solid culture of learning and continuous improvement as well as a focus on good software architecture and practices could have prevented the mess, and that it is not too late to turn it around. I promise an entertaining talk with a lot of humor, and possibly some insights that you can take back to your organization so that you don't end up in the same mess (if you aren't already there).
How we think of architecture shapes what we do as architects, and what we do, shapes how we think of architecture. We will explore our conception of architecture in this dual sense, with an emphasis on visualization and visual expression of design (intention and reflection).
Winner of the 2017 Linda Northrop Software Architecture Award, given to an individual or team that has used software architecture to significantly improve practices, outcomes, or both in an organization or in the software-development community.
The software development community is slowly realizing that maximizing the velocity of delivery is paramount. As Jack Welch said, "If you are not moving at the speed of the marketplace, you’re already dead—you just haven’t stopped breathing yet.” But it's an unfortunately accepted actuality that the software development and delivery velocity of an organization inexorably decrease over time. This happens not just in the context of a single codebase, which could be explained mostly by straightforward technical phenomena, but also across entire teams or companies. In this talk, I'll draw on my experiences with companies from tiny (startups I've co-founded) to large (Microsoft, Google) to offer some observations about the reasons behind the apparently unavoidable slowdown that software development teams experience. These reasons range from purely technical, such as the accretion of technical debt, to organizational and legal. But it's not all bad news: I'll also suggest a few concrete techniques that I've seen have a positive impact on velocity in software development.
