The speed of feature release for web and mobile apps continues to increase, but it can grow costly and time consuming to constantly rebuild and redeploy client applications—especially through app stores, where updates can take more than a week to appear. What if you could add new features to an existing client without repeatedly installing new versions of the application? What would the code look like? What changes are needed to create a client that can adapt to changes in the service API? How much change is reasonably possible when both the client and API are able to evolve over time?

Mike Amundsen offers 12 patterns and practices for building APIs that can safely evolve over time and client applications that can adapt to those changes without relying on explicit versioning systems or repeated redeployment. Whether you are responsible for building web front-ends or APIs to serve those apps, Mike helps you identify key principles to increase the adaptability and evolvability of your web implementations.

Deep Learning has led to breakthroughs in many previously unsolved problem domains, from image classification to machine translation to medical imaging analysis. Venture capital firm Andreessen Horowitz recently cooked up an AI playbook, which posits that AI will impact software as broadly as relational databases have since the late 20th century. It’s hard to think of a technological problem that AI doesn’t touch.

In this talk, we will explore the limits of today’s most popular approaches to AI. In particular, what kinds of problems can’t we solve today and how might the solutions shape the way we approach software development? Training a model for your particular domain is easier than ever, but why is it so difficult to make sense of what is going on inside the model? How can we move toward a more intuitive and accessible model for understanding what our AI has learned?

Over the course of six years, the Cochlear System 7 project went from prototypes using bleeding edge chipsets and mobile frameworks, to delivering a world first mobile and cloud connected implanted device. BlueTooth, custom hardware, regulatory concerns, clinical trials, 37 language internationalisations, accessibility, distributed teams, custom cryptographic implementations, four platforms. A zen garden of Kanban surrounded by waterfalls.

We will look at the project and team aspects as well as coding and technical approaches, that enabled us to take this project from R&D to release, maintaining course and progress on top of shifting technologies, and operating a team in an organisation with complex technical and timeline interdependencies.

There might be 25 or more Kalman filters or variants thereof in your phone and its apps. This essential class of algorithm empowers every aspect of navigation, tracking, control, and beyond to business, finance, and machine learning. Kalman filters can be tricky to test and tune, and it's essential that exactly the same code as was tested be deployed. But Kalman filters are just foldable functions! I show how to fold exactly the same code over repeatable data in a friendly testing environment and over asynchronous data in a harsh, real-world environment.

Are you using or moving to AWS? Have you considered how you organize and secure your AWS environments? The growing push to cloud providers has allowed us to move faster and tackle problems more efficiently. The same freedoms that have allowed us to move faster have also created scenarios where security issues are exposed by accident and/or without proper management and review. As companies move toward more and more cloud usage, teams are pushed harder to ensure the same compliance and security requirements that exist in slower moving private environments. This has the potential to put us right back where we came from.

Join Aaron in this in-depth workshop and work through the most critical security decisions you can make for your AWS environments. Identify issues and solutions in an automation friendly fashion that aim to fit seamlessly into the development and deployment lifecycle.

RESERVE YOUR SEAT NOW

Are you using or moving to AWS? Have you considered how you organize and secure your AWS environments? The growing push to cloud providers has allowed us to move faster and tackle problems more efficiently. The same freedoms that have allowed us to move faster have also created scenarios where security issues are exposed by accident and/or without proper management and review. As companies move toward more and more cloud usage, teams are pushed harder to ensure the same compliance and security requirements that exist in slower moving private environments. This has the potential to put us right back where we came from.

Join Aaron as he talks through the most critical security decisions you can make for you AWS environments.

The software development industry has made huge leaps in recent years; with agile, lean, software craftsmanship, evolutionary design and microservices being just a few of the buzzwords we throw around. Despite this, software development teams are often more chaotic than they are self-organising, with the resulting code being more of a mess than was perhaps anticipated. Successful software projects aren't just about good code though, and sometimes you need to step away from the IDE for a few moments to see the bigger picture. This session is about that bigger picture and is aimed at software developers who want to learn more about software architecture, technical leadership and the balance with agility.

This talk will debunk some of the common myths as we look at five things every developer should know about software architecture; a guide to software architecture on modern software projects that's pragmatic rather than academic and lightweight rather than "enterprisey".

How are microservices in 2017 different from how we used to build them at the beginning of the decade?

More traditional Service-Oriented Architectures were defined by protocols and standards published and curated by industry consortiums. Knowledge of the architectural style usually called "microservices", on the other hand, is often in the form of patterns, cautionary tales, and tools extracted from real-world reports and software made available by organisations that have adopted this style.

Almost ten years since the first wave of such reports, the landscape has changed considerably. Many hard challenges from the past have been eased or completely solved, and a lot of the custom software created by the microservices pioneers have been made off-the-shelf open source software.

In this talk, Phil Calçado will contrast what we first found in the first generation of microservices architectures against the current generation's landscape. Let's talk about which previous common knowledge and patterns are deprecated, which ones are still active, and introduce some of the ones that have been recently added to our toolbox.

While drag and drop interfaces are the rage, is there more value in teaching children real-life coding? Come to this talk to learn about designing accessible APIs in C++ in a way that inspired kids to build and invent on their own.

Event Sourcing is an approach to building software with a long track record of success. By placing business concepts at the heart of our code, we can decouple systems into small services that can be quickly built, changed, and replaced. Although Event Sourcing has been around for many years, it remains outside the mainstream paradigm of software development--much to our detriment.

With Event Sourcing, we place the highest value on the simple capture of essential business events without attempting to interpret them. We can then relegate all interpretations of those events to subsystems that are easy to build, change, and replace when necessary. The resulting systems have single responsibilities and are decoupled from each other, which makes them simple to modify. Event Sourcing can enable us to move faster by supporting rapid experimentation with new perspectives, new user interactions, and new insights into our business.

Event Sourcing is agnostic of technology stack and language style, but it goes well with another pattern called CQRS: Command Query Responsibility Segregation. In this talk, we will do a deep-dive into both of these two patterns and discuss:

• What is Event Sourcing, and how does it differ from systems designed around current state.
• Interpreting Events into denormalised projections for very fast reads (Queries).
• Receiving and validating Commands that, if successful, result in new Events.
• Single responsibility services for reacting to Events by creating other events and, if necessary, triggering external behaviour.
  

We will cover the advantages of the pattern, to give us an idea for when and why it makes sense to use it. But it isn't a silver bullet, and we will also talk about its disadvantages, including the most commonly mentioned downside: eventual consistency, and how we can deal with it.

In 2010 I came across a strange, new (to me!) architecture that the LMAX team used for their Foreign Exchange system. You might have heard about the Disruptor, it came out of this project.

The core of our system is a clustered service which uses the Raft consensus algorithm to reliably replicate state between the different nodes and hosts our application logic. We will take a quick look at Raft and then at the benefits of this design compared to more “mainstream” architectures. This architecture offers a clean separation of concerns between the infrastructure – which takes care of the concurrency, I/O and high availability aspects – and the application logic. The clean architecture is a great fit for domain-driven design.

If you fancy building fast, resilient services without a database you should come to this talk!

Continuous Delivery is a complex, holistic approach to software development and has a significant impact on the way in which organisations operate. This approach demands a broad range of skills and techniques.

This course is designed to introduce, and explore a deeper understanding of, these ideas and techniques. It is primarily aimed at “Change Agents” within organisations, Leaders, Lead Developers, Lead Architects and so on.

More specifically this course will give you the tools to help your company become a 'Learning Organisation'. Increase efficiency and quality, and reduce risk in your software development process. Our training can teach the techniques that will allow you to increase user satisfaction and make your organisation more innovative.

We do this by teaching an approach that will allow your company to become more experimental and capable of reacting quickly and efficiently to change and allowing your software development process to become a tool that enables this flexibility rather than an impediment to it.

RESERVE YOUR SEAT NOW

21st century problems cannot be solved with 20th century software architectures. So why is the starting point for so many projects built on the assumption of a simplistic monolithic, three-layer architecture sat on top of a RDBMS? Hardware has progressed. It has changed many of the assumptions that such architectures were built upon. Modern systems are distributed, deal with massive throughput of data and transactions. Users expect 24/7 service.

The Reactive Manifesto describes what it takes to build systems that meet these demands. Such systems are Responsive, Resilient, Elastic and Message Driven. What does this mean in terms of software architecture and design? This presentation will introduce these ideas and describe how systems built on these principles work.

Would you fly in a plane designed by a craftsman or would you prefer your aircraft to be designed by engineers? Engineering is the application of iterative, empirical, practical science to real-world problems. Craftsmanship is a wonderful thing, and as a reaction to the terrible abuses of the term Engineering in software development Software Craftsmanship has helped in our learning of what really works.

The term "Software Engineering" has gained a bad reputation. It implies "Big up-front design" and "Mathematically provable models" in place of working code. However, that is down to our interpretation, not a problem with "Engineering" as a discipline.

In recent years we have discovered what really works in software development. Not everyone practices approaches like Continuous Delivery, but it is widely seen as representing the current state-of-the-art in software development. This is because at its root CD is about the application of an iterative, practical, empirical, maybe even science based approach to solving problems in software development. Is this a form of software engineering?

Software isn't bridge-building, it is not car or aircraft development either, but then neither is Chemical Engineering, neither is Electrical Engineering. Engineering is different in different disciplines. Maybe it is time for us to begin thinking about retrieving the term "Software Engineering" maybe it is time to define what our "Engineering" discipline should entail.

Test-Driven Development (TDD) has been so successful that it’s now unfashionable. But many developers complain that being required to write tests just gets in the way of shipping features. That wasn’t our experience when we first stumbled onto TDD a dozen years ago, so what went wrong? Were we fooling ourselves, or did the message get confused along the way?

In this talk, I will revisit the basics, the essence of what makes TDD work. I will look at some of the common difficulties that I see with teams that are struggling. I will show how understanding the principles means that we can use tests to help us deliver more effectively.

Let’s debunk the myth that you must keep teams stable or “the same” in order to have a successful company. Changing teams can help reduce the risk of attrition, learning & career stagnation, and the development of knowledge silos. I’ll share original case studies from well known companies that enable dynamic change to their teams propelled by retrospectives and other agile, humanistic practices. In this talk, you’ll learn tips and tricks for building a sustainable company by changing teams – whether it’s by growing and splitting teams, merging teams, seeding teams, adding new people across multiple teams and more. I’ll also share reteaming antipatterns and what not to do.

Architects in the enterprise are often regarded as ivory tower residents who bestow their utopian plans upon project teams in the form of colorful diagrams that bear little to no resemblance to reality. The most suspicious in this group are often the “Enterprise Architects” who are perceived as being furthest from actual technical problems.

However, large-scale IT operation and transformation require transparency across hundreds or thousands of applications running on all sorts of middleware in data centers around the globe. The very enterprise architects are likely the only ones who stand a chance to bring transparency into such an environment and who can direct IT investments in the hundreds of millions of Euros towards modernization and run-cost reduction. This sounds a lot more exciting and valuable than drawing pictures!

This session takes a serious but light-hearted look at the role of enterprise architects in modern IT organizations.

While many Scrum teams talk proudly about progress, fewer engage is rich discuss about product. Many teams who become more confident in progress, or getting work done, often embrace the more ambiguous question of product, or “Are we meeting the needs of our customers”, with some customers buying, by paying for subscriptions, and others buying in, by showing (and glowing about) their use of the system.

In this session, I’ll share experiences helping companies adopt a customer and product / services approach. From small digital product companies to large enterprises who are IT focused, I will present an approach for moving to or augmenting an existing move towards impact driven work.

Topics that will be covered include: mapping teams to products and services, early product discovery, blending product discovery and product delivery, and if there is enough time, ideas for doing these things at scale. If we run out of time, there is always the hallways, where some of the best conversations take place. Feel free to stop me and chat me up. All I ask is that you bring your curiosity and skepticism, but leave any cynicism behind.

Does spending time in beautiful settings boost people’s happiness? The answer to this question has long remained elusive due to a paucity of large-scale data on environmental aesthetics and individual happiness. Here, we draw on two novel datasets: first, individual happiness data from the smartphone app, Mappiness, and second, crowdsourced ratings of the “scenicness” of photographs taken across England, from the online game Scenic-Or-Not. We find that individuals are happier in more scenic locations, even when controlling for a range of factors such as the activity the individual is engaged in at the time, weather conditions and the income of local inhabitants.

However, what might these beautiful places be comprised of? Is beauty in this context synonymous with nature? We extract hundreds of image features from over 200,000 Scenic-Or-Not images using the Places Convolutional Neural Network to understand the composition of beautiful places. We also find that a neural network can be trained to automatically identify scenic places, including both natural and built locations.

Much has changed since the publishing of the Agile Manifesto in 2001.

Pioneers and practitioners of lean and agile methods have examined weaknesses and friction points, experimented with simpler approaches, and produced agile processes that are safer, simpler and far more capital efficient. The result is modern agile. It’s values-driven, non-prescriptive and an easier starting point than antiquated agile processes. Modern agile amplifies the values and practices of organizations that have discovered better ways of achieving awesome outcomes. Are you still cramming low-quality work in the end of each sprint, struggling with growing technical debt, guessing about requirements, focusing on output over outcomes.

RESERVE YOUR SEAT NOW

Genuine agility is enormously effective in helping us achieve our dreams. The trouble is, Agile has grown into a complex tangle of roles and rituals, frameworks and tools, processes and certifications. We need a return to simplicity. Modern Agile is here to help.

Designed for people in many domains (not just IT), Modern Agile is defined by four guiding principles:

• Make People Awesome
• Make Safety a Prerequisite
• Experiment & Learn Rapidly
• Deliver Value Continuously

Understanding and deeply practicing these four principles will help you get better results faster.

In this talk I’ll share how these four principles power world-famous companies and how they can help you work with greater speed, simplicity, safety and success.

In this full-day workshop, you will learn applied big data solution patterns. most often, but not always using the public cloud. We’ll cover Amazon Web Services and Google Cloud Platform, and work with in small groups to design data pipeline architectures for common scenarios.

RESERVE YOUR SEAT NOW

Dr.Bauer and her team have been working to build genome-scale data pipelines that address the computational challenges and limits present in today’s cancer genomic (bioinformatics) data workflows.

Dr. Bauer and her team have built solutions which use modern architectures, such as serverless (AWS Lambda) and also customised machine learning on Apache Spark. AWS Community Hero and cloud architect Lynn Langit is also collaborating with the CSIRO team to push solutions at the cutting edge of bioinformatic research which best utilise advances in cloud technologies..

In this demo-filled session Lynn and Denis will discuss and demonstrate some of the latest cloud data pipeline work that they’ve been working together to build out for the bioinformatics community.

With functions as a service, cloud providers have signaled the smallest billable unit of computation is a single function execution. It’s a beautifully simple idea, rejecting the metaphor of a server, and freeing developers to design smaller and simpler services. We can iterate on our code with a high degree of isolation, without fear of affecting other parts of the system; deploy systems in seconds with zero downtime; and always be available regardless of load.

However, building serverless-y apps is very new and as such fought with early days complexity:

• Configuration tooling was designed for the last generation of computing metaphors (and often lags behind the releases of new functionality)
• AWS is massive and overwhelming with many similar, but not the same, products
• The web console is confusing, with divergent interfaces between interlocking services
• Deep proprietary knowledge is required to configure and maintain common infrastructure primitives

In this talk Brian will walk you through a new approach to architecting applications with plain text using arc.codes to create apps in minutes and subsequently deploy in seconds with zero downtime and unprecedented availability.

Cloud functions have been taking the industry by storm. Always available, scale transparently, only pay for the compute you use (100% utilization) and deploy instantly with zero downtime. However getting started is frought with complexity and configuration. In this workshop you will quickly learn all the angles of 'serverless' technology using Amazon Web Services:

• Lambda
• API Gateway
• Route53
• S3
• Simple Notification Service
• DynamoDB
• CloudFront
• CloudWatch Events

JSF Architect tames AWS complexity, and gets you immediately productive deploying live to isolated staging and production environments. We will setup a CRON function that runs on an interval completely in the cloud. We'll create a website on a brand new domain and be deploying to in seconds complete with user auth and state. We'll create a stateless restful JSON API. We'll close the workshop by building a completely functional bot for Slack.

RESERVE YOUR SEAT NOW

Facebook has been using GraphQL queries to build rich user experience on web and mobile. User interface updated in real time as other users interact with the system plays a key role in driving user engagement. LiveQueries is an API to allow building interactive user interface, update client caches, push updates to the client in the background and more. It allows subscribing to the query result and receive updates as the query result changes.

LiveServer is a stateful back-end for LiveQueries which interacts with query execution engine and reactive data sources. It uses dependency tracking and query re-execution to send updated query results to the client. It also allows delayed query execution and application of strategies for failed client message deliveries. Client and server is using long living connections and RSocket application protocol to deal with subscriptions, bi-directional streams, flow control and connection resumability.

We often think of performance testing as one of those things we just have to do at the end of a project, often using heavyweight tool sets in dedicated environments.
In this talk, James offers an alternative. What decisions would we make differently if we had the ability to rapidly perform experiments using lightweight performance tests? The tools and techniques we now have available makes a new type of architectural decision making possible; from Software Defined Networking, IaaS and Continuous Delivery to Real Options and Architecture Decision Records.James will cover pre-requisites that allow us to make small bets on performance and explore the strange world of evolutionary design that this technique makes possible.

Want a more productive way to build for mobile? Flutter is an SDK for building high-performance, high-fidelity, apps for iOS and Android, from a single code-base. Flutter delivers a great developer experience in part because it is based on Dart, which allows you to build your cross-platform mobile apps in an approachable and analyzable language with sub-second edit-and-continue support baked in.

Come see what makes Flutter special and learn how you can become a more productive mobile developer.

You won’t win if you keep doing the same thing over and over again. And you won’t be world-class if just you do what others have done before you. To truly make it, you need to be different and develop a world-class innovation mindset!

In the world of professional sports, innovation, persistence and rapid learning are everything! In this very personal talk I, a former Olympian, will share key learnings from my professional sports career. I will delve into topics such as choosing the team that’s right for you, rapid feedback, radical candour and high-performance teams.

I will contrast the perspectives and attitudes of professional sports with modern work life and will extract guidelines and tools that we can apply to our professional lives. From critical communication skills to collaboration and effective teams, come along and learn practical ways for how to apply ideas from Olympic sports to your professional agile career!

Using an EPOC headset from Emotiv, I have captured 14 channels of EEG (brain waves) while subjects lied and answered truthfully to a series of questions. I fed this labelled dataset into Azure Machine Learning to build a classifier which predicts whether a subject is telling the truth or lying. In this session, I will share my results on this “lie detector” experiment. I will show my machine learning model, data cleaning process, and results, along with discussing the limitations of my approach and next steps/resources. Attendees will gain exposure to the Emotiv EPOC headset and Azure Machine Learning.

In this talk, we have a look at some of the low-hanging problems in general aviation and how functional programming can be applied to provide significant improvements in efficiency and air safety. The current solutions to problems such as navigation, traffic/terrain collision avoidance and weight/balance calculations will be demonstrated to the audience, mostly for amusement. More seriously, we will have a look at the legacy that has led to the way things are, and how to improve by applying our programming skills.

We will look at:

• how aviation safety is regulated.
• how aeronautical services are provided to flight operators.
• how aeronautical navigation is conducted and regulated.
• how the weight and balance for a flight is conducted.
• the methods by which aircraft and ground coordinate between each other.

We will see:

• some real (and basic) data management problems in aviation, that very obviously threaten safety, then solve them, using programming.
• we will see a live demonstration of aeronautical navigation methods, investigate incident reports where lives were lost as a result, and consider how our programming skills can yield improvements, possibly even save lives.
• we will conduct a real weight&balance calculation for a flight, then once hilarity inevitably ensues, we will look at the problems that arise by this method, then solve them using data structures and functional programming. Some of these practical problems are obvious, even to a non-aviator, and the predictable incident reports are the end result.
• finally, we will have a look at a live demonstration of a software defined radio (SDR), receiving ADS-B transmissions from aircraft (live), an AHRS implementation and GNSS receiver using off-the-shelf, low-cost parts. We will look at why these instruments are helpful to aircraft pilots and interact with that device using the Haskell programming language.

Technical Debt has become a catch-all phrase for any code that needs to be re-worked. Much like refactoring has become a catch-all phrase for any activity that involves changing code. These fundamental misunderstandings and comfortable yet mis-applied metaphors have resulted in a plethora of poor decisions. What is technical debt? What is not technical debt? Why should we care? What is the cost of misunderstanding? What do we do about it?

Doc discusses the origins of the metaphor, what it means today, and how we properly identify and manage technical debt. In this talk I’ll share how these four principles power world-famous companies and how they can help you work with greater speed, simplicity, safety and success.

Open Source sells itself as being about technical problems—delightfully thorny technical problems, at that. However, successful projects are filled with people, which introduces a whole different set of problems that programmers often have not developed the skills to handle.

Agile development has fixed lots of problems in software development, Companies using it consistently deliver working software more predictably than ever before, But, the software they make isn’t necessarily better, or more successful in the market. Because the things we need to do to make a product successful aren’t baked into agile development,. And, in fact, strict adherence to common agile practice can result in even worse products.

This talk explains why and gives you 5 concrete changes to Agile development you can make to improve things. These aren’t things your product owner or product manager must do. They’re the things the whole team need to do. And, they’re not easy things. But, they’re necessary if you want to more consistently make products people love.

Product Ownership is hard! If you’re working as a product owner in an Agile team, you already know this is the toughest and most critical role in a successful product organization. If you’re a UX practitioner, senior engineer, or marketing professional in your organization, it may seem like adopting Scrum or Agile development has stripped away your ability to contribute as a product decision maker.

If you’re adopting an Agile approach, your organization may be struggling with bloated backlogs that aren’t well understood, stressful planning meetings that last too long and fail to get at details needed to deliver predictably, a nagging feeling that you’re building the wrong thing, a lack of time to work with customers and users, chronically late delivery, and frustrated business stakeholders...There’s hope!

The Passionate Product Ownership workshop takes on the bad assumptions and bad practices that often emerge from overly simplistic approaches to agile development and Scrum. Jeff Patton will leverage his past product leadership experience, and years of coaching product teams to teach an effective product ownership strategy.

RESERVE YOUR SEAT NOW

This talk covers the varied aspects of being a CTO in both large enterprises and small start ups. The skills you need, your technical drivers, the political landscape, technology and architecture strategy, and 101 other things you didn't know were required in the role. If you want to one day be a CTO then this is the talk you should not miss.

Functional programming has made great strides in the popular imagination, yet adoption of FP languages has often been challenging for companies, sputtering in fits and starts. Ken has been at the forefront of REA's successful adoption of FP over four years, and will share lessons learnt and traps avoided: how a human-first approach can succeed and scale.

It’s 2017 and we’re all doing microservices and continuous delivery now (yay!). Except, somehow with all of this betterness we’re not able to create more value to our customers as fast as we should.

In this talk, we’ll discuss the fallout from the post-Monolithic era, a key to understanding why we are where we are. We’ll discuss why integration testing is bad for your health, how to deal with legacy architectures and how to truly optimise delivery for the entire value chain.

Humio is a startup on a mission to democratise log analytics. With limited resources, being successful is just as much about avoiding bad decisions, as it is about doing things right. This is a talk about trade-offs, technology and culture in building a startup.

Working with log data introduces quite a different set of assumptions about how a data store should operate: you store a lot of data without known which part of it is relevant, and then after an incident, you want to be able to search it. Our biggest customers only look at 1% of the data they store. This is the opposite of how normal datastores operate: spend resources at ingest to make data easy to find. So we didn’t do it that way.

Facebook is developing a new experimental programming language called Reflex. Its main characteristic is its “spreadsheet semantics”: the runtime recomputes the state of the program incrementally when changes occur. This talk will cover the basics of the language as well as how things work under the hood.

In this talk we’ll explore the new Causal clustering architecture for Neo4j. We’ll see how Neo4j uses the Raft protocol for a robust underlay for intensive write operations, and how the asynchronous new scale-out mechanism provides enormous capacity for very demanding graph workloads.

We’ll discuss the cluster architecture’s new causal consistency model. Causal consistency is a big leap forward compared to the commonplace eventual consistency which makes it convenient to write applications that use the full capacity of the cluster. In particular we’ll show how despite the mixture of concensus protocols and asynchronous replication, that Neo4j allows users to read their own writes straightforwardly and discuss why this is such a difficult achievement in distributed systems.

For the application developer, we’ll show how Neo4j’s Causal Clustering optimised drivers makes it easy to write applications that scale smoothly from a single server to a large, distributed cluster: a practical motivation for the distributed systems enthusiast.

Wherever systems are distributed, timeouts are present. However, they don’t necessarily mean what you expect, and often come from unexpected sources. Don’t be fooled- let’s take a close look at what timeouts are made of, and learn how to use them wisely.

“The only sure thing about forecasts is that they are WRONG” – James P. Womack and Daniel T. Jones. Estimates have been the bane of software development projects for decision makers, managers, and programmers alike for decades. Managers/Customers want to know: When will it be done? How much will it cost? Which project should we do? Programmers are told: “A professional can do meaningful estimates”, and “We won’t hold you to the estimate”, and yet they often are.

It’s my contention that estimates are often not useful for this purpose, and even worse they can misinform the decisions they are meant to support. Do we really need estimates? Is simply “getting better” at estimates worthwhile? Can we live without them? Will things be better without them? I don’t have answers for you, but I’ve worked with “no estimates” for over 8 years and I’m still alive and doing well. We’ll explore the idea of estimates, what they are, why they are pervasive in the programming world, how they might be harmful, and see if we can start a dialog about finding a better way.