""" 1. Mechanical. A good number of the things you mentioned fall into a
category I'll call mechnical (things aren't stored in a good
version control system, for example.)"""
I'd call this "procedural" rather than "mechanical", because "mechanical" implies that it can be automated away. Version control can't be completely automated because it requires humans to make pretty sophisticated decisions and take complex remediative actions. You can try to automate it to the greatest degree possible, and things like SVN and CVS do a good job at that, but doing version control still requires quite a bit of context, thought, and restraint even with the help that these tools provide. I suspect you could spend a lifetime just making this "easy" for a "lower class of developer" py putting a GUI on it and still fail. I'm not sure it's worth it for the marginal benefit of allowing them to do this "through the web". Of course you could allow people to version content (not code) in a less general way within a given application, but this is "content management" and not "content development", IMO.
""" 2. Trust. A lower class of programmer shouldn't be trusted to put
code on a live site. If something is live, it is important, and if
it is important, it should be done right. """
I'm suggesting that there is no such thing as a "lower class of programmer". Certainly, at least, an individual is not one of these permanently and forever. Whatever knowledge a "content developer" aka. "scripter" gains during his time as one of these kinds of people needs to continue to be useful when he "becomes a developer" (I use these terms not because I agree with them, BTW; I still don't believe there's a useful distinction... I think the distinction is actively harmful and pejorative! It's a caste system with all the falsehoods implied by one). There are people with varying skill levels, but their end goals are the same.
""" 3. Not valid use case. This "content developers" audience has a higher
cost than benefit, they're smart enough to learn the CA anyway,
there isn't a valid subset of functionality that will please them.
No such thing as a "content developer". """
+1 ;-) There is no "they". At least, rather than being a permanent actor in the system who is always assumed to be the same person, a person is only a "content developer" or "scripter" for some period of time until they gain enough knowledge to become a "real developer". (Again, these distinctions make me uncomfortable but I'll roll with it).
""" However, if others work on it, all I ask is that we keep an
open mind and not consider Zope 2 TTW "content development" as the
last word in the story. Let's work through the lessons learned and
see if there's still an opportunity. """
I have no ideas on this topic except that I reject the idea that there is a permanent underclass of programmers called "scripters" and "content developers". I'd suggest that if people want to "learn Zope", we work on better documentation rather than software.
We are all individuals
Posted byzopepaulat
2005-12-20 11:20 AM
FWIW, if what I'm describing is actually a "lower caste" (oomph, what a characterization), then I'm in that lower class. I'm describing something that I want, in reaction to something I don't want. If others don't want it, then I'm a caste of one, instead of a caste of thousands. [wink]
The caste idea is flawed
Posted byzopepaulat
2005-12-20 10:16 PM
Implying that advocating ease-of-use and convenience is advocating a caste system has a certain, err, chilling effect on the conversation. [wink]
If you look at tools like ArchGenXML, CPSSKins, and other work done separately by Rob Miller and Nuxeo on making AT/CPSSchema types TTW, you'll notice something crazy. People are attracted to these things.
It's like CLIs vs. GUIs in Linux. There's a class of people that think we are actively harming people by giving them a GUI. That what people really need is the "freedom" of a CLI and the full power it gives. After all, Emacs runs in terminal mode, and that's all that people need, right? [wink]
ArchGenXML, though incomplete in delivering its potential for convenience, is still a slam-dunk for this audience. It is so attractive, some people are willing to install a pig-slow Java app and confront UML. Imagine the task of developing the content schema in a drawing tool vs. throwing a Zope 3 component architecture book at them, and you're unlikely to get a response of: "I yearn for freedom, gimme the book".
You can try claiming that this audience doesn't actually want ease-of-use, nor convenience. They want the full power, just better documented. I'm not buying, it though. I think this audience will swap freedom for simplicity, 8 days a week and twice on Sunday.
I certainly don't buy the half-pregnant thing. I think Archetypes has shown that a subset of functionality, exhibited in a well-bounded, well-scoped way, is attractive to a group of people that just want to get a certain job done without drinking the whole kool-aid. So yes, I think there is very much a group of "scripter" that less interested in the whole enchilada.
I agree that it's still questionable whether doing something for this audience makes sense, or whether the cure is worse than the disease. However, if we don't even agree on the demand, it's a moot point.
I realize that this debate mimics other age-old debates. I'm sure when SQL arrived, people said that it was too confining and that you should just learn a language like cobol. And then, when QBE arrived, people said you should just suck it up and learn SQL. Heaven knows what they said when Access arrived. [wink]
As a note, nearly all of what I'm talking about is specific to the content management market. I'm not implying that generic web applications can be done in a non-component-programmer way. I'm intrigued by Martijn's followup which discusses domain-specific languages.
I don't think it's an underclass. There's a group of people who does not want to be *bothered* with the details of "low level programming" while they can still make valuable contributions to application development. This group of people will never grow into a full blown programmer, because they're just not interested in becoming one, but why would I want to lock them out while they can do valuable work?
Not all applications need to scale up, nor do they need to scale up right away. Getting some small feature in place right away is often more important than making sure it's scalable right from the start. I know that's your concern, Chris, and it's also one of mine, but it depends entirely on the circumstances whether it's an important one. Sometimes implemented badly but working *now* is sometimes more important than it being scalable but later. I just want to at least make this pattern of development more *maintainable* than it's been in the past. I think it should be possible to reduce the maintenance cost of their contribution while still allowing it.
I don't know exactly how big this group is and what they'd be satisfied with. I think there are different use cases involved and they have different solutions. UML code generation, ability to tweak HTML and simple logic, and some scripting functionalities may be answers to slightly different, though related, problems.
category I'll call mechnical (things aren't stored in a good
version control system, for example.)"""
I'd call this "procedural" rather than "mechanical", because "mechanical" implies that it can be automated away. Version control can't be completely automated because it requires humans to make pretty sophisticated decisions and take complex remediative actions. You can try to automate it to the greatest degree possible, and things like SVN and CVS do a good job at that, but doing version control still requires quite a bit of context, thought, and restraint even with the help that these tools provide. I suspect you could spend a lifetime just making this "easy" for a "lower class of developer" py putting a GUI on it and still fail. I'm not sure it's worth it for the marginal benefit of allowing them to do this "through the web". Of course you could allow people to version content (not code) in a less general way within a given application, but this is "content management" and not "content development", IMO.
""" 2. Trust. A lower class of programmer shouldn't be trusted to put
code on a live site. If something is live, it is important, and if
it is important, it should be done right. """
I'm suggesting that there is no such thing as a "lower class of programmer". Certainly, at least, an individual is not one of these permanently and forever. Whatever knowledge a "content developer" aka. "scripter" gains during his time as one of these kinds of people needs to continue to be useful when he "becomes a developer" (I use these terms not because I agree with them, BTW; I still don't believe there's a useful distinction... I think the distinction is actively harmful and pejorative! It's a caste system with all the falsehoods implied by one). There are people with varying skill levels, but their end goals are the same.
""" 3. Not valid use case. This "content developers" audience has a higher
cost than benefit, they're smart enough to learn the CA anyway,
there isn't a valid subset of functionality that will please them.
No such thing as a "content developer". """
+1 ;-) There is no "they". At least, rather than being a permanent actor in the system who is always assumed to be the same person, a person is only a "content developer" or "scripter" for some period of time until they gain enough knowledge to become a "real developer". (Again, these distinctions make me uncomfortable but I'll roll with it).
""" However, if others work on it, all I ask is that we keep an
open mind and not consider Zope 2 TTW "content development" as the
last word in the story. Let's work through the lessons learned and
see if there's still an opportunity. """
I have no ideas on this topic except that I reject the idea that there is a permanent underclass of programmers called "scripters" and "content developers". I'd suggest that if people want to "learn Zope", we work on better documentation rather than software.
If you look at tools like ArchGenXML, CPSSKins, and other work done separately by Rob Miller and Nuxeo on making AT/CPSSchema types TTW, you'll notice something crazy. People are attracted to these things.
It's like CLIs vs. GUIs in Linux. There's a class of people that think we are actively harming people by giving them a GUI. That what people really need is the "freedom" of a CLI and the full power it gives. After all, Emacs runs in terminal mode, and that's all that people need, right? [wink]
ArchGenXML, though incomplete in delivering its potential for convenience, is still a slam-dunk for this audience. It is so attractive, some people are willing to install a pig-slow Java app and confront UML. Imagine the task of developing the content schema in a drawing tool vs. throwing a Zope 3 component architecture book at them, and you're unlikely to get a response of: "I yearn for freedom, gimme the book".
You can try claiming that this audience doesn't actually want ease-of-use, nor convenience. They want the full power, just better documented. I'm not buying, it though. I think this audience will swap freedom for simplicity, 8 days a week and twice on Sunday.
I certainly don't buy the half-pregnant thing. I think Archetypes has shown that a subset of functionality, exhibited in a well-bounded, well-scoped way, is attractive to a group of people that just want to get a certain job done without drinking the whole kool-aid. So yes, I think there is very much a group of "scripter" that less interested in the whole enchilada.
I agree that it's still questionable whether doing something for this audience makes sense, or whether the cure is worse than the disease. However, if we don't even agree on the demand, it's a moot point.
I realize that this debate mimics other age-old debates. I'm sure when SQL arrived, people said that it was too confining and that you should just learn a language like cobol. And then, when QBE arrived, people said you should just suck it up and learn SQL. Heaven knows what they said when Access arrived. [wink]
As a note, nearly all of what I'm talking about is specific to the content management market. I'm not implying that generic web applications can be done in a non-component-programmer way. I'm intrigued by Martijn's followup which discusses domain-specific languages.
Replies to this comment
Not all applications need to scale up, nor do they need to scale up right away. Getting some small feature in place right away is often more important than making sure it's scalable right from the start. I know that's your concern, Chris, and it's also one of mine, but it depends entirely on the circumstances whether it's an important one. Sometimes implemented badly but working *now* is sometimes more important than it being scalable but later. I just want to at least make this pattern of development more *maintainable* than it's been in the past. I think it should be possible to reduce the maintenance cost of their contribution while still allowing it.
I don't know exactly how big this group is and what they'd be satisfied with. I think there are different use cases involved and they have different solutions. UML code generation, ability to tweak HTML and simple logic, and some scripting functionalities may be answers to slightly different, though related, problems.