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...)Next → ← Previous
I'm currently writing a book about how to build your first product. If you want to build your first product, please sign up to be notified when the book is available.