Speaking and Writing

I try to stay fairly active in the professional development community and try to write a paper or speak at a conference at least once a year.  This is a running list of all the papers, workshops, and presentations. I created it as a sort of CV but also because I thought it would be cool to see written down in one place all the various events and publications I've done.

In many cases I've posted slides or written about the paper, presentation, or workshop on this website. If there isn't a link or you just want more information, drop me a line and let's talk.

Book Cover for Design It! by Michael Keeling

Books







Presentations


Panels


Publications


Interviews


Conference Committees

  • Agile 2013 - 2018, 2020 Experience Reports, reviewer and shepherd
  • Pattern Languages of Programs - PLoP2020 Program Committee, shepherd
  • SATURN 2013, 2016, 2017 2018, 2019 Program Committee
  • European Conference on Software Architecture (ECSA) 2018, 2019 Program Committee
  • International Conference on Software Architecture (ICSA) 2019, 2021 Program Committee
  • SATURN 2014,  Technical Program Chair
  • SATURN 2015, Technical Program Co-Chair with George Fairbanks
  • ICSME Annual Workshop on Technical Debt 2014, 2015, 2016, Program Committee

Comments

Post a Comment

Popular posts from this blog

Architectural Drivers: Building Blocks for Decision Making

Architectural drivers are formally defined as the set of requirements that have significant influence over your architecture.  In other words, there are some requirements that will help you decide which structures to pick for your system design and others that are less consequential in the context of software architecture.  This implies that it is extremely important to get the architectural drivers right early in a project, as architecture structures will become more difficult to change as the developed software becomes more realized. Thinking about early requirements as "drivers" can also help you to create traceability from stakeholder concerns to specific architectural decisions made.  Having this traceability is great because it helps to promote important qualities in your team, such as agility.  With traceability you can make changes on purpose and with confidence as you understand the genesis for structural decisions. What are Architectural Drivers? Architectural
Read more

Dealing with Constraints in Software Architecture Design

Image
Definition  of  constraint  (n) Bing Dictionary con·straint     [ kən stráynt ]     limiting factor: something that limits freedom of action state of restriction: a state in which freedom of action is severely restricted lack of spontaneity: a lack of warmth and spontaneity in somebody's manner or in the atmosphere on a particular occasion In software architecture design, constraints come in two basic flavors - technical and business.  On most projects there are only a handful of constraints, but these constraints are a highly influential architectural driver .  Constraints, as the dictionary definition above indicates, are a limiting factor and severely restrict options for making design decisions.  They are also fixed design decisions that cannot be changed and must be satisfied.  You could think of constraints as the ultimate non-negotiable, "must have" requirement.  It is for this reason that architecture design constraints must be created and acc
Read more

Choosing a Software Design Strategy

Image
I was reading an article from the Joel on Software archives and was struck by this quote from The Project Aardvark Spec : I can't tell you how strongly I believe in Big Design Up Front, which the proponents of Extreme Programming consider anathema. I have consistently saved time and made better products by using BDUF and I'm proud to use it, no matter what the XP fanatics claim. They're just wrong on this point and I can't be any clearer than that. When thinking about design there are two extremes pivoting around how much up front design work needs to be done before you start writing code. Proponents of up front design point out, as Joel has in the quote above, that making changes in the design is a lot cheaper in a 20 page design document than a partially or fully implemented system. With a solid plan you stand a better chance of not painting yourself into a corner and avoid having to make expensive design changes in the code later. Opponents of BDUF worry greatl
Read more