The desperate quest for doing it 'right'

re: The desperate quest for doing it 'right'

FransBouma — Mon, 01 Jun 2009 11:39:24 GMT

@yohoe1101: I don't see building a bridge as science, it's an application of science so a bridge can be build. In that light, writing a program isn't science, it's applying science so the software is doing what it should do. At least I look at it that way. Others see it as a creative process which has little to do with science at all. I find that a little too farfetched.

The science behind what we apply in software engineering every day, I think that's exact, as in: you can prove that things are correct or not. How that is applied in writing actual software is up to the engineer. Similar to how physics and math is applied in building a bridge.

re: The desperate quest for doing it 'right'

yohoe1101 — Sun, 31 May 2009 22:50:54 GMT

I'm interested in your thoughts on software development being an exact science. Is building a bridge an exact science? An automobile? Yes, the comparison is apples to oranges, but (I'm sure I am not the first to say this) they are both fruit, are they not? (please don't "flame me" - I have out there thoughts but I'm not trying to waste anyone's time)

re: The desperate quest for doing it 'right'

BinroeTheHeretic — Thu, 21 May 2009 18:31:33 GMT

It's interesting that most of the comments focus on the problem and not on what I thought was your main point: that "context" is everything. I'm reminded of Andy Hunt's book "Pragmatic Thinking and Learning," where he points out that the difference between an expert and a novice is the ability to 'adjust' a rule (idiom/design pattern/etc) based on context. Thanks for the peek at another real-life problem and the dilemmas that we developers go through...

re: The desperate quest for doing it 'right'

Mark Smeltzer — Wed, 20 May 2009 20:14:39 GMT

Anyone from an Agile background, like myself, will happily write "ugly" code on the first pass that gets the job done and makes our tests pass.

Once the tests are passing, we can go through the "messy" bits and look for anything that would benefit from immediate refactoring.

From an Agile perspective, the cost-benefit analysis of making these refactorings should always be at the forefront of one's thought processes. This goes against the dogmatic it-must-be-this-way type of thinking.

Sounds like you're either moving towards, or already endorse, Agile techniques.

re: The desperate quest for doing it 'right'

FransBouma — Wed, 20 May 2009 15:30:23 GMT

@Mark: I think I understood what he said, I'm not denying that a set of UI specific classes for display purposes only is a solution, however my pragmatic gut-feeling tells me that writing a hierarchy of classes for just UI display purposes (and we're talking about a lot of classes here), is a bit overkill if I can solve the particular problem with 1 if statement.

(the article wasn't about the UI specific problem as well ;) it was about the question whether chosing a less 'popular' option( because it seems 'not done' in the eyes of the preachers on the internet and books/conferences) is something you should do because it fits your situation or should you drop it because someone else might say "what a bunch of **** code!", as it doesn't match <insert hype of the day>-coding style.

re: The desperate quest for doing it 'right'

Mark Smeltzer — Wed, 20 May 2009 09:56:43 GMT

Frans,

I think you misunderstood Think Before Coding's point about a view model.

Imagine that your Model contains this interface:

public interface IHasChildren<T>

where T : IHasChildren<T>

{

#region Properties (public)

IEnumerable<T> Children { get; }

#endregion

}

Now, for presentation purposes, you may find situations where it would be VERY helpful to be able to nagivate from child to parent (say when a UI event is fired on a child, we may have to do something with the parent).

Since it may not be possible or it may simply be difficult to modify all of the classes that have the IHasChildren<T> interface, we can add a decorator to the View Model, which is used only in the presentation layer:

public class ParentChildDecorator<T> : IHasChildren<T>

where T : IHasChildren<T>

{

#region Fields (private)

private readonly T _item;

private readonly ParentChildDecorator<T> _parent;

#endregion

#region Constructors

public ParentChildDecorator ( T item, ParentChildDecorator<T> parent )

{

_item = item;

_parent = parent;

}

#endregion

#region Properties (public)

public IEnumerable<ParentChildDecorator<T>> Children

{

get

{

foreach ( var child in _item.Children )

{

yield return new ParentChildDecorator<T>( child, this );

}

public ParentChildDecorator<T> Parent

{

get

{

return _parent;

}

#endregion

#region IHasChildren<T> Properties

IEnumerable<T> IHasChildren<T>.Children

{

get

{

return Children.Cast<T>( );

}

#endregion

}

Now you can use the following type of code to interact with any object that implements IHasChildren<T> in a bidirectional fashion using the decorator above:

var item = new TestItem {

Children = new[ ] { new TestItem( ) }

};

var viewModelItem = new ParentChildDecorator<TestItem>( item, null );

Debug.Assert( viewModelItem.Children.First().Parent == viewModelItem );

Suffice it to say that a View Model is a set of classes/interfaces that exist only at the presentation layer to make the necessary adjustments to the underlying Model to make it VERY EASY to program the presentation layer. There are plenty of good write ups on the View-View Model-Model-Controller pattern out there.

re: The desperate quest for doing it 'right'

whatthe12 — Wed, 20 May 2009 02:36:35 GMT

"So I wondered: isn't this quest to find what the right thing is actually haunting our profession and why exactly is this?"

In 'Zen and the Art of Motorcycle Maintenance', Robert Pirisg write a lot about how his students are crippled by a compulsion to do 'the right thing' at the expense of their creativity.

When I first started programming I was using Flash 4 which nobody really took seriously. It was a lot of fun and as long as something worked people were pretty amazed whatever the state of the code beind it.

As Flash has evolved and I've got into more industrial quality technologies, I've lost some of my ability to reason and have confidence in what I do because I've become infected with the need to things the 'right way'.

re: The desperate quest for doing it 'right'

p.gielens — Fri, 08 May 2009 13:44:50 GMT

So if I understand this article and the comments correctly, these are the important nuggets:

Context - key to success is your understanding of the problem at hand.

Gray - there’s no right or wrong. Track (involve your audience) the decision making process.

Reversibility - a decision that is easy to reverse should be dealt with in a pragmatic manner.

I agree with all of these points and I’d like to add that "decision making" is much bigger and complex than we touched in this article. Frans was clearly wearing his white thinking hat ;)

Have a great weekend all!

re: The desperate quest for doing it 'right'

Think Before Coding — Wed, 06 May 2009 14:56:24 GMT

I see what you mean, the important thing is to 'understand' your problem.

The only one 'right' thing to do is the thing that follow from a deep understanding of your problem. It often has to do with hidden concepts.

As you've seen, my comment was not to say 'it is the right thing', and I tried to give a little context of how I understood the problem, and a adapted solution in this vision.

But you know your problem far better than me :P and my response was just a suggestion depending on a external vision of things. Your the one in charge of your code, you decide !

About my name (think before coding), understand it as in : 'a game of chess is like a sword fight, you must think first, before you move'. Think in movement. While coding, the battlefield change after every single line you write. And this goes in your direction.

re: The desperate quest for doing it 'right'

FransBouma — Wed, 06 May 2009 12:50:45 GMT

@Think before coding: the treeview does reflect the model, that's it purpose, the user can browse the model through the UI. I see what you're getting at, though the visual representation is actually simpler here: the physical model is presented as such, the thing is that not every element in the hierarchy knows what its parent is. It's not coupling that's part of the problem, because the elements of physical hierarchy internally (the model objects) aren't always knowing their containers, (due to decoupling of their defining namespaces/assemblies), this has nothing to do with the visual representation of things, that's just a way to show what we're dealing with here.

The point of the post however isn't to focus on that detail, it's about the fact that if something is presented as 'do this, it will make things better', it requires context, and it also requires that that context matches the context you're dealing with. If not, the advice is not useful. Furthermore, people should always think for themselves (e.g. think before coding ;)) to find out what is the best approach, based on arguments they define/recognized themselves.

Like, 'decouple your concerns, it will make your code better'... why? (I'm not arguing it wouldn't, I just use it as an example) A person should think about why that is, and what the pro/con's are of decoupling and tight coupling and what's better for a given situation. THEN the developer makes wise decisions and the software is maintainable (as decisions are based on reasoning) and not a hodgepodge of 'good' advice brought by random people on the net.