Links to OOPSLA / SPLASH workshops
I have been involved in a number of workshops since 2002, mostly related to current
topics in software engineering.
These workshops were all "free-form discussions" that were focused on specific software
engineering topics -- an opportunity to ask questions and explore new areas for research.
- XP2019
workshop on "Architecture in an Agile World"
- final report
- Results:
- There is a lot to learn when you become an architect: technical knowledge and domain knowledge
- Architects need to learn about the existing product architecture (structure and interfaces) and the organization's development process (how does the design/build/test process work)
- Elements of good "agile architecture" include:
- addressing principal risks
- keeping the cost of change low
- flexibility (don't handcuff the developers)
- keeping the approval process simple and streamlined
- SPLASH
'17 workshop on "Escaped from the Lab"
- final report
- Results:
- Innovation is hard. Today's innovations come from a wider range of sources than the back in the golden age of industrial research labs. And it is more likely today that innovations fit into some kind of "ecosystem" -- something that provides more overall value to users.
- Creating successful innovations and sustaining them requires attention to getting funding, finding the key influencers, and using feedback from customers.
- SPLASH
'15 workshop on "Smart Software Strategies"
- final report
- Results:
- The next wave of "smart" applications and devices will require some new approaches to product quality, safety, reliability, security, and privacy. We need to start working today on the soft skills that will be critical to mitigating widespread system problems.
- One good idea is to have an independent and public reporting system for software failures that is similar to the Aviation Safety Reporting System (ASRS) for aviation safety incidents.
-
SPLASH '14 workshop on "Technical Debt"
- final report
- Results:
- Technical debt can't be avoided, but we should work to mitigate it, manage it, and make it visible. The top techniques are: avoid duplication, keep a technical debt backlog, engage testers to test scenarios early, and use design reviews and code reviews to detect technical debt.
-
SPLASH '13 workshop on "Technical Debt"
- final report
- Results:
- What is the "currency" of technical debt? Time - not quality or dollars. You take design and development decisions that "save time today", but you must pay more time later to keep the product coding.
- Executives, middle managers, and technical staff have very different views of technical debt - relating to financials, risk, and technical skills.
- We are still in the early days of defining technical debt metrics.
-
SPLASH '12 workshop on "What Drives Design?"
- final report
- Results:
- Don't limit yourself to just one xDD process (TDD, BDD, DDD, and others), blend some ideas from several methods depending on the circumstances -- this was the advice from Rebecca Wirfs-Brock in her SPLASH 2011 invited talk. It is good to focus on xDD practices that increase collaboration, especially RDD, DDD, and ATDD.
-
SPLASH '11 workshop on "Beyond Green Field Software"
- final report
- Results:
- Focus on "understanding" in any code modernization project -- invest time in collecting tests, requirements, use cases. Make sure to have discussions with customers and the original system designers (if they are available). Don't reuse code you don't understand -- it will be a disaster.
-
SPLASH '10 workshop on "Architecture in an Agile World"
- final report
- Results:
- Use "timeboxing" and "pageboxing" to keep the architecture from being a "big design up front". Everyone, not just architects, should be on the lookout for "bad architecture smells" -- such as tangled code, missing -ility requirements, unbalanced test suites, and duplication.
-
OOPSLA '09 workshop on "Architecture in an Agile World"
- final report
- Results:
- A mixed model of agile and architecture-driven development is a good way to make software product development effective.
A very important part of "being agile" is having respect for other people, even if they aren't part of the inner team of agile developers. An very important part of "being a good architect" is advocating for the architecture -- working hand-in-hand with the developers to maintain a strong software structure.
-
OOPSLA '08 workshop on "Escaped from the Lab"
- final report
- Results:
- Technology transfer is a collaborative effort. There must be a give and take between technology users and researchers. It is also useful to try to measure the impact of innovation, in terms of individual productivity, organizational improvement, increasing mindshare, and potentially triggering the creation of new industries.
-
OOPSLA '07 workshop on "No Silver Bullet"
- final report
- Results:
- The software development "werewolf" is a combination of complexity, people, and communication -- our problems and systems are becoming more complex, we often make bad choices as developers (that get us into trouble later), and our field (computer technology) selects for people with weaker communications skills.
- The most promising technologies to help with complexity have been objects, frameworks, patterns, and agile development -- but each of these is somewhat limited in how much it can help.
-
OOPSLA '06 workshop on "Escaped from the Lab"
- final report
- Results:
- The transition from research to development is not easy.
- There is always a "design evolution" process involved in the process of transforming a research prototype into something that people will pay for. In addition, there are extra costs relating to quality, system security, and product documentation.
- The biggest "people cost" of the transition is the essential collaboration between people from two different cultures.
-
OOPSLA '05 workshop on Reliability
- final report
- Results:
- Reliability of software and systems is about more than technical design and programming. There are fundamental economic issues that must be addressed to determine the appropriate amount of investment of technical effort in the requirements, architecture, and design of reliabile systems.
- In addition, there must be good communication about the required reliability -- don't just assume that everyone knows the reliability targets and strategy.
-
OOPSLA '04 workshop on Outsourcing
- final report
- Results:
- Outsourcing is a strategic decision that changes everyone's jobs -- executives, project managers, operations managers, business analysts, architects, developers, and testers. Many of those changes create hidden costs, and these must be considered in any outsourcing strategy decision.
-
OOPSLA '03 workshop on "Beyond Green Field Development"
- final report
- Results:
- Legacy code reuse is easier if you have an experienced team (knowledgeable about the code and the problem domain, good code structure, and good tools). But even then, you need to know when to "give up" -- to avoid a purely emotional decision about software reuse.
-
OOPSLA '02 workshop on Discovery Costs
- final report
- Results:
- Discovery -- the process of learning what you need to learn to do the job you have to do -- is mostly an organizational/cultural problem, but tools and technologies can have an impact. There are important organizational practices and tools for both software developers and managers.