Every session, keynote, and workshop slot — sorted by day so you can plan your path through the conference.
With supercomputers in our pockets, self-driving vehicles, and software recognizing images better than humans, what we recently thought of as the future is already here, so how do we define the next future?
Rod Cope explains how different aspects of artificial intelligence, augmented reality, high-performance computing, digital platforms, massive bandwidth, and an obsessive focus on user experience will be the fundamental drivers to future application success as we build upon lower barriers to entry and shift from improving technology to improving life. Rod shares his 20+ year journey from the forefront of open source to a predicted future where the IoT and big data are the new normal and the key questions are less “How can we do it?” and more “How do we make it better?” Join us to learn what you can do now in terms of research, planning, and investment to get the most out of our inevitable future.”
Serverless, Function-as-a-Service (FaaS) and Backend-as-a-Service (BaaS) are the new rage. They promise less cost, less hardware, less operations people and less time to market. But is it really less? What is serverless? Is it different than what you are doing today? Is it the right direction and architecture for your business? What are its strengths and weaknesses? How does it impact your development and operations processes? This session will answer all your questions about serverless and help you determine if it an approach worth pursuing.
This session will insure managers and technical leaders have a good knowledge of what serverless is and is not. It will explain the unique challenges and benefits offered by serverless architectures. It will provide insights into the skills and training teams will need to be successful. It will also explain budgeting and and estimating this new model of infrastructure and development.
According to every metric half of the IT industry has less then 5 years of experience. This fact identifies a challenge of skill gap that most organizations are not prepared handle. As leaders, we need to help young talent to fill their gaps to become productive contributors quickly. This session will provide strategies and lessons learned from hiring and training over 130 recent college grads over the last 7 years through an immersive bootcamp and oversight. You will learn how to make your young talent more successful and therefor your organization more successful.
This session will include proven strategies for:
A recent Gartner survey found that 40% of all enterprise architecture efforts were failing or had failed. One of the primary reasons for these failed attempts at enterprise architecture is a lack of understanding about what enterprise architecture is and whether the high cost of creating an enterprise architecture practice produces any business value or business results. In this session we will explore why enterprise architecture is so important to business (especially today's businesses) and how to either restart or revitalize you enterprise architecture effort to produce results.
Agenda:
Choosing the right enterprise architecture strategy is essential to not only make enterprise architecture a successful venture, but to also help the company move forward in its goals. In this session I will describe 4 different strategies for enterprise architecture and show you which strategy fits which business model. Do you have the right EA strategy in place for your organization? Come to this session to find out!
Agenda
Are you merging with another company? Acquiring new businesses? Moving to a new line of business? Transforming your enterprise? Engaging in cost-cutting efforts? Fully Automating your pipelines? Retiring old and expensive mainframe systems? These are initiatives that most businesses are engaging in. While there are dozens of activities within an enterprise architecture effort, there is only one primary outcome, and that is to develop an enterprise architecture roadmap. Roadmaps describe what efforts (i.e., projects) need to be done to meet a specific objective, the dependencies between those efforts, and the prioritization of those efforts. In this session I'll cover some of the models that make up an EA roadmap and show you techniques for how to identify projects, classify projects, prioritize projects, and finally illustrate these efforts through consolidated roadmap views. By the end of this session you'll have a clear view of why enterprise architecture is needed and how to create an effective and clear enterprise architecture roadmap.
Agenda:
Software architecture is hard. It is full of tradeoff analysis, decision making, technical expertise, and leadership, making it more of an art than a science. The common answer to any architecture-related question is “it depends”. To that end, I firmly believe there are no “best practices” in software architecture because every situation is different, which is why I titled this talk “Essential Practices”: those practices companies and architects are using to achieve success in architecture. In this session I explore in detail the top 6 essential software architectural practices (both technical architecture and process-related practices) that will make you an effective and successful software architect.
This session is broken up into 2 parts: those essential architecture practices that relate to the technical aspects of an architecture (hard skills), and those that relate to the process-related aspects of software architecture (soft skills). Both parts are needed to make architecture a success.
Microservices is one of the latest software architecture styles that promises to deliver benefits such as ease of testing, fast and easy deployments, fine-grained scalability, fault tolerance, and overall agility. It is undeniably one of the latest trends in the software industry, and most companies seem to be jumping on the bandwagon to quickly embrace and adapt this new architecture style. Unfortunately, as many companies are painfully experiencing, microservices is a fairly complex architecture style that is not suited for all applications and environments. In this session I will show you a high-level architectural view of the microservices architecture style so you can gain a high-level understanding about how it works and what challenges exist with this complex architecture style.
Agenda:
The traditional approaches to enterprise architecture have worked well for many decades. However, adherence to the traditional approaches of EA is one of the leading reasons why most enterprise architecture efforts fail. In this session I discuss the 2 primary classical approaches to enterprise architecture and why they no longer work in today's market. I then discuss several modern approaches to enterprise architecture that are increasingly showing promise for both small and large organizations.
Agenda:
Everyone knows security is important. Very few organizations have a robust and comprehensive sense of whose responsibility it is, however. The consequence is that they have duct-tapped systems and a Policy of Hope that there will be no issues. (Spoiler: there will be)
We will review the various roles that most organizations need to fill and how they overlap as well as what should and can be expected from each of them.
Machine Learning is a key differentiator for modern organizations, but where does it fit into larger IT strategies? What does it do for you? How can it go wrong?
This class will contextualize these technologies and explain the major technologies without much (if any) math.
We will cover:
If you listen to zealots and critics, blockchain-based systems and the cryptocurrencies they enable are either the Best Thing Ever or the Worst Thing Ever. As you may suspect, the reality is somewhere in-between. We will introduce the major ideas, technologies and players as well as evaluate them from technological, economic and social perspectives.
Come have a spin-free discussion about these polarizing technologies to find how they might be useful to you.
Big Data is exploding into our industry and the implications go far beyond business intelligence. Much of our existing body of knowledge needs to be updated, however as Big Data solutions present a number of unique challenges. Big Data can be a competitive advantage or a major liability.
In this session we go into big data, the concepts, the pitfalls and everything you need to know to leverage this phenomenal tool.
Whether you want to effect culture change in your organization, lead the transition toward a new technology, or simply get more out of your team; you must first understand that having a “good idea” is simply the beginning. An idea must be communicated; a case must be made. Communicating that case well is as important, if not more so, than the strength of the idea itself.
You will learn 6 principles to make an optimal case and dramatically increase the odds that the other person will say “Yes” to your requests and suggestions, along with several strategies to build consensus within your teams. As a professional mentalist, Michael has been a student of psychology, human behavior and the principles of influence for nearly two decades. There are universal principles of influence that are necessary to both understand and leverage if you want to be more effective leader of change in your organization.
Join us for this thought provoking journey of discovery as we explore the real strategies that you can apply today as you architect your new or existing stack to satisfy the ever-increasing demand for 'real-time' applications and data services, fed by reactive data sources, regardless of your current technology choices.
Users are demanding applications which keep them informed of new events as soon as they happen. They are no longer willing to accept “Just hit the refresh button” or “It will update in a few minutes by itself” when demanding satisfaction of this new basic requirement. They are collaborating in real time, co-editing, co-authoring, 'co-labor-ating' with colleagues across the country and around the world, chatting over the phone or VOIP while working together via your app. They want their updates to travel from their laptop to their co-workers screens as fast as their voice reaches them through the phone. This is a tough requirement to meet, especially when trying to put a modern face on a legacy app or integrating a shiny, new, reactive app with a legacy, REST-based datasource.
And it is not just your end-users that are clamoring for reactive data sources. No, the requirements for server-to-server communication of changes to data or state have forever changed. REST no longer is King in the world of web services. REST just doesn't cut the mustard any longer. Users of your data services are also demanding more flexible, reactive options when consuming your endpoints. They want to be able to subscribe to specific data sets and be updated in near-real-time when changes occur without the need to poll your APIs for such changes.
Join us for this thought provoking journey of discovery as we explore the real strategies that you can apply today as you architect your new or existing stack to satisfy the ever-increasing demand for 'real-time' applications and data services, fed by reactive data sources, regardless of your current technology choices.
Architecture is as important as functionality, at least in the long run. As functionality is recognized as a business asset, it follows that architecture is a business asset, too. In this talk we show how we can approach architecture as an investment rather than a cost, and detail the practical implications both on the technical and on the business level.
Often systems that have great current value are expensive to evolve. In other words, the future value of the system is highly influenced by its structure. Indeed, when I talk with technical people, they broadly agree with the idea that architecture is as important as functionality, at least in the long run.
If we truly believe this, we should act accordingly. If two things are equally important, we should treat them with the same way. Given that functionality of a system is considered a business asset, it follows that the architecture is a business asset as well. That means that we should stop perceiving the effort around architecture as a cost, and start seeing it as an investment.
Functionality receives significant testing investments through direct development effort, dedicated tools and even education. In a way, testing is like an insurance, but unlike other insurances, this one is essentially guaranteed to pay off later on. Now, do you check the architecture with the same rigor? Do you have automatic architectural checks that prevent you from deploying when they fail? Not doing so means that half of the business assets remain uninsured. Half.
How can you test architecture automatically? You need to first see the code as data. The same applies for configurations, logs and everything else around a software system. It’s all data, and data is best dealt with through dedicated tools and skills.
“Technical debt” is a successful metaphor that exposes software engineers to economics, and managers to a significant technical problem. It provides a language that both engineers (“technical”) and managers (“debt”) understand.
But, “technical debt” is just a metaphor that has its limitations, too. The most important limitation is that it presents a negative proposition: The best thing that can happen to you is having no technical debt.
Technical debt is both brought about and solved as a result of decisions. As such, we turn our attention to how people reach decisions about a software system. Decision making is a critical software engineering activity. Developers alone spend some half of their time reading code. This means half of the budget. Even though it is the single most significant development activity, nobody really talks about how this effort is being spent.
It’s time to change this. The talk motivates the need for software assessment as an explicit discipline, it introduces the humane assessment method and outlines the implications.
The #remote, #nomeetings, #noestimates, #nobacklog recent trends tend to disrupt the classic approach to software development. In this talk, we explore this space also based on my own experience of working with teams to build projects that rely on all these.
Can #remote, #nomeetings, #noestimates, #nobacklog really work? What if we employ them at the same time? If we look at the open-source space, we see that we indeed can build highly successful and innovative projects while working completely remotely, rely almost exclusively on asynchronous communication, rely on no estimates and even no real backlog.
What does that mean for the enterprise? At the very least, we should accept that these are not a fad, and we should not equate them with lack of engineering. Instead, we should look at successful examples and learn from them. In this talk, we do exactly that. We go through concrete examples and observe the implications on the way we work and on the systems we can build.
The legend of the Senior Engineer describes engineers so experienced, that they contribute as much as 10 junior ones. While these senior engineers have definitely been spotted in the wild, hiring senior is not always the best course of action.
In this talk we'll examine the principal that guide the building of sports team, and apply those to engineering teams. We'll debate on topics such when to hire senior, when to hire junior, and when it doesn't matter.
We're all familiar with the traditional model - software is built by the technology team and handed off to marketing and sales. While most companies operate that way, some of the biggest successes use an entirely different model. A Full Stack Business is one where technology is building the business itself, and everything that's needed to scale it. Whether it's ride sharing, online marketplaces, or anything else, a Full Stack Business is very different from your traditional tech company.
In this talk, we'll cover what a Full Stack Business is, what it means to be on the technology team in one, and get some tips on how to succeed in one.
The lean startup is changing the way companies are built and new products are launched. In this session we dive into the concepts and ideas as well as strategies to incorporate into your own organization.
.
Software systems should not remain black boxes. In this talk we show how we can complement domain-driven design with tools that match the ubiquitous language with visual representations of the system that are produced automatically. We experiences of building concrete systems, and, by means of live demos, we exemplify how changing the approach and the nature of the tools allows non-technical people to understand the inner workings of a system.
Software appears to be hard to grasp especially for non-technical people, and it often gets treated as a black box, which leads to inefficient decisions. This must and can change.
In this talk we show how by changing our tools we can expose the inner workings of a system with custom visual representations that can be produced automatically. These representations enhance the ubiquitous language and allow non-technical people to engage actively with the running system.
We start from describing experiences of building concrete systems, and, by means of live demos, we exemplify how changing the approach and the nature of the tools allows non-technical people to understand the inner workings of a system. We then take a step back and learn how we should emphasize decision making in software development as an explicit discipline at all layers, including the technical ones. This talk is accompanied is relevant for both technical and non-technical people.
Looking at what occupies most of our energy during software development, our domain is primarily a decision making business rather than construction one. As a consequence, we should invest in a systematic discipline to approach making decisions.
Assessment denotes the process of understanding a given situation about a software system to support decision making.
During software development, engineers spend as much as 50% of the overall effort on doing precisely that: they try to understand the current status of the system to know what to do next. In other words, assessing the current system accounts for half of the development budget. These are just the direct costs. The indirect costs can be seen in the quality of the decisions made as a result.
One might think that an activity that has such a large economical impact would be a topic of high debate and improvement. Instead, it is typically treated like the proverbial elephant in the room. In this talk, we argue that we need to:
• Make assessment explicit. Ignoring it won’t make it go away. By acknowledging its existence you have a chance of learning from past experiences and of optimizing your approach.
• Tailor assessment. Currently, developers try to assess the system by reading the source code. This is highly ineffective in many situations, and it simply does not scale to the size of the modern systems. You need tools, but not any tools. Your system is special and your most important problems will be special as well. That is why generic tools that produce nice looking reports won’t make a difference. You need smart tools that are tailored to your needs.
• Educate ourselves. The ability to assess is a skill. Like any skill, it needs to be educated. Enterprises need to understand that they need to allocate the budget for those custom tools, and engineers need to understand that it is within their reach to build them. It’s not rocket science. It just requires a different focus.
Our technical world is governed by facts. In this world Excel files and technical diagrams are everywhere, and too often this way of looking at the world makes us forget that the goal of our job is to produce value, not to fulfill specifications.
Feedback is the central source of agile value. The most effective way to obtain feedback from stakeholders is a demo. Good demos engage. They materialize your ideas and put energies in motion. They spark the imagination and uncover hidden assumptions. They make feedback flow.
But, if a demo is the means to value, shouldn’t preparing the demo be a significant concern? Should it not be part of the definition of done?
That is not even all. A good demo tells a story about the system. This means that you have to make the system tell that story. Not a user story full of facts. A story that makes users want to use the system. That tiny concern can change the way you build your system. Many things go well when demos come out right.
Demoing is a skill, and like any skill, it can be trained. Regardless of the subject, there always is an exciting demo lurking underneath. It just takes you to find it. And to do it.
In this session we will get to exercise that skill.
Marshall McLuhan told us among other things that “We shape our tools and thereafter our tools shape us.” If this is true, we should be very careful with the tools that we expose ourselves to because they will determine the way we are going to think.
Quick question: did you check your phone within 5 minutes of waking up this morning? Likely, yes. Yet, this seemingly imperious need did not exist before the iPhone brought it in our world.
The tools we use have a deep influence on our behavior. This is particularly relevant in our increasingly digital world, and it has a critical impact in the way we approach software. Just think of this: software is data, and data has no particular shape. Yet we as humans require shape to be able to reason about something. But, the shape of software is provided by our tools. This means that we must scrutinize the tools we use and make our choices with as much care as we do any other significant architectural choice.
In this talk, we show examples of how the tools influence the way we think, and look carefully at how we should equip our environment to foster better software.
Technology changes, it's a fact of life. And while many developers are attracted to the challenge of change, many organizations do a particularly poor job of adapting. We've all worked on projects with, ahem, less than new technologies even though newer approaches would better serve the business. But how do we convince those holding the purse strings to pony up the cash when things are “working” today? At a personal, how do we keep up with the change in our industry?
This talk will explore ways to stay sharp as a software professional. We'll talk about how a technology radar can help you stay marketable (and enjoying your career) and how we can use the same technique to help our companies keep abreast of important changes in the technology landscape. Of course it isn't enough to just be aware, we have to drive change - but how? This talk will consider ways we can influence others and lead change in our organizations.
You built the app. You are ready to launch! But how do you proceed from there? You need to ensure that, once deployed, your app remains 'up', healthy, available and secure. For that, you are going to need some serious tools in your belt! Join us as we explore the tools and services you can use to complete your deployment stack and give you all of the monitoring and control that you need for a successful launch!
You built the app. You are ready to launch! But how do you proceed from there? You need to ensure that, once deployed, your app remains 'up', healthy, available and secure. For that, you are going to need some serious tools in your belt! Join us as we explore the tools and services you can use to complete your deployment stack and give you all of the monitoring and control that you need for a successful launch!
We constantly hear that change should be affordable and cost effective. True, but, in reality, that's easily said than done. Complexity makes change hard. We can't shy away from the hard problems posed by domains and business needs. So, how can we solve complicated problems without getting dragged into the quagmire of what appears to be an inevitable complexity? In this keynote, an award winning author and software practitioner will share experiences and observations from working on multiple software projects, about what leads to complexities, the traps developers and organizations fall into, and what we can do to effectively deal with these common, recurring issues we see across domains and products.
.
“Forewarned is forearmed”
-Old Proverb
If it seems like humans are easy to deceive, it's because we are. The myriad traits that make humankind so eminently exploitable are practically baked into our DNA. Too often these same traits make it into the software we build. This session takes an entertaining look at why humans are so easy to fool and goes on to explore what we can do to overcome our weaknesses and build more secure software.
Security is everyone's responsibility but the burden disproportionally falls on us. As software engineers, we are the last line of defense in our organization. We build the technology and that technology is constantly scanned, probed, and tested. Building truly secure software requires going beyond mere functional requirements; it requires a complete shift in how we think about problems.
It seems like all anyone talks about these days is making our architectures more modular and whether microservices is the answer. The question is, should your business embrace microservices and similar highly modular architectures or stick with what you have? In this session I will describe the business value, business benefits, and drivers associated with moving towards architectural modularity. Once you understand the drivers for architectural modularity, you can them make an informed decision about whether you should embrace architectural modularity in your company or run away from it as fast as possible.
Agenda:
Recurly powers subscription billing for some of the largest brands out there. I was their CTO during a period of growth that saw employee count, API traffic, total payment volume and revenue grow significantly. Engineering did many things right and we clearly did many things wrong.
I will recount my experience and lessons learned.
As a technical leader or software development manager, you're eager to remove impediments so your team can produce continuous results. Instilling a few technical practices can have significant impact on your teams ability to deliver continuous results.
In this presentation we will cover the what, why, and how of essential technical practices that take time and effort but they result in saving significant cost and time in the long run.
Finance has been shaped by Information technology since the beginning of human civilization. Banking and Finance have been early adopters on information technologies because money is one of the purest information goods. From the earliest coins to cryptocurrencies; from bills of exchange to collateralized debt obligations; from smoky London cafes to nanosecond trading latencies - the evolution of finance has been a barometer of the evolution of technology.
This talk will focus on the history of technology in finance as a way to understand how technology shapes an industry. In a future where all industries are being shaped by information technology, the lessons from finance are a useful background for technology leaders to understand.
The evolution of technology companies from a few people hacking to large valuable public companies requires strong technical managers. Technical management can be viewed through the lens of two important transitions - The first the transition from being an individual engineer to a manager of people; the second transition from a manager of individual contributors to a manager of managers. Understanding these two transitions and navigating them effectively is a critical skill.
This talk will address the key skills and behaviors that managers need to master in order to navigate these transitions and become successful executives.
Every organization has at least a phalanx or two in the “Cloud” and it is, understandably changing the way we architect our systems. But your application portfolio is full of “heritage” systems that hail from the time before everything was as a service. Not all of those applications will make it to the valley beyond, how do you grapple with your legacy portfolio? This talk will explore the strategies, tools and techniques you can apply as you evolve towards a cloud native future.
In this talk, you will learn:
If you’ve spent any amount of time in the software field, you’ve undoubtably found yourself in a (potentially heated) discussion about the merits of one technology, language or framework versus another. And while you may have enjoyed the technical debate, as software professionals, we owe it to our customers (as well as our future selves) to make good decisions when it comes to picking one technology over another.
In this talk, I will explore what criteria we should consider when comparing technologies, how we can avoid burning platforms as well as what to do when we’ve reached a dead end. We will also apply these techniques to a current technology or two.
Developer First leadership does not depend on accumulating power within a team or company. Instead, it focuses on the needs of the developers, their technical and career growth, and building positive team cultures.
This session will cover 7 different tactics to practice Developer First leadership. These include empowering others, the importance of diversity & inclusion on our dev teams, establishing a positive developer onboarding experience, and how to become an authentic and respected leader.
Participants of this talk will learn how to successfully navigate the complexities of Engineering Leadership; regardless of your title!
Approaches to managing technology architecture across a diverse enterprise tend to be pretty bipolar: either a huge formal ivory-tower framework that produces reams of standards and documentation that no one actually uses, or really no framework at all and everything is self-organizing chaos. These two approaches tend to have identical outcomes, with the former just having more bureaucracy involved than the latter.
In this session, we'll talk about several practical things you can do to put some minimal structure and governance around architectural chaos without moving into the ivory tower and becoming irrelevant.
Welcome, bold adventurer! Are you ready to work with me to explore the multiple paths of deployment, activation, and feature flags? The audience drives the talk by choosing different deployment and activation options in real time and we’ll see how the story ends.
We’ll use this format to explore how feature flags can work with CI/CD or other rapid deployment models, and how we can work to make deployments safer and faster incrementally.
Audiences will get a fun, fast-paced exploration of forking deployments. They’ll walk away with an understanding of how to reduce the risk of major changes, how to follow multiple streams of deployment, and how to evaluate the best way to speed deployment in their environments.
This really is a dynamic, audience driven presentation. They'll select branching options, and I'll create the talk on the fly based on pre-determined options. As such, it's going to be hard to show you the outline. Topics I intend to cover include feature flags, scaled deployments, and kill switches.
Lots of us aren’t developing tidy, discrete features that are easy to manage. How do you plan to move from a tangle of interconnected features to something that you can test and deploy each part of? How do you manage the combinatorial complexity of individual feature testing? Join us for an overview on the conceptual basis of designing for feature management.
It sounds simple to say that we will build one feature at a time, give it an API interface and allow it to connect with other features and microservices. The implementation is anything but simple. This talk explores how you can start migrating your existing features and services to a more modular, testable, and resilient system.
Since containers are not state-aware, how do you make changes to their presentation without needing to rebuild them entirely? With feature flags, your container can be stable and your presentation dynamic. How can you test a distributed architecture on your laptop? How can you simulate partial outages? This talk is going to touch on some of the best practices that you can use to bring new life to your brown fields.
We never change the amount of work or technical debt, we just shift it, and with it, we change how it emerges and appears.
Our systems don’t have to be perfect to be operational - planes, networks, and elite athletes all function at extremely high levels even though they are not operating at 100%.
The audience will leave with some concrete ideas about how to add resiliency to their system by learning to trust but mitigate their reliance on perfect performance of their underlying tools.
As an industry, we have moved the locus of control from hardware to operating system to virtual machine, to container, to orchestration, and now we are approaching serverless. None of that has reduced the amount of work that must happen, it just makes it possible to re-use and conceptually compress the work of others. Since we are making the work in our tools less visible, we also have less control over how they work. We end up assuming that the promises that have been true will continue to be true, but that is not in our control.
How do we handle this level of uncertainty? By adding in error budgets, layered access, and other accommodations for failure and for designing our systems for function over form or purity.
Since the dawn of software development, we've struggled with a huge disconnect between the management world and the engineering world. We try to explain our problems in terms of “technical debt”, but somehow the message seems to get lost in translation, and we drive our projects into the ground, over and over again.
What if we could detect the earliest indicators of a project going off the rails, and had data to convince management to take action? What if we could bridge this communication gap once and for all?
In this session, we'll focus on a key paradigm shift for how we can measure the human factors in software development, and translate the “friction” we experience into explicit risk models for project decision-making.
What makes software development complex isn't the code, it's the humans. The most effective way to improve our capabilities as an organization is to better understand ourselves.
In this session, we'll breakdown the dynamics of culture into explicit architecture models based on a synthesis of research that spans cognitive science, biology and philosophy. We'll discuss the nature of Identity, communication, relationships, leadership and human motivation by thinking about humans like code!
If you want to better understand the crazy humans around you, you won't want to miss this talk!
Once upon a time, it was just me and my app – the days when all I had to know was “get data, put on screen.” Fast forward ten years later, and what the hell happened? The level of complexity that we deal with in modern software development is insane.
Are we really better off than we were 10 years ago, or have we just been putting out our fires with gasoline?
In this session, we'll turn the projector off, and focus on a deep-dive discussion, contrasting the world of 10 years ago versus today. Rather than generalizations and hand-waiving about the golden promises of automation and magic frameworks, we're going to question everything and anchor our discussions in concrete experience.
Looking back across your career in software development, how has the developer experience changed?
First, we'll dig into the biggest causes of friction in software development, and how our solutions have created new problems. Then we'll focus on distilling strategies for overcoming these challenges, and how we can take our teams, and our industry in a better direction.
Recurly powers subscription billing for some of the largest OTT providers on the internet. And with that, Recurly has had to support some of the historically most streamed events of the past decade including the Super Bowl, World Cup, NBA, NCAA Football, NCAA Basketball including March Madness, Grammy’s, McGregor Vs Mayweather and other PPV events.
I will recount my experience as their CTO, lessons learned and things we clearly did wrong.
Software has no shape. Just because we happen to type text when coding, it does not mean that text is the most natural way to represent software.
We are visual beings. As such we can benefit greatly from visual representations. We should embrace that possibility especially given that software systems are likely the most complicated creations that the human kind ever produced. Unfortunately, the current software engineering culture does not promote the use of such visualizations. And no, UML does not really count when we talk about software visualizations. As a joke goes, a picture tells a thousand words, and UML took it literally. There is a whole world of other possibilities out there and as architects we need to be aware of them.
In this talk, we provide a condensed, example-driven overview of various software visualizations starting from the very basics of what visualization is.
Visualization 101:
How to visualize
What to visualize
Interactive software visualizations
Visualization as data transformation
As Tech Leaders, we are presented with problems and work to find a way to solve them, usually through technology. In my opinion this is what makes this industry so much fun. Let's face it - we all love challenges. Sometimes, however, the problems we have to solve are hard - really hard. So how do you go about solving really hard problems? That's what this session is about - Heuristics, the art of problem solving. In this session you will learn how to approach problems and also learn techniques for solving them effectively. So put on your thinking cap and get ready to solve some easy, fun, and hard problems.
Agenda:
Agile development is about adapting to change and deliver what's relevant to the customers and business. The vehicle to get there has wheels on two sides. Organizations often tend to focus on one side, the business aspect and the technical practices and discipline seems to go by the wayside. In spite of all the good intentions, the development turns into a crisis and becomes unmanageable.
In this presentation we will talk about the cost of creating automated feedback loops, the cost of not creating it, and how to lead teams to create successful automated tests.
On the one hand, agile processes, like Scrum, promote a set of practices. On the other hand, they are based on a set of principles. While practices are important at present time, principles allow us to adapt to future situations.
In this talk we look at Inspection and Adaptation and construct an underlying theory to help organizations practice these activities. Why a theory? Because, as much as we want to, simply invoking “Inspect and Adapt” will not make it happen.
It turns out that for almost half a century the software engineering community has been working on a theory of reflection, which is defined as “the ability of a system to inspect and adapt itself”. We draw parallels between the design of software systems and the design of organizations, and learn several lessons:
Reflection must be built into the organization.
Reflection incurs a cost that must be planned for.
Inspection is easier than adaptation.
We can only reflect on what is explicit.
Reflection is a design tool that enables unanticipated evolution.
This sounds technical, but the most important observation is that reflection is an inherent human ability. It only requires training to develop it into a capability.
“Emerge your architecture” goes the agile mantra. That’s great. Developers get empowered and fluffy papers make room for real code structure. But, how do you ensure the cohesiveness of the result?
In this talk, we expose how architecture is an emergent property, how it is a commons, and we introduce an approach for how it can be steered.
To steer means three at least things:
When it comes to steering agile architecture, of the above three, only the second point is about design. The first and the third points are about software assessment. While the literature covers the design aspect in detail, the assessment issues are left open.
In this talk, we focus on how by integrating software assessment in the daily development process we can make steering agile architecture a reality.
Too often, developers drill into the see of data related to a software system manually armed with only rudimentary techniques and tool support. This approach does not scale for understanding larger pieces and it should not perpetuate.
Software is not text. Software is data. Once you see it like that, you will want tools to deal with it.
Developers are data scientists. Or at least, they should be.
50% of the development time is typically spent on figuring out the system in order to figure out what to do next. In other words, software engineering is primarily a decision making business. Add to that the fact that often systems contain millions of lines of code and even more data, and you get an environment in which decisions have to be made quickly about lots of ever moving data.
Yet, too often, developers drill into the see of data manually with only rudimentary tool support. Yes, rudimentary. The syntax highlighting and basic code navigation are nice, but they only count when looking into fine details. This approach does not scale for understanding larger pieces and it should not perpetuate.
This might sound as if it is not for everyone, but consider this: when a developer sets out to figure out something in a database with million rows, she will write a query first; yet, when the same developer sets out to figure out something in a system with a million lines of code, she will start reading. Why are these similar problems approached so differently: one time tool-based and one time through manual inspection? And if reading is such a great tool, why do we even consider queries at all? The root problem does not come from the basic skills. They exist already. The main problem is the perception of what software engineering is, and of what engineering tools should be made of.
In this talk, we show live examples of how software engineering decisions can be made quickly and accurately by building custom analysis tools that enable browsing, visualizing or measuring code and data. Once this door is open you will notice how software development changes. Dramatically.