DevLink Open Spaces Theme

[Alan Stevens]

Hi All,

I had a great time facilitating my first open spaces at CodeStock last weekend. While I had announced the theme for the day prior to the event, I forgot to mention it at the start of the day because I was trying to rush into the first session. At DevLink, we will have the luxury of time for opening an closing circles where we can discuss the theme and how it was addressed during the event.

I would like your help in defining the theme for the DevLink Open Spaces. What issue is foremost in this groups minds right now? What topic needs exploration right now in our community?

--
++Alan

H. Alan Stevens

President, East Tennessee .NET Users Group:  http://etnug.org
blog:  http://netcave.org
twitter:  http://twitter.com/alanstevens

Podcast Interviews:
Visual Studio Extensibility:  http://tinyurl.com/yogrgy
Entity Framework:  http://tinyurl.com/2n9kal
Visual FoxPro:  http://tinyurl.com/2kfex4

[Evan Hoff]

> What issue is foremost in this groups minds right now? What topic needs exploration right now in our community?

 

How about:

 

A theme for DevLink Open Space...lol

 

or maybe..

 

How does Tuesday (26th) work for our first meetup? heh

 

Evan

[Alan Stevens]

Or maybe "Is sarcasm poisoning the conversation"? :-P

[Troy DeMonbreun]

Maybe...

DDD
Unit Testing Friction
Introducing Agility in the Workplace
Quality vs. ROI - When is Good Enough, good enough?

Or maybe you were looking for a higher level of abstration?

- Troy

[Alan Stevens]

Given the broad audience at DevLink, the first two are probably not appropriate, but I really like the last two suggestions.

Thanks.

[Will Gant]

Introducing Agility in the workplace would be cool. We've been trying to do it here (Brookdale) and have had some luck with it.


--- On Sun, 8/17/08, Troy DeMonbreun <TroyDeM...@gmail.com> wrote:

[Alan Stevens]

Right now I'm thinking Quality vs. ROI spawns the introduction to agile. I've been thinking a lot lately about the different connotations of simple and pragmatic in use on blogs etc.

Really, Quality provides a better ROI than non quality. Perhaps the driving issue is Quality vs. Time to Market?

[Troy DeMonbreun]

I replied to this hours ago, but I don't see the post, so here goes
try #2...

Agreed that Time to Market is very important. With the term ROI I was
trying to also encapsulate the other part of the "Triangle
Triumvirate", the Cost of Resources, e.g.: if we commit more resources
(in essence, cash), we can have more produced within a time-box (short
of diminishing returns). I think it is valuable to also address Cost
as a detractor from Quality, as it is so common in the Biz World for
the stakeholders to be as (IMO, more) restrictive regarding Cost than
Time to Market, though both are important.

ROI is all I can think of at the moment as term for the 2 (or more
than 2) high-level concepts that detract from quality.

On Aug 18, 7:36 am, "Alan Stevens" <alanstev...@gmail.com> wrote:
> Right now I'm thinking Quality vs. ROI spawns the introduction to agile.
> I've been thinking a lot lately about the different connotations of simple
> and pragmatic in use on blogs etc.
>
> Really, Quality provides a better ROI than non quality. Perhaps the driving
> issue is Quality vs. Time to Market?
>
>
>
>
>
> On Mon, Aug 18, 2008 at 8:08 AM, Will Gant <williamwg...@yahoo.com> wrote:
>
> > Introducing Agility in the workplace would be cool. We've been trying to do
> > it here (Brookdale) and have had some luck with it.
>

> > --- On Sun, 8/17/08, Troy DeMonbreun <TroyDeMonbr...@gmail.com> wrote:

> Visual FoxPro:http://tinyurl.com/2kfex4- Hide quoted text -
>
> - Show quoted text -

[Alan Stevens]

Troy,

I totally see where you're coming from. My issue with using ROI is that quality provides better ROI over the lifetime of the app, but I don't run into many stakeholders that think in those terms. The business concerns are usually focused around the short horizon of time to market.

I definitely think you have hit on the point of contention between the two camps claiming the terms value, simplicity and pragmatism. I think a clearly stated theme exposing that contention could spawn some very interesting conversations across tools, technologies, practices and business domains.

++Alan

[Evan Hoff]

> Really, Quality provides a better ROI than non quality.

Really?  Why's that?  You have to justify quality in terms of ROI or this entire discussion is all smoke and mirrors.

But of course, before you justify it in terms of ROI, you are going to have to define it.  Preferably, in some way that's directly or indirectly measurable.

Much like having a brilliant idea, if you can't communicate it, it's worthless.

And no, I'm not trying to spoil the conversation.  I'm just trying to challenge you a bit. ;-)

Evan

[Troy DeMonbreun]

Gotcha. I was thinking only short term ROI, a viewpoint unfortunately
popular among many businesses.

I think I threw myself a bit off track actually. ROI popped into my
head originally in the sense of the 80/20 rule, a.k.a. pragmatism.
The illustration that comes to mind is that if it costs, say, $10,000
to keep an uptime of 99%, then it can cost $100,000 to keep an uptime
of 99.9%, and possibly $1,000,000 to keep an uptime of 99.99%.
Somewhat like calculus in approaching 0, as we closely approach 100%,
the cost can increase exponentially. Therefore, where do you decide
that enough is enough, e.g.: are you getting a good ROI at 99, 99.9,
99.99?

Maybe we could call it:

Approaching 100% - At what point is Quality Overpriced?

Granted, it depends on the spin you want to give it. If you want to
take a wholly pro-quality approach, maybe:

Getting [Staying?] out of Technical Debt - Quality is your Capital
Getting [Staying?] out of Technical Debt - Quality is your Net Worth
Getting [Staying?] out of Technical Debt - Quality is your Equity

(Technical Debt as in http://www.martinfowler.com/bliki/TechnicalDebt.html)

I'll hold off brainstorming further until I get some feedback.

- Troy

On Aug 18, 3:45 pm, "Alan Stevens" <alanstev...@gmail.com> wrote:
> Troy,
>
> I totally see where you're coming from. My issue with using ROI is that
> quality provides better ROI over the lifetime of the app, but I don't run
> into many stakeholders that think in those terms. The business concerns are
> usually focused around the short horizon of time to market.
>
> I definitely think you have hit on the point of contention between the two
> camps claiming the terms value, simplicity and pragmatism. I think a clearly
> stated theme exposing that contention could spawn some very interesting
> conversations across tools, technologies, practices and business domains.
>
> ++Alan
>
> On Mon, Aug 18, 2008 at 4:27 PM, Troy DeMonbreun

> <TroyDeMonbr...@gmail.com>wrote:

> > > Visual FoxPro:http://tinyurl.com/2kfex4-Hide quoted text -

[Alan Stevens]

Evan: I think the points you raise are exactly the type of conversation I want this theme to spark. Rather than answer the questions with the theme, I want to provoke them.

Troy: I've heard Pareto(80/20) argued both ways. I hold that 80% of your cost is in maintenance and rework and 20% (or less!) is in the initial release, but others don't share my view. This is great conversation fodder.

You are correct in pointing out that there is a point of diminishing returns, and determining that point is also an excellent discussion topic.

Here are two blog nuggets:

Chad Myers has this awesome quote from Uncle Bob on his blog this morning:

But there is one set of criteria that I think all engineers will agree with. A piece of software that fulfills its requirements and yet exhibits any or all of the following three
traits has a bad design.

1. It is hard to change because every change affects too many other parts of the system. (Rigidity)
   
2. When you make a change, unexpected parts of the system break. (Fragility)
   
3. It is hard to reuse in another application because it cannot be disentangled from
   the current application. (Immobility)

Moreover, it would be difficult to demonstrate that a piece of software that exhibits
none of those traits, i.e. it is flexible, robust, and reusable, and that also fulfills all its
requirements, has a bad design. Thus, we can use these three traits as a way to unambiguously decide if a design is 'good' or 'bad'.

Then there is this nugget from Greg Young:

DDD is hard and often painful, it is costly up front and should only be used in domains that can justify its up front costs in maintainability.

Uncle Bob is answering the argument that good code is code that works while Greg Young is admitting that DDD is not appropriate in every situation. I think both of these go to the heart of the conversation I would like to see at DevLink this weekend.

I'm not sure that "Technical Debt" is well known enough to put in the theme and still attract a broad range of developers. Quality, pragmatism and ROI are all good candidates, however.

How about "Quality, pragmatism & return on investment: Finding the point of diminishing returns"?

[Troy DeMonbreun]

If we are attracting a broad range of developers, while pragmatism is
more well known than Technical Debt because it is an English word, I
still wonder how broadly known the term is among developers, not
universally known for their grammatical skills. I myself didn't know
the term until I read the Pragmatic Programmer, FWIW.

Maybe:

Quality, Practicality, and Return on Investment: Finding the Point of
Diminishing Returns.
Quality, Reality, and Return on Investment: Finding the Point of
Diminishing Returns.

- Troy

On Aug 19, 8:20 am, "Alan Stevens" <alanstev...@gmail.com> wrote:
> Evan: I think the points you raise are exactly the type of conversation I
> want this theme to spark. Rather than answer the questions with the theme, I
> want to provoke them.
>
> Troy: I've heard Pareto(80/20) argued both ways. I hold that 80% of your
> cost is in maintenance and rework and 20% (or less!) is in the initial
> release, but others don't share my view. This is great conversation fodder.
>
> You are correct in pointing out that there is a point of diminishing
> returns, and determining that point is also an excellent discussion topic.
>
> Here are two blog nuggets:
>
> Chad Myers has this awesome quote from Uncle Bob on his blog this morning:
>
> But there is one set of criteria that I think all engineers will agree with.

> A piece of software that *fulfills its requirements* and yet exhibits any or

> all of the following three
> traits has a bad design.
>

>    1. It is hard to change because every change affects too many other parts
>    of the system. (Rigidity)
>    2. When you make a change, unexpected parts of the system break.
>    (Fragility)
>    3. It is hard to reuse in another application because it cannot be

>    disentangled from
>    the current application. (Immobility)
>
>  Moreover, it would be difficult to demonstrate that a piece of software
> that exhibits
> none of those traits, i.e. it is flexible, robust, and reusable, and that
> also fulfills all its
> requirements, has a bad design. Thus, we can use these three traits as a way
> to unambiguously decide if a design is 'good' or 'bad'.
>
> Then there is this nugget from Greg Young:
>
> DDD is hard and often painful, it is costly up front and should only be used
> in domains that can justify its up front costs in maintainability.
>
> Uncle Bob is answering the argument that good code is code that works while
> Greg Young is admitting that DDD is not appropriate in every situation. I
> think both of these go to the heart of the conversation I would like to see
> at DevLink this weekend.
>
> I'm not sure that "Technical Debt" is well known enough to put in the theme
> and still attract a broad range of developers. Quality, pragmatism and ROI
> are all good candidates, however.
>
> How about "Quality, pragmatism & return on investment: Finding the point of
> diminishing returns"?
>
> On Mon, Aug 18, 2008 at 6:43 PM, Troy DeMonbreun

> <TroyDeMonbr...@gmail.com>wrote:

> > > > > Visual FoxPro:http://tinyurl.com/2kfex4-Hidequoted text -

[Brett Baggott]

Y'all know how to argue this issue in the traditional framing but my
guess is, this pain is universal. I think _that_ is where you will
have your great Open Spaces. IOW, a lot of the developers at DevLink
may not have been exposed to the "technical debt" terminology but
they've _felt_ it. They will understand it.

I think this (Discussion on Quality) will be an excellent topic, no
matter what it's called.

> > > > > > Visual FoxPro:http://tinyurl.com/2kfex4-Hidequotedtext -

>
> > > > > > - Show quoted text -
>
> > > > --
> > > > ++Alan
>
> > > > H. Alan Stevens
>
> > > > President, East Tennessee .NET Users Group:http://etnug.org
> > > > blog:http://netcave.org
> > > > twitter:http://twitter.com/alanstevens
>
> > > > Podcast Interviews:
> > > > Visual Studio Extensibility:http://tinyurl.com/yogrgy
> > > > Entity Framework:http://tinyurl.com/2n9kal
> > > > Visual FoxPro:http://tinyurl.com/2kfex4-Hidequoted text -
>
> > > > - Show quoted text -
>
> > --
> > ++Alan
>
> > H. Alan
>

> ...
>
> read more »- Hide quoted text -

[Alan Stevens]

I totally agree. I want to avoid anything that smacks of insider jargon. Practicality is a great substitute.

How about "Quality, Practicality, and Return on Investment: How do we define good enough?"

[Troy DeMonbreun]

What say ye onlookers?

On Aug 19, 11:56 am, "Alan Stevens" <alanstev...@gmail.com> wrote:
> I totally agree. I want to avoid anything that smacks of insider jargon.
> Practicality is a great substitute.
>
> How about "Quality, Practicality, and Return on Investment: How do we define
> good enough?"
>
> On Tue, Aug 19, 2008 at 11:00 AM, Troy DeMonbreun

> <TroyDeMonbr...@gmail.com>wrote:

> ...
>
> read more »- Hide quoted text -

[Colin Callahan]

That theme sounds great to me.

Colin

[Troy DeMonbreun]

Oh, just noticed (via Twitter, ironically) that the subtitle changed.
I agree with Evan that the new subtitle kind of implies a goal of good
enough - it's a subtle difference from "When is Good Enough, good
enough", where I was trying to do a little play on words. Granted,
maybe Evan is thinking that we should stay completely away from the
term "good enough". I'm not overly tied to it myself. I liked the
whole Technical Debt thing best, but agree it is esoteric for many. I
like your subtitle of "Finding the Point of Diminishing Returns" the
best so far.

- Troy

http://twitter.com/troydemonbreun

On Aug 19, 11:56 am, "Alan Stevens" <alanstev...@gmail.com> wrote:
> I totally agree. I want to avoid anything that smacks of insider jargon.
> Practicality is a great substitute.
>
> How about "Quality, Practicality, and Return on Investment: How do we define
> good enough?"
>
> On Tue, Aug 19, 2008 at 11:00 AM, Troy DeMonbreun

> <TroyDeMonbr...@gmail.com>wrote:

> ...
>
> read more »- Hide quoted text -

[Alan Stevens]

I like the fact that the term "good enough" has sparked discussion. I think it is better for exactly that reason. If however you think it distracts from the core issue, I'm open to further refinement.

[Troy DeMonbreun]

Well, I definitely hope that the "Good Enough" argument comes up.
It's always a good one. :-)

This is your baby, you should have a good amount of input.

- Troy

On Aug 20, 1:54 pm, "Alan Stevens" <alanstev...@gmail.com> wrote:
> I like the fact that the term "good enough" has sparked discussion. I think
> it is better for exactly that reason. If however you think it distracts from
> the core issue, I'm open to further refinement.
>
> On Wed, Aug 20, 2008 at 11:30 AM, Troy DeMonbreun

> <TroyDeMonbr...@gmail.com>wrote:

[Alan Stevens]

 My thinking is that every discussion, no matter the specific topic, good enough will have to be addressed. It should force people to recognize and question dogma.

I don't get to convene any sessions, so you guys need to tell me if this theme is off track for YOUR event.