We also know that certain kinds of literature can promote suicidal tendencies in minors. One of Goethe's classics showed this so well that the correlation ("The Werther Effect") was named after the protagonist in one of his books.
Shall we start maintaining a list of literature which minors are banned from purchasing as well because of the documented tendency for more suicides? It seems that the case for censorship of literature is probably stronger than the case for censorship of video games, but probably only because we have more information regarding history of literature and its effects on society.
Life imitates art. But if we value freedom of artistic expression, that is not sufficient grounds in my mind for censorship.
We prefer the second set. Those that we trust allow us to walk away, and trust that they know what they're doing, and will do it well. Now I see what my clients see in me. They make widgets. They don't make software. They don't want to make software. They don't want to learn how to make software, and they don't want to supervise someone else making software. They just don't want to get screwed -- especially the ones that have been screwed in the past. I get to convince them that any supplier can screw them, and taht they need to trust me. Those that let me earn that trust get everything they want and more, without any work or worry. With all due respect this doesn't sound like they are ceding business decisions to you. It sounds like you are essentially selling them a customized version of an off-the-shelf sort of product. This is sort of different.
Ok. In a previous post you mentioned web catalog software. In general, web catalog software is pretty straight-forward. However, where the real difficult issues come in have very little to do with software, building software, deciding what the software needs to do, etc. They are the social issues. I.e. a web catalog is a catalog. It requires content management processes to be in place on the *human* level. This means content review, etc. And in fact, none of these things (except the actual data entry) need to even be done at a computer. This level (the business process level) is where the customer needs to be in control.
As I sometimes say, "If the customer was always right, I would have a lot less work." The customer is not always right and they don't need to be in control of the technical end. However the customer is the expert on the customer's needs and the person with the ultimate responsibility and hence a) the customer needs to be in charge of their own business processes and b) the software needs to support rather than define those processes. From what you say, I am guessing that you don't entirely disagree.
BTW, regarding performance-- I believe that support two of the largest instances of LedgerSMB. The largest is actually a cash register environment. We have found that in general, we get a *lot* better performance with each release despite doing a lot of things that you would think would degrade performance (for example relying more and more on CPAN). One of my recent changes reduced running time from 30 minutes to 1.8 seconds.
Basically you have to apply through the legal department, but once it is approved (basically showing that you are not undermining Microsoft with your business), you get basically back your ability to keep the development you do on your own time.
There is a pretty convincing body of evidence which suggests that the "Werther" effect is in fact real. I.e. that reading about a sympathetic character who commits suicide makes one more likely to do the same. So yes, I would say that reading does invoke the same effect.
I think there is a pretty clear set of scientific knowledge which suggests that reading portrayals of suicide, particularly in literature, makes one more likely to contemplate suicide. May be should start banning all sorts of subjects in books...
What about books? What did the author say about the copycat suicides? "My...friends thought that they must transform poetry into reality, imitate a novel like this in real life and, in any case, shoot themselves; and what occurred at first among a few took place later among the general public..."
The fact is-- we all know or should know that there is an effect. The real question is whether we are prepared to ban books, video games, movies, etc. in order to prevent poetry and art from influencing people. I think that at least here in the US, that would be a blatent attack on the Constitution.
My argument is one of how much harm reduction we actually expect from regulating violent video games, movies, theater plays etc. (Why should violence in a movie version of MacBeth be any different than a play?) vs the cost to our civil liberties.
We all know that art work can cause people to do destructive things. I am not even questioning that. For example, there was the rash of suicides in Germany linked to the publication of Die Leiden des Jungen Werther in the 19th century. But nobody suggests that regulating the sale of depressing literature to minors is a good idea.
In the cases of restricting driving, etc, owning guns, etc.... 1) There is a *clear* question of harm which is easily quantified and analyzed. 2) The restrictions are a lot less intrusive to civil liberties in general than controlling portrayals of violence in art and exposure of children to these (whatever you do, don't read The Song of Roland to a minor!) 3) I think the question of adult mags is an interesting one. The argument is that children shouldn't be exposed to sexuality first by things outside a parent's control. However, a lot of parents are afraid that if they talk about these sorts of things with their children that they will start being sexually active. However, this generally results in the teens learning about sex from other teens. In general, I think it would almost be better if pornography wasn't regulated because it would provide less of a false sense of security to parents who want to hide their heads in the sand.
However violence in art (games, movies, books) doesn't provide an argument along the lines of pornography. Unlike sexuality, children are confronted at an early age with questions of physical violence and how one deals with the impulse to be violent. This comes from parents even before a child knows what a video game is, so.....
Well, in a lot of ways this is how open source works. However with open source, the gains for the developer are more obvious, more direct, and all-round better. Crowdsourcing is an attempt to do open source development for closed projects and while it will have some limited success, it is not that important.
First, kids are pretty resourceful. I have been brewing beer since I was 16. Probably legally at first, since it was in my parents' house with their permission (BTW, I am not and have never been much of a drinker, but I *do* enjoy brewing). Later when I moved away to college it was suddenly illegal. Did I stop though? Why should I? It is not like there is any law in my state against selling brewing equipment to people under 21 (and it is strange to me that it would have been legal for me as a minor but illegal for a few years as an adult).
I have never known a kid who couldn't have figured out how to buy tobacco either.
So have you ever known a kid who couldn't get his hands on booze or smokes if he/she wanted? What do you expect to accomplish here?
The only argument for alcohol laws regarding minors is that it allows an additional charge of minor in possession to be made for underage persons with such beverages. Are you prepared to do the same with video games?
Secondly restricting sales of video games (which are nonconsumable) is very different than restricting sales of alcoholic beverages. If my friend gets his parents to buy some violent video game, he gains more by sharing it with me than by using it all himself. This is very different than alcohol where the good in question is *gone* after it is used. So how do you expect to enforce this? Make it a crime for kids to play such video games with eachother (just as with alcohol)?
Hence this isn't just a matter of parental control. The only way such a thing can work is if there are *legal consequences* to exposing minors to such material which makes it a case far more like the question of pornography than like alcohol. Do you really want our society to have crimes like "exposing a minor to violent depictions in movies?"
Finally, I would say that neurological information gleaned from these reports is important, but you can't get from it any information which suggests that there is a sufficient social harm to abridge the freedoms we hold dear in ways that would actually make such measures have any real teeth.
I never said the research shouldn't be done. I think research should always be done.
But you asked about lobbying which concerns how that research is used to steer public policy. The public policy questions are different. Research is only a small part of that discussion and that is how it should be.
One of the real problems that you have is that violent crime rates (robbery, murder, rape, etc) have been dropping for a long time. There is a real question of whether or why one should be overly worried about violent video games/movies/etc. when we are generally doing pretty well as a society. At some point we as a society have to be able to choose freedom to have some slightly self-destructive habits if we are to remain a free society.
At some point the video game violence issue is the same as whether we as a country should have laws banning homosexual activity, and whether we should ban alcohol consumption. Do we want freedom or an authoritarian state?
Note that alcohol consumption contributes to a *lot* more harm every year than video games and I support the right to consume alcohol.
Responsible non-competes only attempt to enforce trade secret protection. For example, you may not go to work for a company which competes with us for a period of six months after your employment here if your role at that company would be likely to cause you to use trade secrets you had access to with us.
Note the conditional. Absent the conditional, it is a problem. With the conditional, it is *just* a form of trade secret protection.
I think that once a project is abandoned, it should no longer qualify for trade secret protection. However, this does not mean that one should, say, work on a new technology and then take what you built for your employer in order to go into business for yourself unless it is pretty clearly cancelled first. There are some basic ethics involved:-)
Sure, but then have the contract appropriately scoped.
For example, my reading of the non-compete at Microsoft was simple: If you were an Office developer, and you went to Sun to add MS OfficeOpenXML to StarOffice, then that would be a problem. If OTOH, you went to work at IBM building new features for the Linux kernel that would be OK. If the contract distinguishes between using your employer's trade secrets and working for the competition that is one thing. If it doesn't then it is a form of servitude.
When I worked at Microsoft, the contract had a clause to that effect. I did sign it because it had another clause which gave me ways to protect work I did on my own time-- If there are options for moonlighting, you can negotiate a right to start your own business and keep all the IP of that business to yourself.
My business has no trade secrets aside from customer lists, etc. Hence we get by just with trade secret protections (no poaching customer, and the like). Non-competes are more or less useless for us.
BTW, one thing my business actively does is provide ideas we have in development to third party businesses free of charge. THe reasoning is: in these cases we are involved in core communities of open source projects, and our competition helps us more than it hurts (because they are downstream of us and this helps us reach more customers).
Having seen then non-competes at Microsoft, Intel, etc. they are appropriately scoped to avoid leakage of trade secrets, but not attrition of employees. Small companies should be doing this (i.e. use non-competes to keep someone from taking your trade secrets and going to work using them at a competitor) but usually they are really just interested in keeping *you.*
I believe that non-competes, used appropriately, do more good than harm. However, they are very often abused and on the whole that may not be the case.
Neither of us find specs particularly useful. I don't find UML diagrams terribly useful (actually I generate UML diagrams *from* my work rather than do them first). However, a lot of stuff happens via a proposal process which ensures that various businesses in the community get to weigh in about how to ensure that a feature works well for everyone. Yes it costs the customer a little more in the short run but a *lot* less once others are helping to maintain the code.
I would be interested in seeing where things are for both projects in 5 years.
See, I disagree with your last point. For as long as software developers aren't software engineers, then you have two things. First, you have programmers who can't see three steps ahead. Second, you have designers who have no idea how things are actually implemented. Third, you have wasted energy passing between the two. What I meant was that I can out-design most programmers out there. However, I have met a lot of developers who can out-code me. There is a deceptively large gap between those skill sets. I have been burned by assuming that there was less of a gap than there is. I am guessing that you are in the latter camp.
Nothing I'm doing is difficult. Forty million if statements, basic iteration, rare recursion, and a whole lot of simple code. The trick is only knowing where everything is. IMO, nearly every application which relies on if statements for its structure is a maintenance nightmare.
And now, they call you in for a mystery meeting -- my all time favourite; it means free business. So you walk in two hours later, and they want a feature. They ask only two things: when, and how much. I take thirty seconds of silence, and I give them an answer. I know every line of code, so I know what's involved. And I've done shit before, so I know how long it takes. After all, they're asking for something as simple as an isolated feature, or a wide-ranging integrated cross-system entanglement. Either way, it's either something I've done a dozen times, or something that I planned they might want down the line. But do you understand what, exactly, they need? 99% of my time in requirements engineering is actually just talking with the customer about what they need. Then we have meetings with developers and plan out how to get there. Generally speaking I do give them a date and a time (and I inflate both with the idea that I can then come in under budget and ahead of schedule). Sometimes projects slip because problems are more complex than they appear but that is not the typical case.
Smaller projects ("I want price matrixes to update automatically when invoices are sent") also go the way you describe.
What I offer, as a service provider, is the ability to make 98% of the business decisions on behalf of my client. That gives them the piece of mind, and the time, to not worry about the project. I would never trust such decisions to someone outside my business. I might ask advice, but....
I'm just really tired of people not knowing their own products. I bought a douve -- a bed quilt. I was looking for a 100% white goose down version. Every single box/bag says "white goose down douve". I asked the sales people: "is it 100% goose down?" every one of them "yes, it is". Then I got to rip open the bag, and show them the new materials tag on the product that says "contains an amount of feathers not in excess of legal limits". They not only didn't know, they actually lied to me. The difference is dollars, and that's just fraudulent. Now, LedgerSMB is in a funny spot here-- we forked from an application which could easily be nominated "Worst web app ever" and after working with the codebase or over 3 years, I still find unpleasant surprises. Hence we are pulling out as much as we can in favor of CPAN modules, and moving everything over to a much cleaner architecture. Hence it is now far easier for everyone to work with the application and we are getting more community contributions.
IMO, at least with PostgreSQL, the planning overhead in a query drowns out anything going on in DBI. I move a lot of things to stored procedures try to move from running thousands of queries to only running a hundred or so. I suppose if you are using a database manager with a less sophisticated planner like MySQL, it might be an issue, but then you are limited to doing trivial things (and my comment was appropriately scoped to non-trivial operations).
For example, if you are inserting records one by one (one row per statement), your planning overhead will be around 30 ms per row. If you leave autocommit on in your db handle, you are issuing additional commit statements after each record.
If you consolidate those into one statement as in insert into x (a) values ('b'), ('c'), ('d'), ('e'),...., you cut down both on the COMMIT statements which force disk writes *and* on the planning overhead. So optimization of SQL is *far* more critical than what you are using to connect.
BTW, we use Simple::CGI (it does a lot less than CGI.pm, and is less buggy). CGI is not a templating language. Even CGI.pm is not a templating language-- it is procedural framework for building code. This seems to be what you prefer but you do lose something in the process.
LedgerSMB is something like 85k lines of code (trunk) not including documentation that is not inline in the code. Consequently, while speed is something we care about, long-term maintainability of the codebase is more critical. Hence we are moving everything to a system where we only have one language per file. HTML, Javascript, Perl, and SQL are all largely contained in separate files. (2 files have both Perl and SQL in them, but that is as many as we expect to have in the long-run.)
This means that changing colors is no problem- you edit a CSS file. Any web dev can do that. No problem. You don't even have to know Perl! Want to add Javascript? You need to know a little about TT, but we have it all documented. You don't have to know Perl. In fact long-term the required Perl knowledge to customize the application is going to drop a great deal. This is all based on appropriately layering things.
My question to you, as one who uses LSMB with the limitations that you've listed above, is very simple. I refuse, and prohibit my developers from using third-party modules for integrated features. Obviously, LWP, DBI, ImageMagick, something PDF, and other extensions of the core don't count. I'm talking about integrated business features because that's my industry. If my industry were database management, then I wouldn't let them use DBI either. But in my world, database performance is not something on which I need a strangle-hold. I have no idea why you would be worried about the database performance and DBI. If you are doing anything non-trivial, DBI is not going to cause you any headaches. Case in point-- most of our interactions with the db tend to use PostgreSQL for only a tiny portion of the total execution time of the page load.
Similarly, has anyone ever told you that premature optimization is the root of all evil?
My question is, when you reach something that LSMB can't do -- perhaps your cash register example is one -- what do you tell your clients? Do you say something to the effect of "sorry, that's not possible" or "we'll have to rebuild everything from scratch"? or do you say something like "it can't be done properly, but we can bolt-on this work-around"? Ok, there are very few cases I will tell customers I wont do something. These generally involve cases where accounting logic would be compromised and don't have anything to do with the modules used. For example, if you asked me to port to MySQL, I would probably say no. If you asked me to port to Oracle, I might take you up on the challenge, however.
I have run into cases in the past where things are not designed to work a certain way. In those cases, I do a gap analysis, come up with a solution, and write it. The cash register is one example. My customer wanted pole display support and this is a web application. So I created an additional UDP connection for sending commands to the pole display. So my answer is always:
"Yes it can be done. Here is how much it will cost you." Obviously I can't get to an estimate until I have done basic requirements engineering and have a roadmap to get there.
Of course, I might say "No that is impossible" if someone wanted me to hook wings made of wax, wood, and bird feathers, and make it fly around the room by flapping its wings.... But that is more than a little outside the scope of the project.
But I've been doing this for a long while, and I've become pretty adept at seeing the future (from my clients' perspective). I just need my developers to believe me when I say that writing their own code is going to be better when they need to change it. "it's impossible" can't ever be the answer that I give to my clients. Sure. And you don't have to tell your customers you are rewriting chunks of code, but you do need to set their expectations accordingly.
BTW, we are using TT because we use extremely complex data structures and TT handles those well. Consider a data structure which contains all the information needed on an invoice, for example. Works great.
After reading your post through, I doubt we are in industries which are that different.
See, yours is the perspective that I get from everyone -- including my developers. But that's just it. I do have a package that huge, and flexible, and makes things much easier, and supports dozens of structures in any sort of layout I want. I call it "the developer".
I too am a developer. Writing a routine that traverses a perl structure is five lines of code -- ten if you want to go nuts. Any formatting can be shoved in and shoved out as quickly as a developer can type. Whether it's a bunch of tabs and line breaks to indent a tree, or td's and tr's to produce a table, it's an extra line or two of code. Making it dynamic is just adding id's and onclick's to the td's. So our ten lines becomes twenty. That's it.
Ok, IMO, this is a maintenance nightmare. BTW, traversing Perl structures can be tricky. I do have to do it on occasion to process various things (for example, ensure that certain objects are turned into strings prior to template processing) and yes, one can do recursion in 10 lines, but there will be corner cases that don't get handled properly. Perl being Perl, you can probably do it in fewer lines, but will drastically reduce readability in the process.
My clients don't don't know what they want up-front. Quite frankly, they have no freakin' clue what they want. And in my opinion, they shouldn't. My clients sell, widgets, manufacture widgets, dig tunnels, sell services, organize events and provide advice. None of them build web-sites nor design software. That's why they call me.
If that is what your attitude is towards development, it is easy to see why these projects sometimes go amiss. It is entirely certain to me that your customers do know what they want up-front, even if it is just "we know how we want this to help us." (Customers who don't know that don't tend to spend money.) From that point, it is your job to help the customer understand *how* you and they together are going to help them accomplish their goals. After all, you have to help the customer accomplish their goals-- you cant do it for them.
Most of my customer's don't initially care how I accomplish what they want, but they do understand that they have to be a part of the solution and that we will work together. I can't think of any major jobs we do where specifications get agreed upon up-front. Instead we send analysts (even if it is myself) to their location where we document how they do things and what needs to be changed. It is still requirements engineering but we generally drive it. And we communicate what we are doing with our customers.
However, it seems like you are asking developers to code without a roadmap or a list of technical requirements. So you can't be unhappy when things slip because those requirements change.
Back to reality, changing a web-site's colours is not worth worrying about. I can re-skin the entire site's layout too and not be worried at all. But that's because I program things properly in the first place. The principles are simple: the client will change everything that they can see, and nothing that they can't see. Their business objectives won't change (within the scope of the project).
So let me see-- you are equating changing a CSS file to changing the output format of recursing through a data structure. A better analogy would be to change a table in a web site from HTML to, say.ODS Yeah, they are both SGML-based and may both be XML (depending on the web site), but that is no less trivial than changing from a pure Perl dump to valid DHTML.
I see it like a car. I build them a car. It needs to do what a car does, and every car does the same thing. I build a good car. Then my client comes and doesn't like the steering wheel, so I show them wheel options. Then they don't like the body, so we talk and I build them a bigger body -- and swap out the chassis as needed. Then I s
Greener as in from Evergreen State? No. THat is the school I went to. We are/were not all hippies, you know:-)
Greener as in have solar on my house? YES Kudos to you.
Greener as in bad stereotype that says I should have Dreds and smell like patchuli (sp?) NO. Never had dreds myself. Didn't smell like patchouli much either....
Nor do I do any drugs Alcohol and caffeine are about my limit there:-) And even there I have to be careful or else my ability to program drops. Most drugs don't mix well with strenuous mental activity (even caffeine can be overdone here).
I would contact The Advice PC Group. They are based in Puyallup but work throughout Western Washington.
Ok, we use TT for LSMB pretty extensively in 1.3. Yes, there are some potential issues performance-wise, but those are actually ram-scarcity issues. BTW, LedgerSMB has portions which are very latency-sensitive (cash register support, for example) and we do everything we can to make those fly speed-wise. Generally speaking, however, in our case it is db access which is the bottleneck. We use it to generate HTML, LaTeX, CSV, Excel, and OpenDocument files.
Part of the problem is that you are going to pay in performance for flexibility. Next time someone says "oh, we just want one simple modification-- can you output in Excel?" you can do that and it will be simple. Otherwise it will be a headache.
The point is that you should have known and should have been informed this was web-based from the start, and if you didn't it is either you or your customer who is at fault here. Not your programmer. You can't blame developers for not building in requirements that were not given to them.
Slashdot Mirror
We also know that certain kinds of literature can promote suicidal tendencies in minors. One of Goethe's classics showed this so well that the correlation ("The Werther Effect") was named after the protagonist in one of his books.
Shall we start maintaining a list of literature which minors are banned from purchasing as well because of the documented tendency for more suicides? It seems that the case for censorship of literature is probably stronger than the case for censorship of video games, but probably only because we have more information regarding history of literature and its effects on society.
Life imitates art. But if we value freedom of artistic expression, that is not sufficient grounds in my mind for censorship.
Ok. In a previous post you mentioned web catalog software. In general, web catalog software is pretty straight-forward. However, where the real difficult issues come in have very little to do with software, building software, deciding what the software needs to do, etc. They are the social issues. I.e. a web catalog is a catalog. It requires content management processes to be in place on the *human* level. This means content review, etc. And in fact, none of these things (except the actual data entry) need to even be done at a computer. This level (the business process level) is where the customer needs to be in control.
As I sometimes say, "If the customer was always right, I would have a lot less work." The customer is not always right and they don't need to be in control of the technical end. However the customer is the expert on the customer's needs and the person with the ultimate responsibility and hence a) the customer needs to be in charge of their own business processes and b) the software needs to support rather than define those processes. From what you say, I am guessing that you don't entirely disagree.
BTW, regarding performance-- I believe that support two of the largest instances of LedgerSMB. The largest is actually a cash register environment. We have found that in general, we get a *lot* better performance with each release despite doing a lot of things that you would think would degrade performance (for example relying more and more on CPAN). One of my recent changes reduced running time from 30 minutes to 1.8 seconds.
Basically you have to apply through the legal department, but once it is approved (basically showing that you are not undermining Microsoft with your business), you get basically back your ability to keep the development you do on your own time.
There is a pretty convincing body of evidence which suggests that the "Werther" effect is in fact real. I.e. that reading about a sympathetic character who commits suicide makes one more likely to do the same. So yes, I would say that reading does invoke the same effect.
Here is an interesting link for you: http://pespmc1.vub.ac.be/Conf/MemePap/Marsden.html
I think there is a pretty clear set of scientific knowledge which suggests that reading portrayals of suicide, particularly in literature, makes one more likely to contemplate suicide. May be should start banning all sorts of subjects in books...
What about books? What did the author say about the copycat suicides? "My...friends thought that they must transform poetry into reality, imitate a novel like this in real life and, in any case, shoot themselves; and what occurred at first among a few took place later among the general public..."
The fact is-- we all know or should know that there is an effect. The real question is whether we are prepared to ban books, video games, movies, etc. in order to prevent poetry and art from influencing people. I think that at least here in the US, that would be a blatent attack on the Constitution.
My argument is one of how much harm reduction we actually expect from regulating violent video games, movies, theater plays etc. (Why should violence in a movie version of MacBeth be any different than a play?) vs the cost to our civil liberties.
We all know that art work can cause people to do destructive things. I am not even questioning that. For example, there was the rash of suicides in Germany linked to the publication of Die Leiden des Jungen Werther in the 19th century. But nobody suggests that regulating the sale of depressing literature to minors is a good idea.
In the cases of restricting driving, etc, owning guns, etc....
1) There is a *clear* question of harm which is easily quantified and analyzed.
2) The restrictions are a lot less intrusive to civil liberties in general than controlling portrayals of violence in art and exposure of children to these (whatever you do, don't read The Song of Roland to a minor!)
3) I think the question of adult mags is an interesting one. The argument is that children shouldn't be exposed to sexuality first by things outside a parent's control. However, a lot of parents are afraid that if they talk about these sorts of things with their children that they will start being sexually active. However, this generally results in the teens learning about sex from other teens. In general, I think it would almost be better if pornography wasn't regulated because it would provide less of a false sense of security to parents who want to hide their heads in the sand.
However violence in art (games, movies, books) doesn't provide an argument along the lines of pornography. Unlike sexuality, children are confronted at an early age with questions of physical violence and how one deals with the impulse to be violent. This comes from parents even before a child knows what a video game is, so.....
Well, in a lot of ways this is how open source works. However with open source, the gains for the developer are more obvious, more direct, and all-round better. Crowdsourcing is an attempt to do open source development for closed projects and while it will have some limited success, it is not that important.
First, kids are pretty resourceful. I have been brewing beer since I was 16. Probably legally at first, since it was in my parents' house with their permission (BTW, I am not and have never been much of a drinker, but I *do* enjoy brewing). Later when I moved away to college it was suddenly illegal. Did I stop though? Why should I? It is not like there is any law in my state against selling brewing equipment to people under 21 (and it is strange to me that it would have been legal for me as a minor but illegal for a few years as an adult).
I have never known a kid who couldn't have figured out how to buy tobacco either.
So have you ever known a kid who couldn't get his hands on booze or smokes if he/she wanted? What do you expect to accomplish here?
The only argument for alcohol laws regarding minors is that it allows an additional charge of minor in possession to be made for underage persons with such beverages. Are you prepared to do the same with video games?
Secondly restricting sales of video games (which are nonconsumable) is very different than restricting sales of alcoholic beverages. If my friend gets his parents to buy some violent video game, he gains more by sharing it with me than by using it all himself. This is very different than alcohol where the good in question is *gone* after it is used. So how do you expect to enforce this? Make it a crime for kids to play such video games with eachother (just as with alcohol)?
Hence this isn't just a matter of parental control. The only way such a thing can work is if there are *legal consequences* to exposing minors to such material which makes it a case far more like the question of pornography than like alcohol. Do you really want our society to have crimes like "exposing a minor to violent depictions in movies?"
Finally, I would say that neurological information gleaned from these reports is important, but you can't get from it any information which suggests that there is a sufficient social harm to abridge the freedoms we hold dear in ways that would actually make such measures have any real teeth.
I never said the research shouldn't be done. I think research should always be done.
But you asked about lobbying which concerns how that research is used to steer public policy. The public policy questions are different. Research is only a small part of that discussion and that is how it should be.
One of the real problems that you have is that violent crime rates (robbery, murder, rape, etc) have been dropping for a long time. There is a real question of whether or why one should be overly worried about violent video games/movies/etc. when we are generally doing pretty well as a society. At some point we as a society have to be able to choose freedom to have some slightly self-destructive habits if we are to remain a free society.
At some point the video game violence issue is the same as whether we as a country should have laws banning homosexual activity, and whether we should ban alcohol consumption. Do we want freedom or an authoritarian state?
Note that alcohol consumption contributes to a *lot* more harm every year than video games and I support the right to consume alcohol.
Responsible non-competes only attempt to enforce trade secret protection. For example, you may not go to work for a company which competes with us for a period of six months after your employment here if your role at that company would be likely to cause you to use trade secrets you had access to with us.
Note the conditional. Absent the conditional, it is a problem. With the conditional, it is *just* a form of trade secret protection.
I think that once a project is abandoned, it should no longer qualify for trade secret protection. However, this does not mean that one should, say, work on a new technology and then take what you built for your employer in order to go into business for yourself unless it is pretty clearly cancelled first. There are some basic ethics involved :-)
Sure, but then have the contract appropriately scoped.
For example, my reading of the non-compete at Microsoft was simple: If you were an Office developer, and you went to Sun to add MS OfficeOpenXML to StarOffice, then that would be a problem. If OTOH, you went to work at IBM building new features for the Linux kernel that would be OK. If the contract distinguishes between using your employer's trade secrets and working for the competition that is one thing. If it doesn't then it is a form of servitude.
When I worked at Microsoft, the contract had a clause to that effect. I did sign it because it had another clause which gave me ways to protect work I did on my own time-- If there are options for moonlighting, you can negotiate a right to start your own business and keep all the IP of that business to yourself.
My business has no trade secrets aside from customer lists, etc. Hence we get by just with trade secret protections (no poaching customer, and the like). Non-competes are more or less useless for us.
BTW, one thing my business actively does is provide ideas we have in development to third party businesses free of charge. THe reasoning is: in these cases we are involved in core communities of open source projects, and our competition helps us more than it hurts (because they are downstream of us and this helps us reach more customers).
Having seen then non-competes at Microsoft, Intel, etc. they are appropriately scoped to avoid leakage of trade secrets, but not attrition of employees. Small companies should be doing this (i.e. use non-competes to keep someone from taking your trade secrets and going to work using them at a competitor) but usually they are really just interested in keeping *you.*
I believe that non-competes, used appropriately, do more good than harm. However, they are very often abused and on the whole that may not be the case.
There are a number of other similarities.
Neither of us find specs particularly useful. I don't find UML diagrams terribly useful (actually I generate UML diagrams *from* my work rather than do them first). However, a lot of stuff happens via a proposal process which ensures that various businesses in the community get to weigh in about how to ensure that a feature works well for everyone. Yes it costs the customer a little more in the short run but a *lot* less once others are helping to maintain the code.
I would be interested in seeing where things are for both projects in 5 years.
Smaller projects ("I want price matrixes to update automatically when invoices are sent") also go the way you describe. What I offer, as a service provider, is the ability to make 98% of the business decisions on behalf of my client. That gives them the piece of mind, and the time, to not worry about the project. I would never trust such decisions to someone outside my business. I might ask advice, but.... I'm just really tired of people not knowing their own products. I bought a douve -- a bed quilt. I was looking for a 100% white goose down version. Every single box/bag says "white goose down douve". I asked the sales people: "is it 100% goose down?" every one of them "yes, it is". Then I got to rip open the bag, and show them the new materials tag on the product that says "contains an amount of feathers not in excess of legal limits". They not only didn't know, they actually lied to me. The difference is dollars, and that's just fraudulent. Now, LedgerSMB is in a funny spot here-- we forked from an application which could easily be nominated "Worst web app ever" and after working with the codebase or over 3 years, I still find unpleasant surprises. Hence we are pulling out as much as we can in favor of CPAN modules, and moving everything over to a much cleaner architecture. Hence it is now far easier for everyone to work with the application and we are getting more community contributions.
IMO, at least with PostgreSQL, the planning overhead in a query drowns out anything going on in DBI. I move a lot of things to stored procedures try to move from running thousands of queries to only running a hundred or so. I suppose if you are using a database manager with a less sophisticated planner like MySQL, it might be an issue, but then you are limited to doing trivial things (and my comment was appropriately scoped to non-trivial operations).
...., you cut down both on the COMMIT statements which force disk writes *and* on the planning overhead. So optimization of SQL is *far* more critical than what you are using to connect.
For example, if you are inserting records one by one (one row per statement), your planning overhead will be around 30 ms per row. If you leave autocommit on in your db handle, you are issuing additional commit statements after each record.
If you consolidate those into one statement as in insert into x (a) values ('b'), ('c'), ('d'), ('e'),
BTW, we use Simple::CGI (it does a lot less than CGI.pm, and is less buggy). CGI is not a templating language. Even CGI.pm is not a templating language-- it is procedural framework for building code. This seems to be what you prefer but you do lose something in the process.
LedgerSMB is something like 85k lines of code (trunk) not including documentation that is not inline in the code. Consequently, while speed is something we care about, long-term maintainability of the codebase is more critical. Hence we are moving everything to a system where we only have one language per file. HTML, Javascript, Perl, and SQL are all largely contained in separate files. (2 files have both Perl and SQL in them, but that is as many as we expect to have in the long-run.)
This means that changing colors is no problem- you edit a CSS file. Any web dev can do that. No problem. You don't even have to know Perl!
Want to add Javascript? You need to know a little about TT, but we have it all documented. You don't have to know Perl. In fact long-term the required Perl knowledge to customize the application is going to drop a great deal. This is all based on appropriately layering things.
Similarly, has anyone ever told you that premature optimization is the root of all evil? My question is, when you reach something that LSMB can't do -- perhaps your cash register example is one -- what do you tell your clients? Do you say something to the effect of "sorry, that's not possible" or "we'll have to rebuild everything from scratch"? or do you say something like "it can't be done properly, but we can bolt-on this work-around"? Ok, there are very few cases I will tell customers I wont do something. These generally involve cases where accounting logic would be compromised and don't have anything to do with the modules used. For example, if you asked me to port to MySQL, I would probably say no. If you asked me to port to Oracle, I might take you up on the challenge, however.
I have run into cases in the past where things are not designed to work a certain way. In those cases, I do a gap analysis, come up with a solution, and write it. The cash register is one example. My customer wanted pole display support and this is a web application. So I created an additional UDP connection for sending commands to the pole display. So my answer is always:
"Yes it can be done. Here is how much it will cost you." Obviously I can't get to an estimate until I have done basic requirements engineering and have a roadmap to get there.
Of course, I might say "No that is impossible" if someone wanted me to hook wings made of wax, wood, and bird feathers, and make it fly around the room by flapping its wings.... But that is more than a little outside the scope of the project. But I've been doing this for a long while, and I've become pretty adept at seeing the future (from my clients' perspective). I just need my developers to believe me when I say that writing their own code is going to be better when they need to change it. "it's impossible" can't ever be the answer that I give to my clients. Sure. And you don't have to tell your customers you are rewriting chunks of code, but you do need to set their expectations accordingly.
BTW, we are using TT because we use extremely complex data structures and TT handles those well. Consider a data structure which contains all the information needed on an invoice, for example. Works great.
See, yours is the perspective that I get from everyone -- including my developers. But that's just it. I do have a package that huge, and flexible, and makes things much easier, and supports dozens of structures in any sort of layout I want. I call it "the developer".
I too am a developer. Writing a routine that traverses a perl structure is five lines of code -- ten if you want to go nuts. Any formatting can be shoved in and shoved out as quickly as a developer can type. Whether it's a bunch of tabs and line breaks to indent a tree, or td's and tr's to produce a table, it's an extra line or two of code. Making it dynamic is just adding id's and onclick's to the td's. So our ten lines becomes twenty. That's it.
Ok, IMO, this is a maintenance nightmare. BTW, traversing Perl structures can be tricky. I do have to do it on occasion to process various things (for example, ensure that certain objects are turned into strings prior to template processing) and yes, one can do recursion in 10 lines, but there will be corner cases that don't get handled properly. Perl being Perl, you can probably do it in fewer lines, but will drastically reduce readability in the process.
My clients don't don't know what they want up-front. Quite frankly, they have no freakin' clue what they want. And in my opinion, they shouldn't. My clients sell, widgets, manufacture widgets, dig tunnels, sell services, organize events and provide advice. None of them build web-sites nor design software. That's why they call me.
If that is what your attitude is towards development, it is easy to see why these projects sometimes go amiss. It is entirely certain to me that your customers do know what they want up-front, even if it is just "we know how we want this to help us." (Customers who don't know that don't tend to spend money.) From that point, it is your job to help the customer understand *how* you and they together are going to help them accomplish their goals. After all, you have to help the customer accomplish their goals-- you cant do it for them.
Most of my customer's don't initially care how I accomplish what they want, but they do understand that they have to be a part of the solution and that we will work together. I can't think of any major jobs we do where specifications get agreed upon up-front. Instead we send analysts (even if it is myself) to their location where we document how they do things and what needs to be changed. It is still requirements engineering but we generally drive it. And we communicate what we are doing with our customers.
However, it seems like you are asking developers to code without a roadmap or a list of technical requirements. So you can't be unhappy when things slip because those requirements change.
Back to reality, changing a web-site's colours is not worth worrying about. I can re-skin the entire site's layout too and not be worried at all. But that's because I program things properly in the first place. The principles are simple: the client will change everything that they can see, and nothing that they can't see. Their business objectives won't change (within the scope of the project).
So let me see-- you are equating changing a CSS file to changing the output format of recursing through a data structure. A better analogy would be to change a table in a web site from HTML to, say .ODS Yeah, they are both SGML-based and may both be XML (depending on the web site), but that is no less trivial than changing from a pure Perl dump to valid DHTML.
I see it like a car. I build them a car. It needs to do what a car does, and every car does the same thing. I build a good car. Then my client comes and doesn't like the steering wheel, so I show them wheel options. Then they don't like the body, so we talk and I build them a bigger body -- and swap out the chassis as needed. Then I s
I would contact The Advice PC Group. They are based in Puyallup but work throughout Western Washington.
Ok, we use TT for LSMB pretty extensively in 1.3. Yes, there are some potential issues performance-wise, but those are actually ram-scarcity issues. BTW, LedgerSMB has portions which are very latency-sensitive (cash register support, for example) and we do everything we can to make those fly speed-wise. Generally speaking, however, in our case it is db access which is the bottleneck. We use it to generate HTML, LaTeX, CSV, Excel, and OpenDocument files.
Part of the problem is that you are going to pay in performance for flexibility. Next time someone says "oh, we just want one simple modification-- can you output in Excel?" you can do that and it will be simple. Otherwise it will be a headache.
The point is that you should have known and should have been informed this was web-based from the start, and if you didn't it is either you or your customer who is at fault here. Not your programmer. You can't blame developers for not building in requirements that were not given to them.