Comments on: Save Us From Needless Abstractions http://tottinge.blogsome.com/2005/09/23/save-us-needless-abstractions/ Tim Ottinger on Christianity, freedom, software, podcasts, and really hot-looking guitars. Thu, 28 Aug 2008 03:19:22 +0000 http://wordpress.org/?v=1.5.1-alpha by: Administrator http://tottinge.blogsome.com/2005/09/23/save-us-needless-abstractions/#comment-34 Sat, 24 Sep 2005 22:36:10 +0100 http://tottinge.blogsome.com/2005/09/23/save-us-needless-abstractions/#comment-34 Requirements would precede this. This is really about OOD, not requirements analysis. I've been increasingly leaning toward building a more concrete model (code or object stucture) and proceeding into abstractions (class structures) intentionally. When people dive into abstractions first, they often start adding facts instead of needed interfaces. I think it's a natural human tendency that just happens to be the wrong way to go about things. A friend of mine specialized in RAD. John told me that the secret to moving quickly is to not make mistakes. False starts and bad ideas take time to correct. I think that starting with an object diagram or collaboration diagram first is probably in line with that. With regards to hurry, I don't think you can think through a whole system at once anymore, but you have to kinda get a sense of what you are doing. You can work through the design in baby steps. It's a tough game. I've seen where looking ahead a bit invalidated technology decisions made early on, and cause some thrash. Not looking ahead would have been the bigger problem in that case. In other cases, people put a lot of diagrams together and base further design on them before they know if they're right. That can be a problem too. I don't think that thinking about the baby step you're about to take is a bad thing, even in a hurried setting. I wonder if it's not generally worse not to. Requirements would precede this. This is really about OOD, not requirements analysis. I’ve been increasingly leaning toward building a more concrete model (code or object stucture) and proceeding into abstractions (class structures) intentionally.

When people dive into abstractions first, they often start adding facts instead of needed interfaces. I think it’s a natural human tendency that just happens to be the wrong way to go about things.

A friend of mine specialized in RAD. John told me that the secret to moving quickly is to not make mistakes. False starts and bad ideas take time to correct. I think that starting with an object diagram or collaboration diagram first is probably in line with that.

With regards to hurry, I don’t think you can think through a whole system at once anymore, but you have to kinda get a sense of what you are doing. You can work through the design in baby steps.

It’s a tough game. I’ve seen where looking ahead a bit invalidated technology decisions made early on, and cause some thrash. Not looking ahead would have been the bigger problem in that case. In other cases, people put a lot of diagrams together and base further design on them before they know if they’re right. That can be a problem too.

I don’t think that thinking about the baby step you’re about to take is a bad thing, even in a hurried setting. I wonder if it’s not generally worse not to.

]]> by: Steve http://tottinge.blogsome.com/2005/09/23/save-us-needless-abstractions/#comment-33 Sat, 24 Sep 2005 00:34:09 +0100 http://tottinge.blogsome.com/2005/09/23/save-us-needless-abstractions/#comment-33 Where do the requirements play into this? Thinking out things are good but alot of the time, those who want what you are going to build for them, they like to see a demo. To achieve this, coding seems to start almost immediately. It seems that today, things are rush rush rush. Thought costs the company more money. However, in the long run, without thought, this could cost the company more money... Where do the requirements play into this?

Thinking out things are good but alot of the time, those who want what you are going to build for them, they like to see a demo. To achieve this, coding seems to start almost immediately.

It seems that today, things are rush rush rush. Thought costs the company more money. However, in the long run, without thought, this could cost the company more money…

]]>