For four years, I wrote the bi-monthly IEEE Software Design column. I vowed to write on a new design topic every other month! I started writing about object design concepts and design practices, and then went on to write about design simplicity, giving and receiving constructive design advice, designing for testability, designing long-lived systems, revisiting and refreshing design patterns, and more.
Looking for Powerful Abstractions
IEEE Software January/February 2006 issue. Vol. 23, No.1.
This column explains why identifying reasonable classes isn't as simple as underlining nouns or modeling "real world" concepts.
PDF
IEEE DOI
Abstract
Some claim that only innately talented designers can form good abstractions, develop a well-factored object design, or construct a domain model. The implication seems to be that design talent is rare and that only gifted designers are up to the more challenging task of creating good abstractions. Balderdash! Although design is a highly creative activity, we can still learn fundamental design skills--and accomplish a lot with them. In this column, Rebecca Wirfs-Brock explores ways of seeing that have helped her become a better designer. She starts by discussing the fundamental design skill of finding objects.Characterizing Classes
IEEE Software March/April 2006 issue. Vol. 23, No. 2.
The column introduces several key properties of classes.
Keywords: Class, Aptronym, Role Stereotype
PDF IEEE DOI
Abstract
The author introduces several characteristics she ascribes to classes when trying to understand their nature and purpose. Class characterization is a key step of object design. It clarifies at a glance some important aspects of a class’s expected behavior and communicates its design intent to others.Refreshing Patterns
IEEE Software May/June 2006 issue. Vol. 23, No. 3.
This column explores how a preferred form of a pattern can change with use and experience.
Keywords: Design Patterns
PDF IEEE DOI
Abstract
When the published form of a pattern seems dated due to new language features or new experiences, it needs refreshing. Unfortunately, just like in spoken languages, once standard definitions are widely circulated in print, it becomes much harder to update them. And instead of updating a single source, pattern authors have expanded and grown the literature. Furthermore, if you're looking for new patterns, want to explore patterns in the making, or want to discuss pattern nuances, print publications aren't your best source. You need to look online. So although some prefer sources of tried and true patterns, ready for immediate consumption, if you only look in published pattern books, you miss out on a lot of design ideas and good discussions.Designing For Recovery
IEEE Software July/August 2006 issue. Vol. 23, No. 4.
This column explores the design of software recovery actions when failing fast isn't an option.
Keywords: Object Oriented Methods, Program Testing, Exception Handling, Software Fault Tolerance, Software Design, Patch Up Proceed Strategy, Code Checking, Program Testing, Exception Handling, Software Design, Plugs, Null Value, Programming Profession, Logic, Redundancy, Safety, Design Engineering, Humans, Costs, Software Recovery, Failing Fast
PDF IEEE DOI
Abstract
How should you design your software to detect, react, and recover from exceptional conditions? If you follow Jim Shore's advice and design with a fail fast attitude, you won't expend any effort recovering from failures. Shore argues that a "patch up and proceed" strategy often obfuscates problems. Shore's simple design solution is to write code that checks for expected values upon entry and returns failure notifications when it can't fulfil its responsibilities. He argues that careful use of assertions allows for early and visible failure, so you can quickly identify and correct problems.Toward Exception Handling Best Practices and Patterns
IEEE Software September/October 2006 issue. Vol. 23, No. 5.
This column presents guidelines and explores the state of exception handling patterns.
Keywords: Exception Handling
PDF IEEE DOI
Abstract
Agreeing on a reasonable exception-handling style for your application and following a consistent set of exception-handling practices is crucial to implementing software that's easy to work with, comprehend, evolve, and refactor. Demystifying exception-handling design requires writing about proven techniques, guidelines, and patterns.Explaining Your Design
IEEE Software November/December 2006 issue. Vol. 23, No. 6.
Keywords: Design, Design Fundamentals, Presentation
PDF IEEE DOI
Abstract
Have you ever tried to explain some aspect of your design and not known where to start? If people can't understand the fundamentals influencing your design, they can get lost in detailed explanations. But always starting from first principles can make for a dull presentation. The art of telling a compelling design story is understanding what your audience knows and what they need to know about your design, and then plotting your storyline accordingly.Driven to...Discovering Your Design Values
IEEE Software January/February 2007 issue. Vol. 24, No. 1.
Keywords: Responsibility Driven Design, Test Driven Design, Behavior Driven Design, Domain Driven Design, Model Driven Design, Design By Contract, Software Development
PDF IEEE DOI
Abstract
Software development approaches all emphasize a core set of values and principles around which practices, techniques, and tools have emerged. A thoughtful designer should be able to pick and choose among practices without losing their essence. But not all practices are congruent.Toward Design Simplicity
IEEE Software March/April 2007 issue. Vol. 24, No. 2.
Although the perfectly beautiful design is impossible to achieve, a disciplined approach to removing clutter can lead to simplifications.
Keywords: Accidental Complexity, Simplification, Inheritance, Composition, Design Rework And Repair
PDF IEEE DOI
Abstract
Designing incrementally, keeping it clean as you go, can help you avoid accidental complexity. But doing this takes discipline and design familiarity.Handling Design Criticism
IEEE Software May/June 2007 issue. Vol. 24, No. 3.
Effectively giving and receiving criticism are skills every designer needs to master.
Keywords: Design Criticism, Illogical Arguments, Judgments, Aesthetics, Design Complexity
PDF IEEE DOI
Abstract
Knowing what tactic to take when someone criticizes your design is important. Designers need to recognize, accept, and seek out valid criticism, while deflecting false criticisms and defusing aesthetic arguments.Giving Design Advice
IEEE Software July/August 2007 issue. Vol. 24, No. 4.
Keywords: Cognitive Biases
PDF IEEE DOI
Abstract
Cognitive biases exist, and designers are remiss if we ignore them. By becoming aware of some common cognitive biases in design discussions, you can learn when it's worthwhile to tweak your message to increase the likelihood of it being accepted.Designing Extensible Classes
IEEE Software September/October 2007 issue. Vol. 24, No. 5.
A responsible class designer must strike a balance between openness, clarity, safety and ease of extension.
Keywords: Class, Subclass, Abstractions
PDF IEEE DOI
Abstract
Building clean abstractions with clearly defined extension points is satisfying, but the best design choice isn't always obvious. How much access should you give a subclass to a class's inner workings? How much freedom should you give a subclass designer to "bend" inherited behaviors to make a new abstraction fit in or to extend an existing one? These decisions involve nuanced reasoning. The contract between a class and its subclasses requires thoughtful design, experimentation, and careful specification.Does Beautiful Code Imply Beautiful Design?
IEEE Software November/December 2007 issue. Vol. 24, No. 6.
Instead of arguing for truth or beauty, we should think more about making our software more habitable.
Keywords: Code, Design, Habitable Code
PDF IEEE DOI
Abstract
Yukijiro Matsumoto, chief designer of the Ruby programming language, claims brevity is one of the most important contributors to beautiful code. Although brevity can contribute to code beauty—clarity of purpose, expressive use of the programming language, and design elegance also play a part. But is there more to good design than beautiful code?Valuing Design Repair
IEEE Software January/February 2008 issue. Vol. 25, No. 1.
Designing fixes to working software can be much harder than designing new stuff.
Keywords: Antipattern
PDF IEEE DOI
Abstract
While a style guide typically covers good practices—what to do and what to avoid —an antipattern is somewhat more ambitious. It seeks to explain how good intentions can go awry and suggest meaningful ways to repair broken systems. The point isn't so much to say "do this" or "avoid doing that" as to suggest ways to prevent a problem or to skillfully apply a set of corrective actions.Connecting Design with Code
IEEE Software March/April 2008 issue. Vol. 25, No. 2.
The best commentary shares what the designer was thinking.
Keywords: Design Intent, Code
PDF IEEE DOI
Abstract
Code clutter and unnecessary complexity can obscure design. How can designers better present their design decisions in their code?Design Strategy
IEEE Software May/June 2008 issue. Vol. 25, No. 3.
Design matters, but not every design task deserves the same attention.
Keywords: Strategic Design, Design Stories, Core Problems, Domain Modeling
PDF IEEE DOI
Abstract
Designers need to sharpen their focus and apply design energy where it will have the most impact. So, identifying what's core to our system's success is one of the most critical things we must do.Up-front Design
IEEE Software July/August 2008 issue. Vol. 25, No. 4.
When preparation matters upfront design can payoff. Upfront doesn't have to be a four letter word.
Keywords: Smalltalk, Software Prototyping, Software Prototype, Smalltalk, Software Design, Prototypes, Color, Rhythm, Hardware, Software, Technological Innovation, Writing, Up Front Design, Software Development
PDF IEEE DOI
Abstract
There can be significant benefits in thinking through a design until you get it "right enough" before launching into a major development effort. One of those times when careful thinking and preparation pay off is when you're designing software that breaks new ground. No one had done color BitBlt graphics before, no one knew what it would take to enhance the existing Smalltalk system to support color, and no one had developed classes that modeled different color representation schemes. We also wanted the existing Smalltalk applications to run on the new platform without change.Enabling Change
IEEE Software September/October 2008 issue. Vol. 25, No. 5.
Keywords: Software Design, Refactoring
PDF IEEE DOI
Abstract
Enabling continued, steady change requires that we integrate design corrections and adjustments into the natural course of development.Designing Then And Now
IEEE Software November/December 2008 issue. Vol. 25, No. 6.
Keywords: Software Design, Software Engineering, Smalltalk, Assembly Language, Test Driven Development
PDF IEEE DOI
Abstract
Over the past 25 years, we've made great advances in tooling, technologies, and techniques that make software design more concrete. But design still requires careful thought.Designing in the Future
IEEE Software January/February 2009 2008 issue. Vol. 26, No. 1.
Keywords: Software Design, Up Front Design, Design As You Go, Design Rhythms
PDF IEEE DOI
Abstract
Becoming a better designer means getting better at what we do now while not getting lulled into accepting the status quo. To stay effective as designers, we need to continue to learn, adapt, keep an open mind, and work to perfect our craft.Designing with an Agile Attitude
IEEE Software March/April 2009 issue. Vol. 26, No. 2.
This article looks at the attitudes and practices of successful agile software designers.
Keywords: Agile Software Design, Pair Programming, Reflection Meetings
PDF IEEE DOI
Creating Sustainable Designs
IEEE Software May/June 2009 issue. Vol. 26, No. 3.
Keywords: Christopher Alexander, Centers, Properties Of Living Structures, Sustainable Software, Software Development Processes
PDF IEEE DOI
Abstract
Christopher Alexander's concept of centers and properties of living structures can help developers create pleasing, sustainable software designs.Design for Test
IEEE Software July/August 2009 issue. Vol. 26, No. 4.
Software design principles can be extremely helpful but shouldn't be followed slavishly.
Keywords: Software, Software Design, Design Principles, Robert Martin
PDF IEEE DOI
Principles in Practice
IEEE Software September/October 2009 issue. Vol. 26, No. 5.
The design of tests and of the code that satisfies them should be complementary parts of software development.
Keywords: Software Engineering, Software Design, Unit Tests, Debugging, Test Driven Design
PDF IEEE DOI
The Responsible Designer
IEEE Software November/December 2009 issue. Vol. 26, No. 6.
Keywords: Responsible Design, Agile Development, Flexibility, Commonality Variability Analysis
PDF IEEE DOI