Back Seat Driven Development
secretGeek .:dot Nuts about dot Net:.
home .: about .: sign up .: sitemap .: secretGeek RSS

Back Seat Driven Development

Various development 'methodologies' talk about being 'driven' from one place or another --

Model driven, Test Driven, User Interface Driven, Todo Driven Development (ahem) and so on...

Each of these practices dictate a particular starting place for work -- a single place from which the 'truth' emanates. The resulting tool chain is focused on radiating the 'truth' outward from this driving place -- whether it's the model, the tests, the spec, the database, the user interface.

When the truth changes, you go back to the 'driving' place, alter it, and update the solution from there. So in model driven development you alter the model then rebuild the app. In test driven development you update your tests and see what fails. In database driven development, you alter your database and re-run your code generators.

This is all nice -- but each form is limiting.

What would be nice (and by nice I mean damn impossible) would be if each of these potential places was both a driver and a result.

So that -- without prejudice (without fighting the tools) -- you could update the user interface and have this change flow back to the business layer, the database, the tests, the model, all places.

You could then tweak the database and have this change flow out to the tests, the business layer, the user interface, the model. You could change the model and have the change propagate around to each place.

In code generation speak I think they call this 'active code generation' -- and it's never seemed realistic or clean.

But that's what I would like, please. And I would like you to go and write just such a tool for me please.

I will pay eight dollars for it.

(first person to mention RoR scaffolding gets their ip address banned)

(no, i wouldn't really ban your ip address, i'm just sayin...)





'PJW' on Wed, 09 May 2007 23:05:48 GMT, sez:

So you want a reversible GLR parser? If a working implementation was released today, closed source, I think you would have to wait a long time for the price to come down to 80 dollars.



'lb' on Wed, 09 May 2007 23:20:45 GMT, sez:

@pjw -- not 80 dollars -- 8 dollars ;-)



'Dylan Bennett' on Thu, 10 May 2007 05:38:07 GMT, sez:

Ha! I came to the site from my RSS reader just to see if anyone had mentioned *ahem* those red... train... platform... things... *ahem* only to find your note about banning. Nice. :)



'Karthik' on Thu, 10 May 2007 13:10:12 GMT, sez:

I've actually seen this done before...a model and view which pro actively responded to changes on the database. It was a custom CMS app written using ASP.NET and SQL Server. I can see the value in such a system, but I think there are way too many devs out there that would not want the data to affect the view without any human intervention.



'Helen' on Thu, 10 May 2007 15:24:28 GMT, sez:

Australian dollars or american dollars?



'Steve Campbell' on Thu, 10 May 2007 17:04:00 GMT, sez:

The reason we drive from a single place is because that is the place which has a certain amount of valuable information. You cannot drive from another place because to do so would imply that that other place has the same valuable information, plus more (because otherwise what's its purpose). Thus that place would be the better driver, and you could not have been driving from the first place to begin with.

Rinse, repeat, recurse, catch-22 chickens and 21 eggs.



'lb' on Thu, 10 May 2007 21:24:50 GMT, sez:

@Karthik: "would not want the data to affect the view without any human intervention"

Sometimes yes, sometimes no.
You'd need the 'flow rules' to be easily revised, to sometimes ask for confirmation, sometimes to just show what they've pushed to where (and let you undo the symptom, without undoing the cause). Wise defaults are important, and a flexible review process.

@Karthik: "a model and view which pro actively responded to changes on the database"

I'd like to see that. Though, I think that it wouldn't begin to be useful until it was really really good.

@Helen:
let's say: hong kong dollars. ;-)

@Steve: "Rinse, repeat, recurse, catch-22 chickens and 21 eggs."
Love it.



'lb' on Thu, 10 May 2007 21:28:34 GMT, sez:

@Steve: "The reason we drive from a single place..."

But in a car, do we really drive from a single place? For one thing, we put 'rear vision' mirrors all over the car. Second -- if you're using a GPS navigation unit, then you're also employing a bird's eye view of the local area.

It's strange, but we tend to drive from one main place, with info from other places too.



'Andrew Shepherd' on Thu, 17 May 2007 21:18:43 GMT, sez:

We've written a code generator that creates an .XSD file from a schema, and then we automatically generate a .NET dataset from this, and then plug a DataGrid into that.
The resulting user interface is semi-useful for what we use it for (an in-house testing tool) and would be absolutely useless in the hands of a non-developer.

If a client application is a mirror of the database, then you have at least one of two things: a really crap user interface, or a woeful database design that doesn't support multiple users.

I'll just make the sweeping statement that code generating the user interface from the database, or vice versa, will never be possible for a professional looking end-user application. At least not possible in a way that's actually useful.

But hey, you've saved eight dollars!




name


website (optional)


enter the word:
 

comment (HTML not allowed)


All viewpoints welcome. But the right to delete any post for any reason is reserved. Don't make me do it. Comments may be republished, emailed to your loved ones or printed and used as toilet paper. Who reads this legal bit anyhow?

TimeSnapper is a life analysis system that stores and plays-back your computer use. It makes timesheet recording a breeze, helps you recover lost work and shows you how to sharpen your act.

TimeSnapper won last year's Developer Competition at Larkware.com, and is used by over 10,000 people.

Articles

TimeSnapper 3.2: What are you afraid of? TimeSnapper 3.2: What are you afraid of?
Babbage and Boole! Babbage and Boole!
Downloadable Slide-decks: Downloadable Slide-decks: "Build your own Tiny Software Company"/"F# eye for the C# guy"
Simple Trouble Shooting Application Now Fixes Everything Simple Trouble Shooting Application Now Fixes Everything
a simple checklist for trouble-shooting regular problems a simple checklist for trouble-shooting regular problems
secretGeek at Tech-Ed: secretGeek at Tech-Ed: "How to build your own Tiny Software Company"
Bambrick versus Hanselman: Bring it! Bambrick versus Hanselman: Bring it!

Archives .: secretGeek :: Complete Archives :.
25 steps for building a Micro-ISV 25 steps for building a Micro-ISV
3 minute guides -- babysteps in new technologies: powershell, JSON, watir, F# 3 Minute Guide Series
Top 10 SecretGeek articles Top 10 SecretGeek articles

Downloads

TimeSnapper -- Automated Screenshot Journal TimeSnapper.com    
Version 3.1: instant productivity profiles

ShinyPower (help with Powershell) ShinyPower
Now at CodePlex

Next Action NextAction
Managing the top of your mind



[powered by Google] 


World's Simplest Code Generator (html edition) World's Simplest Code Generator
Gradient Maker -- a tool for making background images that blend from one colour to another. Forget photoshop, this is the bomb. Gradient Maker
How to be depressed How to be depressed
You are not inadequate.



Recommended Reading

The Best Software Writing I
The Business Of Software (Eric Sink)

Recommended blogs

Jeff Atwood
Reginald Braithwaite
Joseph Cooney
Phil Haack
Scott Hanselman
Julia Lerman
Joel Pobar
Eric Sink
Joel Spolsky
Des Traynor

Aggregated Links

programming.reddit.com
dzone
dot net kicks

Human Link Machines

interesting finds
a continuous learner's weblog
arjan's world
n links today
new and notable
morning coffee
learning .net
weekly link post
(my del.icio.us account)

LinkedIn profile
 
home .: about .: sign up .: sitemap .: secretGeek RSS .: © Leon Bambrick 2006 .: privacy

home .: about .: sign up .: sitemap .: RSS .: © Leon Bambrick 2006 .: privacy