edjez's WebLog : Off the deep end...

Invoking the ghost

edjez — Fri, 28 Apr 2006 23:37:00 GMT

Let’s say you are talking about a program with someone. Imagine stakes are somewhat high. Suddenly one of these two phrases gets thrown out:

1. "It could be faster"

In any but the healthiest of teams, these are great words to put folks on defensive and stop rational conversations about code. Suddenly the neurons spin (?) and we wonder- is there something we missed? Is my code wrong? Did I screw it up all over the place? Does this guy/gal have some privileged piece of information? When someone tells you "It could be faster" - what's your typical reaction…?

2. "It's for security reasons"

That's another one. And it's funny I even dare to bring this up, being from Microsoft and all that. Who would be brave enough enter a debate about code being written for such an honorable purpose? Who would be enough of a security expert to dare question the existence of code that is there to protect us from evil, shame and regret? Do you want your grandchildren to remember you for being the dude/dudette that left that gaping security hole open? That was exploited by that worm that took civilization back to the 19th century in one fell swoop? I know I don't want to be associated with an accidental return to hunter/gatherer lifestyle ...so we block the issue in our heads and move on.

What's going on here?

These are just two examples of what I call 'invoking ghosts' in discussions about software. We bring up a topic that is vague, crosscutting, obscure, to 1) provide an excuse to do work or not do work, independently of how sensible it is to do it or not 2) win a debate against The Other Idea 3) raise FUD levels and gain control of the situation or reduce others' credibility 4) basically steer the conversation away from the code and into people manipulation.

Now, don't get me wrong. Perf and security are important (Doh! I sound like an idiot....I guess you can quote me on that...No, the first phrase) Things can be faster and you could be doing things for real security measures - but how to tell? What do you do if in a conversation someone invokes these topics as ghosts, and steer it back into a productive place?

Fortunately, I think there are good patterns and tools to communicate around these issues. A huge one is to be transparent about the goals and unknowns. This basically puts on the table 1. What is it that you are trying to achieve, and 2. An acknowledgment that the understanding of the problem and the shape of the solution are still evolving.

What has helped me is to get to a shared (implicit or explicit) commitment to an approach:

1) Establish the needs & the priorities

2) Analyze current situation and set a goal for an improvement

3) Work on improving the system, checkpoint against goals

4) do it all again

This actually sounds quite obvious, but it has helped me bring sanity to discussions about quality attributes such as performance & scalability, security, manageability, maintainability, and other areas where 'ghosts' tend to live. Quality attributes tend to be particularly good 'haunted houses' because of their crosscutting, distributed nature, and because we tend to have less than ideal tools to think about tests of success.

If you look at the 4 steps above the first one is about establishing needs - figuring out your tests, if you will. There has been a lot of work for many years around helping people figure out their tests/needs for quality attributes.

For security you have Threat Modeling, for manageability you have Health Modeling, for performance you have Perf Modeling, and I hope good frames come up for other quality attributes as well. But what I particularly like about these models is that they aren't models about the solution, but models for tests (and steps 2, 3 & 4 are just process guidance to help us make them pass…the “green and refactor” of the “red, green, refactor” cycle).

In my opinion the focus on tests first for these complex areas makes these approaches and tools intrinsically suitable for expressing partial, incomplete or overlapping goals (which tends to happen whenever humans are involved..), and helping people iteratively collaborate around defining, verifying and refining them.

By starting with tests, we support an inductive approach to building the solution, akin to what you do with TDD. Now maybe we still don't have good tools to automatically test our systems based on all these testing models, but I hope that's just a matter of time (base DSL for tests that can be specialized for specific domains, anyone?). Eventually, these tools could become part of the suite of tests that drive the creation of the solution, treated as acceptance tests tied to business needs, and maybe even verifiable against systems at runtime.

…In the meantime it takes toil, tinkering, and a dabbling with mental experiments. But most of all I think it takes clear communication between people. Here’s some resources around these topics that I’ve used to help me scare the ghosts away from the conversations, and keep them productive, collaborative, and smart:

What makes a good threat model – by J.D. Meier

Performance & Scalability Checkpoint to improve your software engineering – by JD too

MSDN page having lots of things threat model (the generic portal)

Rico Mariani’s blog – Entry with the foreword of the p&p perf & scale guide with a quote of Donald Knuth quoting Tony Hoare saying ‘

Health Modeling - whitepaper on the Windows Server. They’ve done us all the favor of dumping the health model of a printer in XML. Whee! (But can you write a test runner for it?)

(Whither my simplicity model paper? Related to maintainability of code? I digress)

Kudos: It’s clear that J.D. has done a lot of work in this area. He’s the best I know at distilling these areas in significant, actionable, and insightful ways.

(OK, My cereal is going something like "Ed - W-T-F-is-this-fluffy-post? Why don't you tell us about dependency injection, aspects, executable models, Object Builder, using XAML to define types dynamically, gps, CAB running in mobile devices, workflow and UI or concurrency or whatever?" A: "I believe writing software is a social activity. I believe that if we learn to communicate, improve how we reason, become more self-aware, and question assumptions in more effective ways we will plain simply write much better software and enjoy it more along the way. Plus - it's my blog. And my doctor told me I shouldn't talk to cereal.)

What's in a name? What's an "Application Block"

edjez — Mon, 24 Apr 2006 18:52:00 GMT

Often I get the question 'what is an application block' and 'why that name'? We have lots of articles, webcasts etc describing them how we've built them and how to extend them or build your own. Then people ask 'what is the difference between a block or a library or a framework' and I remind them that we use the Application Block name to reflect a set of expectations around packaging, design and how they could be used.

Using the word “blocks” was done to evoke a set of patterns about how p&p -and hopefully eventually more of MS - chooses to distribute reusable chunks of bits, without constraining them too much a priori. The approach has allowed our team, communities and others to participate in their evolution rather than try to invent something different altogether. There is an existing taxonomy of chunks of reusable code, and using the word "Blocks" was not done to try to introduce a new item in this taxonomy (that would be arrogant) or redefine existing terms.

There's plenty that's been written about code libraries (things you can use), frameworks (things that affect the architecture of your code a bit more), app containers and the likes, so I won't go there. I'll just say why I didn't think this would be a good distinction to revolve around when you are creating names for a new product line.

I believe good names tend to be:

- Unspecific enough that you can accept variability of the named thing.

- Short

- Metaphorical. The concept of the name evokes visual, physical/physiological and metabolic actions.

- Associative and work by metonymy, just like 'White House' represents a government, a president, and a big dome, and not a building.

I believe a good name does not need to reflect every detail, or every characteristic, or the complete position in the taxonomy, of the thing it describes. For engineers it causes some heartburn (to realize that better names are not necessarily better for classification) but it's easy to embrace once you understand why.

(If you are interested in this you can read Lakoff or cognitive science papers from the last couple of decades. The one thing that strikes me the most is the impact of physical evolution on the brain's workings, which is one of those conclusions that just strikes me as insightful. What dictates the shape of the box we tend to think in? Thanks Ward for recommending this author)

Back to code. You can read plenty about the distinctions most of the experts in the community put forward between libraries and frameworks. I will oversimplify, but in the end libraries are things I can use, and frameworks tend to mess with the architecture and design of my own code. Maybe containers implementing DI tend to clarify the edges a little bit, by allowing an otherwise hefty-framework-author have better boundaries between what you use and what affects you.

The one difficulty I find when trying to classify blocks in terms of "libraries" of "frameworks" is that folks will not understand application architecture in objective ways. For example, enterprise library is IMO a great example of "Library" chunks. However, if you ask around many folks consider EntLib to 'deeply affect the architecture of their app'. One man's library is another man's framework. On the other hand, CAB has lots of pieces which are canonical "framework" chunks and a gentle sprinkling of "library" pieces. It has both gentle and forceful ways of suggesting a design for some areas of your code. I do think we could have packaged CAB up a bit better by breaking out specific pieces, but we all have constraints.

So to summarize them, the name "Application Block" does not reflect a precise place in the taxonomy of reuse, rather, a loose metaphor that encompasses a family of assets, and how you use them. Using blocks should be a matter of choice, they work together, they can be piled up, you can use many or a few, they will probably have commonality internally and externally as dictated by efficiency and usability, and they should be fun.

New Blog Section - "Off the deep end..."

edjez — Mon, 24 Apr 2006 18:12:00 GMT

Disclaimer: JD Meier suggested I get to blogging and after some discussion why I haven't been doing this, I decided to create a section for 'off the deep end' posts. The description is is a reference to Gödel: Thoughts, Ramblings, and content not computable through predicate calculus.

My hope is that I can put things in this section with an implicit disclaimer.