Describe What You Want Not How to Get It
So much of good software design comes down to separating the WHAT from the HOW. WHAT we want should be expressed in the interfaces of the services that we create. It should clearly state WHAT the service provides, the parameters that it needs to take in, and the value that it returns. Our services should …
Continue reading “Describe What You Want Not How to Get It”
Read MoreHelp Developers Understand Why and for Whom
The traditional ways that we describe how to build something, whether it’s a blueprint for an office building or the specification for a computer program, it always involves a document that describes WHAT to build and often includes information on HOW to build it. However, these documents are often missing critical information on WHY these …
Continue reading “Help Developers Understand Why and for Whom”
Read MoreUse Development for Discovery
Before you begin to build a house and break ground on the foundation you better have a blueprint and know exactly what you’re going to build. In physical construction, we really need to plan things out ahead of time to ensure that we have the right materials at hand and that things come together as …
Continue reading “Use Development for Discovery”
Read MoreBe the SME
I’m kicking off a new series of blog posts based on the Seven Strategies sections in my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software. The next seven blog posts will each be based on a different strategy from the section in my book called on Seven Strategies for …
Read MoreWhy Practice 1: Say What, Why, and for Whom Before How
In honor of the 10th anniversary of this blog, which I first started under the name Techniques of Design and then became To Be Agile, I’m starting a new blog series. Actually, I’m starting nine new blog series, a series on each of the nine practices from my book, Beyond Legacy Code: Nine Practices to …
Continue reading “Why Practice 1: Say What, Why, and for Whom Before How”
Read More