Framework Design Guidelines in stock…

Today I noticed that Amazon has the Framework Design Guidelines in stock (finally)... you can also post comments up there now.  Especially for those of you that already have a copy of the book from the PDC, please do post a review and let us (and your fellow developers) hear what you think of the book…. 


In honor of this day I thought I’d kick off a series of blogs discussing bits of information from the Framework Design Guidelines.  I am looking forward to having some conversation on each one, so let me hear what you think!  BTW – a full sample chapter is available from Addison Wesley here


Chapter 2.0

DO explicitly design for a broad range of developers with different programming

styles, requirements, skill levels, and using different programming



DO understand the broad range of developers using multilanguage



PAUL VICK There is no magic bullet when designing frameworks for

Visual Basic programmers. Our users run the gamut from people who are

picking up a programming tool for the first time through to industry veterans

building large-scale commercial applications. The key to designing a

framework that appeals to Visual Basic programmers is to focus on allowing

them to get the job done with the minimum amount of fuss and bother.

Designing a framework that uses the minimum number of concepts is a

good idea, not because VB programmers can’t handle concepts, but because

having to stop and think about concepts extraneous to the task at hand

interrupts workflow. The goal of a VB programmer usually is not to learn

some interesting or exciting new concept or to be impressed with the intellectual

purity and simplicity of your design, but to get the job done and move on


What do you think? VB developers out there, do you agree with Paul? My guess is that Paul equally well describes many C#, C++ developers as well, no?

Comments (8)

  1. tzagotta says:

    I agree – Paul’s comments should apply to most C# programmers also. There’s no reason to believe that someone programming in VB would be more or less task-focused than someone programming in another programming language.

  2. I am a C# developer with 8 years of professional C++ experience. I have seen two types of people – those that want to get the job done and would like nice, clean and easy to use library and those that like to marvel in the beauty and perfectionism of the library regardless of its complexity.

    The former usually ship the products and the latter endlessly refactor and clean up the code.

    That said, there is a limit to the simplification of the use of your library. Sometimes the user of the library HAS to learn some concepts before though usually that is not the case.

    Knowing that properly written library should be usable by any .NET language the goal for the library developer should be (IMHO) to make a good library (having in mind goals stated above by Paul) and not to target any specific audience.

  3. Jonathan Allen says:

    That is about as accurate as you can get. I hate working with Java frameworks because they make it so difficult to write even the simplest of programs.

    Jonathan Allen

    "No matter what your pattern books say, complexity does not equal elegance."

  4. Sean Chase says:

    IMO – Mort, Elvis, and Einstein work with different languages just because it is their language of choice. Some favor curly braces, others fear them. In other words, not all C# developers are Elvis. Not all VB programmers are Mort. Although in general that may be the case. 🙂

    I have certainly seen Mort prefer C# just because they think C# is cool, and they still write C# programs the same way they used to write VB6 programs…like crap. 🙂

    So, does everyone want to focus on getting their jobs done efficiently? Of course! But, that being said: either people care to continue their learning, or they don’t regardless of what language they prefer. Developing APIs for those who don’t is really what Paul Vick is talking about I think.

  5. vippx says:

    I would partially agree with Paul’s opinion. This comes from my own experience of hearing, "A good framework is a combination of carefully arrived at compromises" many a times. While I seen the principle work extremely well on a domain specific framework, I doubt the application of the same precept on a general purpose framework. The approach is fine; Provide people with what they need to achieve their goal and move on, but also in a lesser esoteric way, they should be provided efficient ways to bypass certain rules, even though it would involve some complexity. Its very disheartening to ask a developer to learn a new language just because a certain feature is not supported by his/ her favorite language. Ofcourse there can be best practices advices and sufficient caution (like PInvoke in .NET, an excellent idea), but the availability of a feature instills more confidence in choice of language. Now doing this elegantly is where the real challenge lies.

  6. Jonathan Allen says:

    > So, does everyone want to focus on getting their jobs done efficiently?

    No, not really.

    I have worked with a several people that focused primarily on using patterns, not on getting the job done.

    Others focused on building tools to help them with the project, ignoring the fact that the month their tools would save doesn’t account for the 3 months it took to write.

    Still others are so starry eyed about using new technology that they make the problem much harder than it really is. In my experience, this usually involves trying to use XSLT, MS Message Queues, or J2EE in totally inappropriate ways.

    I suspect that lack of focus, more than anything else, is the cause for most failed software projects.


  7. The GoF Design Patterns book has probably done more harm to software framework development than any other book. I loved that book when it was published, but it advised to use the "design" patterns as building blocks to add flexibility and extensibility to your libraries.

    There is no end to the addition of extensibility and flexibility, for any given set of features. You can recursively add abstractions ad infinitum. The result is a framework that no one likes to use: who wants to learn 10,000 new abstractions? Avalon is a good example of such a framework.

    This has nothing to do with language choice. Everyone is under pressure these days to work quickly, so the quality standards for frameworks must be higher, and learning curves lower.

  8. I would agree that Paul’s comments apply to any language and technology. Simplicity is an important design goal. But I think it’s worth noting the difference between internal flexibility and the simplicity of the interface. Not to put too fine a point on it, patterns don’t help the client, they help the author. It’s our responsibility as framework designers to present facades to users that are easy to understand and use.

Skip to main content