Peter Muldoon
We can't test this is the path to failure
Actions
Pete Muldoon has been using C++ since 1991. Pete has worked in Ireland, England and the USA and is currently employed by Bloomberg. A consultant for over 20 years prior to joining Bloomberg, Peter has worked on a broad range of projects and code bases in a large number of companies both tech and finance. Such broad exposure has, over time, shown what works and what doesn't for large scale engineering projects. He's a proponent of applied engineering principles, elegant solutions and expressive code.
Software Engineering Completeness : Knowing When you are Done and Why it Matters ?
Whether creating new features or fixing bugs in software applications or libraries, the question that inevitability gets asked is "Are we done implementing a change ?". But what does that mean in Software Engineering terms and what is its effect on delivering change in the real world ?
Being "Done" can mean just checking code into a repository but what about the merging of changes for a release, the updating of feature flags and the phased deployment of these changes into Production. Primitive approaches to delivering change and defining it as complete can lead to unwieldy code bases that are difficult to manage and foment technical debt.
However implementing change should go further than that and ask questions on the completeness of the changes. Has code quality/technical debt been addressed ? How does tactical fixes versus strategic direction achieve different versions of being finished. what about the vital task of decommissioning of old code as new code is added to replace it ?
This better line of thinking of "Being Done" will bring about a more maintainable and extensible codebase. But stopping there falls short of proper engineering goals. What about the Monitoring of system health, Holistic testing and strategic goals of the business ?
In this presentation, we will explore these topics and build up a Software Engineering Completeness pyramid for change delivery - analogous to the survival needs pyramid - and illustrate differing levels of being change complete.
The revelation that "doneness" - properly defined - and executed is a force that drives superior software engineering and strikes to the heart of achieving improved outcomes. This clarity of thinking on the real cost of software ownership promotes flexible software, happy consumers and allows for clean communication to others of when you are actually and finally DONE.
Exceptionally Bad : The Story on the Misuse of Exceptions and How to Do Better
Exceptions were originally heralded as a new modern way to handle errors. However the C++ community is split as to whether exceptions are useful or should be banned outright. It has not helped the pro-exception lobby that in their enthusiasm to embrace exceptions, a lot of code has been written that puts exceptions in a bad light.
In this talk, We will present the original intent/history of exceptions and a brief overview of how exception mechanics work and how they circumvent the usual stack return mechanism to set the stage. we will then examine the philosophy of using exceptions and then the many cases of exception misuse including resource management, retries, hierarchies, data passing and control flow to name but a few.
For each case, we will then suggest better ways to handle each specific situation. In many cases, exceptions are often dropped in favor of some other more appropriate paradigm.
Finally, we will introduce situations that can truly benefit from exceptions and what a model exception class might look like.
Dependency Injection in C++ : A Practical Guide
A key principle for testing code is the concept of dependency injection aka the ability to swap out functionality of key components. This feature allows not only for easier code testability but also promotes well structured code that is more extensible and flexible beyond its original use cases.
In this talk we will explore the basic building blocks that can be used for Dependency injection like link-time substitution, dummies, Interfaces via Inheritance, templates, smart-pointers and polymorphic function wrappers. what are their strengths and weaknesses and the problem space they best serve.
But what exactly is good dependency injection and what are good/bad strategies for employing these building blocks ?
How do you inject multiple dependencies into classes/functions without going down the road to singletons and global state ? We will also show how to introduce dependency injection into older codebases that were never designed for the concept. Doing this without having to make major changes throughout a legacy codebase ?
After exploring this and other use cases, we suggest better ways to handle these specific situations. Finally a coherent strategy for adding DI to your applications should emerge and be added to your toolbox.
Peter Muldoon
We can't test this is the path to failure
Actions
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top