Tag Archives: IEEE design column

Design For Test

Posted on by
2

It sounds straightforward. Write your test code first, then write code to pass that test. Don’t write an inch of code without writing a test first. That is what test-driven development (TDD) is about: Use tests to drive out the design and implementation. Rinse and repeat. Repeat many times a day.

I know a number of top notch developers who are masters at their craft. Yet they don’t daily program in a pedal-to-the-metal test-first-only write-the-barest-amount-of-code-to pass the test style. Yet they value testing. Testing, to them, is integral to programming. I asked a few of my programmer buddies who value testing what does it mean to design for test (I have my ideas, but I don’t make my daily living writing production code)…even if they aren’t TDD followers.

And the bottom line is this: code that is designed for test must continually be tested (not necessarily at the speed of a TDDer). If you want to make testing feasible, you often need to make code-under-test easy to isolate from its production environment, tunable, and measurable. Not easy stuff. Just like design flexibility, testing doesn’t come for free. It’s part of a disciplined development process.

Read more about Design For Test in my latest IEEE Design Column.

I’d like to hear your reactions…

Sustainable Design

Posted on by
4

In my most recent IEEE Column, Creating Sustainable Designs, I explore what it means to create software that can be maintained without too many growing pains. I have been intrigued by Christopher Alexander’s writings, particularly the first two volumes of the Nature of Order where he explains the properties of designed (or architected) things which have life and processes for creating life.

It is just as important to look at process of creating good software as it is to consider what properties make software habitable for those who have to maintain it and keep it alive. While I appreciate process (and I think the agile community has given us a lot to consider) I am more keenly interested in exploring what makes complex software “living”.

Alexander identifies these properties (or qualities) of living things: levels of scale, strong centers, boundaries, alternating repetition, positive space, good shape, local symmetries, deep interlock and ambiguity, contrast, gradients, roughness, echoes, the void, simplicity and inner calm, and non separateness.

It can be easy picking to draw certain connections between certain “good” software design properties and Alexander’s list. For example, good shape, as others have pointed out can be a matter even as simple as properly indented a method. Or it can be more profound than that–leading you to break up a method into substeps and invoke helper methods, just to keep every step at a similar level of abstraction. I’m only giving you a taste to see whether you are interested in exploring these ideas further.

If you are, read my column, and also take a look at the C++ Report article by Jim Coplien on Space: The Final Frontier, which introduces Alexander’s notion of centers and how they relate to software structure, and peruse several very good blog entries by Regis Medina.

And if you are interested in exploring these ideas further, perhaps by taking a deep look into working code or frameworks or software that you consider to be particularly alive (or not)… let me know. I am considering finding a venue where software developers and designers and philosophers could concretely explore Alexander’s properties more thoroughly. I am not just satisfied to make those simple, easy connections and call it good. I want to challenge our best designs and see whether Alexander’s properties really do apply (or if we have some other properties that are more relevant).

Design Hygiene

Posted on by
2

Without ongoing attention to design hygiene, design integrity is bound to deteriorate over time. My latest IEEE design column, Enabling Change, briefly examines what it takes to keep a code base ready to absorb new design changes.

At the very least you should leave code as clean as it was before you made a change (if not better). One credo that Scott Bain extols in his new book, Emergent Design, is whenever you touch the code “do no harm”. Do what you know to be best at the time (given the constraints you are under). Scott is a realist, but I like his stance on when to fight for one particular design approach over another, too. When you think it will be really difficult to refactor/cleanup the design later due to a poor design decision that is on the verge of being made now, argue for what you think now is a better solution.

But even with good intentions and experience, we need to refactor and rework our code as we refine our design ideas–and learn from the code. Yep, we should refactor. Continually. But we don’t always do so. Emerson Murphy-Hill, a Ph.D. student at Portland State and Andrew Black, a professor at Portland State wrote an intriguing paper, Refactoring Tools: Fitness for Purpose, that also appears in the upcoming issue of IEEE Software. They explain why in practice refactoring tools aren’t used as much as they should be and propose some principles that characterize successful regularly used refactoring tools. They also distinguish between “floss refactorings”–those which should be done a regular ongoing basis during programming in order to avoid more pain later on– from “root canal” refactorings. They found that refactoring tools could be better designed and point out some that are better designed for daily use than others.

Giving Design Advice

Posted on by
4

In an ideal work environment software designers freely ask for and offer constructive criticism and openly discuss issues. They don’t take criticism as personal affronts, and they and their managers make intelligent, informed decisions.

OK, so how do design discussions play out where you work? In my latest IEEE Software design column I discuss some effective ways to give advice as well as hurdles you may have to overcome before your advice is heeded. Being an effective critic, advisor, and design colleague isn’t purely a matter of being on top of your technical game. Cognitive biases affect how people naturally (and often illogically) receive and process information. They can have a big impact on how you your advice is received and interpreted. If you want to get better at communicating suggestions to others, you should become more aware of these biases and look for ways to mitigate or avoid them. Wikipedia has a good overview of cognitive biases in how people assess risk, make decisions, and rationalize them after the fact.

To whet your appetite for this topic I’ll mention one bias that has probably bitten every programmer at least once. A confirmation bias is when a person looks for what confirms a strongly held belief while ignoring or undervaluing contradictory evidence. Have you ever found yourself unable to isolate a software bug because you insisted that your software just couldn’t work that way? Your confirmation bias might have prevented you from noticing facts that would lead you more swiftly to identifying the bug’s root cause. I like the idea presented in Debugging by Thinking by Robert Charles Metzger that taking on the different mindset of a detective, mathematician, safety expert, psychologist (one of my personal favorites), computer scientist or engineer you can get a better slant on tracking down a bug. According to the author, “Each way has an analogy, a set of assumptions that forms a worldview, and a set of techniques associated with it.” In designing as well as debugging, having a variety of worldviews for tackling a problem helps you avoid getting stuck in a rutand pick the right strategy based on the context. One way to get around a confirmation bias is to shake yourself out of the normal way of doing business.

Cognitive biases aren’t good or bad. They just are. And if you work with others it helps if you can identify biases that lead you (or others) to jump to conclusions, hold onto an idea when it should probably be discarded, or ignore risks. That knowledge can help you tune your message and become aware of and avoid bias traps.

Martin Fowler is no Kent Beck

Posted on by
Reply

I know the difference between those two….When authors make mistakes, readers notice. In my latest IEEE Software Design Column, Driven…to Discovering Your Design Values, I quoted Martin Fowler as claiming that test-driven development,

“gives you this sense of keeping just one ball in the air at once, so you can concentrate on that ball properly and do a really good job with it.”

Kent quoted Martin in his book Test Driven Development by Example.
It gets a little tricky when you cite someone quoting someone else. Originally, I had the reference to the book in line with the quote attributed to Martin (but my citation only listed the book title, not the author). My editor moved that citation to the back of my article and undstandably filled in Martin as the author. Easy mistake to make and I didn’t double check the references when it was refactored. I assumed my editor would fill in the author appropriately and double check citation.

My fault. You heard it from me first. When anything is refactored, whether it is code or citations or comments, you need to check twice. Since I don’t have an xUnit tool to write tests for citations and quotations, this has to be by visual inspection. I’ll know better next time. Thanks Mirko and Shinobu for caring enough to email me about this mistake.

Start Me Up…

Posted on by
Reply

…it’s a new year and time to exercise my blogging muscles. I’ve been hunkered away writing design columns for IEEE Software (as well as enjoying a holiday break). Now that two columns are in the bag, I am turning some attention here. In addition to appearing in print, I will also post my columns on my website’s resource page. Looking for Powerful Abstractions appears in the Jan/Feb 2006 issue. If you have any design ideas you’d like to kick around or think are worthy of a 1500 word column, please drop me a line.