On Fri, Feb 08, 2002 at 10:50:25AM -0500, Matt Cashner wrote: > On (02/08/02 16:38), [EMAIL PROTECTED] wrote: > > > So when I speak > > about design, it is not about code in any way, but for example a statement > > that threading model xyz should be used. > > i've always found that this is better determined by getting in there and just > trying stuff. > > > We cannot just say that data > > access should be serializable because that is not detailed enough. So if > > you want to influence rfcs and design, you would have to take part in the > > discussions. Or there will be a spec where the implementation is not > > given but a lot of constraints. > > i dont want a given implementation. i want a feature spec. the implemntation > will be fairly easily derived from the requested features. you cant design > the office space until you know the shape of the building.
No. The problem is too big for that. You dont find algorithms by trying out all code blocks, do you? Implementation with just a feature spec as you call it might be easy for you, but then you would have to be _very_ good. > > The code itself > > is certainly something that needs a lot of time, energy and motivation. > > But the real problems are solved before that. > > actually, you cant know the really tricky problems until you're coding. > ideal design often breaks down in the course of the reality of coding. You can. That is what makes a good software architect (or how you want to call it). This is why you actually do analysis and design, to find out what and how to do it. Implementation is rather easy compared to that. Finding errors during the implementation or even the test phase always results in more work than finding the errors during design. In the ideal world implementation shows no surprises, all important decision are done yet. About the reality of coding, of course you can't predict bugs in libraries and stuff like that. But usually you know what you can do. Roughly said you find out how to do it in the design phase, you specify what you want when analysing the problem and in the end you test and maintain. There are several software life cycle models but the direction analysis -> design -> implementation -> tests exists in all of them. > > > What I would like to know however is if you really would volunteer to just > > produce code. Only some people like that and I dont know wether you do > > (i'd guess you dont, but you seemed to say that .. ). > > dont worry about what i like. i volunteered didnt i? i'm more interested > in the year or more of conversation finaly resulting in code. > > i have no stock or personal/work drama wrapped up in the object layer. it > just sounds like an interesting problem to hack on. > > in lieu of consensus, i'm probably just going to play with some stuff on > my own. you guys will probably hate it but oh well :) you need to think about it first and find out how to do it. no code needed for that. maybe you just try finding the really tricky problems before you start coding. it needs practice and there are several techniques etc. meant to help people with that (for example UML models, objects life cycles, ...). It might be no fun in the beginnning, but it enables you to work on bigger projects. And to actually succeed. Torvald
