robert young
Posts: 361
Nickname: funbunny
Registered: Sep, 2003
|
|
Re: Hiring the Rowing-Forward 30%
|
Posted: Apr 18, 2008 11:24 AM
|
|
> You keep suggesting that it somehow fundamentally changes
> the problems at hand. Specifically in this thread, you
> have suggested that it would relieve problems finding
> effective team members.
I didn't note closely the words "software tool company" when I began. To the extent that such systems are more like games than transactional systems, a distinction I did make at the beginning, then generating such software from a database is not likely. No question. Whether it still makes sense to gatekeep based on editor preference; I don't think so.
My point is, admittedly, to aver that the task of finding effective *coders* (worrying about whether a candidate prefers vi or emacs makes for a bad team member is the sort of near-sighted pettiness I never expected to hear from Mr. Eckel, by the way), for the class of systems I referenced (data based narrrowly, and explicitly not such as games construction), is simply the wrong question. For that class of problems, the coder mindset is what has brought us to bloatware. The data mindset provides a better answer to the question of getting folks rowing in the same direction.
Data folks, in my experience, just tend to be more productive and less worried about counting coup than coders. And, on other occasions, I have mentioned commercial and OS products which implement a database driven development methodology.
>
> > . So, yes this does answer the question.
>
> What you have described is exactly how I build systems.
> The only difference I detect is perhaps how the data gets
> s to the code that acts upon it. In my case, I use SQL.
> I'm not sure what you are suggesting to use.
>
> But in any event, getting the data with SQL is the easy
> part. It's what happens with the data that takes the most
> work.
>
> > > In addition, the mail merge example you give, beyond
> > being
> > > trivial and inadequate for the problem at hand, does
> it
> > > produce relational a model or some sort of
> hierarchical
> > or
> > > flat data?
> >
> > As stated, the variable data, whatever it may be, it
> > stored relationally, merged into the boilerplate stored
> in
> > however many versions, thence sent out via cron/word/db
> to
> > the many happy recipients.
>
> I never mentioned anything about merging. The recipients
> in question do not have emotions. You have failed to
> understand the scope of the problem. The formats are not
> templates. They are arbitrarily defined formats of
> machine readable data e.g. CSV, X12, ASN.1, JSON,
> fixed-length, delimited, XML. The variable data itself
> needs to be transformed.
Well, know you tell me?? Lack of clear specification leads to change control. In any case, I expect that the system referenced could do it. Word can do anything with text.
>
> In any event, what part of the solution you propose is
> relational? What would change from the way most people do
> things to the way you are suggesting. Your suggestion
> seems to be the within the most common and obvious
> approaches.
|
|
Previous Topic
