login      my ps      about      contact  



home instructor-led training online training blogs


Don Box's Spoutlet » The Sellsian Approach

The Sellsian Approach

Don Box's Spoutlet

Pluralsight Blogs

Syndication

Recent Posts

Tags

View more

WinFXies

Z through A

VSers

WinFXers

Archives

Around 1994, Chris Sells explained to me how he designs software for use by other programmers:

“First I write the code I would want to write if I were the other programmer. Then I do whatever it takes to make that code the real implementation.”

I know the TDD folks have a similar approach, but the focus there is more on iterative development and implementation as well as making sure that tests get written as an integral part of the process (all good things btw).

Sells took it further, in that the code you would want to write as “the other programmer“ is what drives the design of the API/object model and in fact is where you start the overall design process.

Not principled architecture.

Not UML.

Not Patterns.

Not even by defining the interfaces themselves.

One or more of these things obviously have a role to play (especially the last one :-)), but none of them are as useful a starting point as the simple “what would my customer want to write“ exercise that Chris turned me on to.

I look at a lot of programming APIs and OMs (not just .NET ones) and I think there's no way they'd be as complex if only the original developers had applied the Sellsian approach.

Posted Jan 24 2007, 09:21 PM by don-box

Comments

Bill wrote re: The Sellsian Approach
on 01-25-2007 2:44 AM
Don,

I totally agree! I am squarely in Sells camp on this one, having had the opportunity to write library code for many years now. When TDD became popular, I noticed the similarity - the only difference being that I was starting not with test code, but with the intended "user" code. This approach greatly improves the API. (It also results in some nice sample code to hand over with the library).

There are also other things that I do during requirements development, design, implementation, and testing that are different when the audience is "another program" (or programmer) rather than an end user.

Maybe the topic of developing library/API software is under-covered in our industry?
Jonathan Perret wrote re: The Sellsian Approach
on 01-25-2007 2:57 AM
Don,

You write about TDD:
"I know the TDD folks have a similar approach, but the focus there is more on iterative development and implementation as well as making sure that tests get written as an integral part of the process (all good things btw)."

It is a common misconception that TDD is only about testing or even implementation. The "TDD epiphany" comes when you realize that it is actually a software design method. The catch phrase commonly heard is "Test-driven development is not about testing".

When properly practicing TDD, you don't start by defining the interfaces, you just write a test that does not even compile and make it compile. Then you make it pass. Then you refactor...

In other words, the "Sellsian approach" you just described is TDD, no more no less. Now, the fact that he already did it that way in 1994 does show amazing foresight...

Cheers,
--Jonathan

PS: please blog more ! :)
Dilip wrote re: The Sellsian Approach
on 01-25-2007 4:13 AM

Scott Meyers in his MEC++ calls this the "outside in" approach. I can't remember which Item # it is but your post bears a striking resemblance to what Meyers wrote years ago.
BM wrote re: The Sellsian Approach
on 01-25-2007 8:52 AM
Our CTO calls this "reusability". If you create your components with reusability as your priority, usually architectural elegance takes a back seat to simplicity and cleanliness. Essentially the same things.
Brad wrote re: The Sellsian Approach
on 01-25-2007 8:58 AM
Hi Don, Driving a piece of code by client code is older than TDD but surely part of it, at least the way my team practices it. A typical scenario: add the desired client calls to non-existent code, which forces the creation of the empty method; then write tests for the empty method, which forces correct implementation. The greatest thing about letting the client code drive is that I don't get LOST (now why am I writing this class again?) making complex augmentations.
MarkG wrote re: The Sellsian Approach
on 01-25-2007 10:56 AM
Don,

I'm feeling a kind of obsession regarding the TDD methodology, and speaking honestly, it looks like a fashion for me. It comes and goes.

I can say what I don't like in the Sellsian approach:
1. Somehow, noone speaks about performing some kind of analysis before coding. I mean, I do think about patterns before I'm going to use in my solutions, and I'm completely sure it's worth it.
2. I met tons of useless tests written just to cover minor scenarios when missing major ones. Most "impressive" part of it is that the overall design was not robust enough, because it developed without any kind of perspective in mind.
3. It's against a "common sense" (I know it sounds defiantly). I raised 2 start-ups and I can't see how I would have managed to cut initial time-line down investing resources in coding tests (I'm aware of that the TDD methodology is not only about coding tests). People love to get instant "return-on-their-investment" :) To prove your concept, you have to be more than just agile, you have to be fast.

Thank you
Oran wrote re: The Sellsian Approach
on 01-25-2007 11:01 AM
Behavior Driven Development replaces the word "test" with "behavior" to encourage Sellsian thinking. Of course they then proceed to tear through their favorite open-source testing framework replacing Test* with Behavior* which takes it a bit far. User scenarios are typically about how all the pieces flow together ("integration testing"), not how a unit of code behaves in isolation.

The Sellsian Approach is also described in some of the commentary in Framework Design Guidelines by Brad Abrams and Krzysztof Cwalina. Perhaps Sells was the commentator, I don't remember.
Scott Rudy wrote re: The Sellsian Approach
on 01-25-2007 8:06 PM
I think most of us (code slingers) prefer to write this way as the "other developers code" passes our definition of a requirements determination phase. The unfortunate part is that we are not the "other developer" or independent quality assurance testers and thus:

1) Technical writers are necessary to fill in the gaps of the programmers approach (sometimes after the product is released due to time constraints).
2) There is a honey-do list of enhancement requests for the first couple releases.
3) There are a significant amount of bugs to fix for the first couple releases.
4) The product isn't right until the third release.

Much of this can be avoided when you take a community approach to development. Based on what I have seen in the past few years, I think software companies are beginning to understand the value of this.
optman wrote 急人之所急
on 01-26-2007 7:39 AM
??????,????,????????????????,??????????,???????????????.???,?????????,?????????,??????.???????????
Paul Downey wrote re: The Sellsian Approach
on 01-27-2007 4:40 AM
I'm baffled how else would you develop an API but adopt this approach? Either I'm a fellow genius or you're stating the bleeding obvious ;-)
Mitch Wheat wrote re: The Sellsian Approach
on 01-27-2007 7:31 PM
I like to term this 'Be your own client', and find it is generally applicable to all design tasks. It's more of a mind set than a methodology...

I believe it is essential you think this way when designing how users will interact with software based processes.
//@ wrote re: The Sellsian Approach
on 01-29-2007 6:26 AM
Being your own client initially probably reduces complexity and targets the typical/common usage scenarios, but a skeptic in me doubts it provides the best API design ie. <i>API</i> being too broad a definition and <i>best</i> too relative.

From my limited experience, yes you get to obtain great object models easily, goodness for client audience, raise evermore those levels of abstraction and other user32/DOM/runtime stylisms :)

But, have seen an instance/domain that forces me to think: on flexibility of use ('make any API on top you desire'), easiness on wire, on integration (down to C or above XML), on granularity and especially on extending/introducing new functionality, nothing modeled beats simple grouping of message definitions and message patterns.

Which is how I read "what would my customer want to write".

Uninformed view only though..
Charlie Calvert's Community Blog wrote Community Convergence XX
on 02-02-2007 1:58 AM
Welcome to the twentieth Community Convergence. I'm Charlie Calvert, the C# Community PM, and this is
Neal Ford wrote re: The Sellsian Approach
on 02-02-2007 9:59 AM
For a lot of us in doing research in the Domain Specific Language space, this is self evident, and not just for testing. Look at the way Rake was developed: they sat down, figured out what they would like for it to look like, the bent Ruby to their will to make it look like that. Code should be written like this, not just tests. That's one of the many reasons that DSLs are better than just APIs.
William wrote re: The Sellsian Approach
on 02-05-2007 2:24 PM
I have been doing just that lately and did not know what to call it. Seems to make a lot of sense.
Gary Depue's VSTA Blog wrote Don Box on Object Model Design: The Sellsian Approach
on 02-08-2007 11:51 AM
Don Box blogs on OM design: The Sellsian Approach Around 1994, Chris Sells explained to me how he designs
dbox wrote Sellsian 方法
on 03-19-2007 9:34 AM
???1994?,Chris Sells???????????“?????”???????

“??,?????????,????????????????????????????????”
Auratius February wrote Writing code first?
on 03-22-2007 6:09 AM
I always tend to write code before doing my design. Please do not critisize me on this. I work in a 'fast
Javier wrote re: The Sellsian Approach
on 04-04-2007 12:29 PM
I think you're omitting a few things:

The approach that you describe has a defined *scope*: designing software for other programmers.

Sure thing, APIs and OO models (or app frameworks) should be approached from the main stakeholder's perspective: the developer.

There are, however, multiple stakeholders--at least in the software that I design--and the developer is but one of those stakeholders. I, in particular, have to answer to a systems engineering group, a developers group, test group, tech support, and take into account scheduling and technology constraints--I cannot use and deploy on the latest and greatest on my timeline :-).

I'm well aware of the "developer experience" that I must provide from my design...but I still use UML, design patterns...

Add a Comment

(required)  
(optional)
(required)  
Remember Me?


home instructor-led training online training blogs

781.749.9238 (East Coast) | 310.251.9901 (West Coast) | Pluralsight, LLC , 185 Lincoln St., Suite 305, Hingham, MA 02043-1741

Copyright © 2008 Pluralsight LLC. All rights reserved.

designed by nukeation