| |
4:01:08 PM |
 |
Prevayler: Just do it!. Chiara has a really funny discussions on the largest reason behind choosing to use a relational database (or any other kind of database really) instead of Prevayler: Fear.
Pick up any book about eXtreme Programming, the largest problem to overcome when Keeping It Simple is fear. Your fear, your colleagues fear, you bosses fear. Keeping It Simple is not about making simple software, it's about keeping the software as simple as possible given the circumstances. It's about none other than you taking the decisions and the responsibility for the software being you're producing. You can't just follow the book, you have to decide for yourself. This also means there's noone to blame when things go wrong.
The best way to do it is Just Do It. When you've started you never want to go back. Seriously, I've never produced software at this pace before. Our project management plans a couple of stories for our 2-week iteration. They're all done the very first day of the iteration. Ok, the project management plans another set of stories. They're done by the next day. And this goes on and on, we really had no idea of what kind of velocity you could get. Things that would take weeks with EJBs and RDBMSs we're now doing in hours.
I mean, we're all looking to increase software development productivity, I think I might have found a solution...
(And now I haven't even mentioned the absurd performance you get out of it, people simply doesn't believe it, they insist on it being some kind of static HTML-demo.) [jutopia]
Yes yes and yes :). Taking the top down approach can simplify so much. The higher you climb to the top before making the leap down, the faster you go.
Dan North recently taught me to 'ask the stupid questions'. There's a project, it is using some kick ass app server, a database cluster, awesome persistence layer. The database schema has been modelled to perfection. The object model is very clean. Enter the stupid questions...
"What are you trying to do?" - "Use our system to handle persistence."
Not high enough.
"Why do you need that?" - "Makes it much easier to store objects in Oracle."
Not high enough.
"Why would you want do that?" - "Because, uhmm, like we need data to be stored in a database."
Not high enough.
"Why?" - "Grrr... because how would we be able to invoice the customer if we didn't store their details, eh?"
Not high enough.
"Why do you need to do that?" - "Because that f*kin requirement says 'It must be to obtain an invoice for each customers purchase' - OK?"
Ok, that's high enough. 'It must be to obtain an invoice for each customers purchase'.
What's the simplest way that can be done? I'm not sure. But if I start writing a test, I'll start to get a good idea of what objects I'll need and any methods that need to be created. From there I bet the simplest way to get the test to pass doesn't involve 90% of the stuff I was planning on using from the architecture.
The best code is that you can take no more away from.
| 
