<WARNING...! Loooong post, incoming...!> Man, Lief...! It's like you lined 'em up, just for me to shoot 'em down...! So I'll start with YOU... LOL...! But before that, I'll say I've REALLY enjoyed this thread...! (This discussion goes back even further than the "Age-Old Debate" on using the primary cycle...;-) But where I see all the points of disagreement, I mainly see where there is an awful lot of overlap in what appears to be contradictory statements. In fact, not to mention any names (Brad ;-), but I sometimes see more contradiction in one individual's posts, than in the apparently conflicting viewpoints. I wish time permitted me to comment on each post. Generally I agree with what everyone said, with just a few exceptions. All that to say...: ...Now, Leif.. If you're saying there's no room for creativity in programming, then I disagree with you completely. I don't think that's what you're saying, however, and I don't REALLY believe that you think that. I think you're just trying to point out the problems in the industry. ===> That problem is stated, precisely, by the comparison of coding to art, rather than craft. I'll drive that point home, very easily, by asking the question: How many of you have a Picasso or Van Gogh hanging in your livingroom...?!? IOW, programmers are pricing themselves out of the market, IMV. At some point, tools will replace a lot of programmers, for this reason. Been going on for a long time now (Synon, Lansa, BCD, MRC, etc.) but the process is only gonna be speeded up unless programmers achieve greater levels of effectiveness. Hardware/software costs are going down.. personnel costs are going up... Another point of disagreement I have is where Brad commented on the need for strong individualism, but then layed out a set of coding standards that are stricter than anything I've ever seen, except in my own shop...! And if those coding standards are written down anyplace, then Brad's got me beat. ;D The analogy about comparing program to creating art clearly illustrates one of the fundamental problems in the industry. I think that the analogy is not so close as it appears, however. IMHO, this analogy is a closer parallel to the process of programming: Programming is a lot more like writing, than painting. I s'pose there could be some debate about this, but I'm working on the assumption that most folks understand their job isn't to create, in and of itself, but to support the company they work for. There is a fair bit of confusion about this, but I think most would understand this point. Anybody who's fought back a downturn in the company knows...: It doesn't matter if you're producing Picasso's of programming. If the company loses money for too many years, yer outofa job...! Period. Company cultures differ, and the IT dept is can be more closely aligned with the business, or less. That balance is achieved because those both within and without the IT dept want either a closer alignment or an IT department that is more aloof. But there is a direct connection between what IT does, and how the company functions, no matter what the view... Looking at producing code is a false point to start from, then, in this view. The question is how to produce systems. And I think it is generally recognized that systems are produced, not for their own sake, but to help a company make a profit (even in not-for-profits). To help companies provide better goods and services to their customers. I think this is actually what a lot of this here debate is about, but it's not phrased in that way. But in this view, IT departments are a service organization within the company. So in this view, even if you're not working for an ISV, the users of the software are "customers". (Of course, that's not always easy to see it that way, especially when the users don't view themselves as customers.) But I'm not even gonna attempt to address the issue of creating systems, but only the issue of creating programs. I think programming is VERY much like writing. ===> Except that you don't see a whole lot of debate about how to form each and ever letter of the alphabet that forms a story, like you do in the programming world. There is an assumption that if you want to gain some efficiency in the programming world, you are necessarily talking about resorting to stamping out programs like an assembly line produces cars. Nothing further from the truth, in my mind (although I don't know, for sure, about Leif). What I'm talking about is not spending so much time creating a work of art, and not spending a whole lot of time making each single letter in a story as artistic as possible. Because that doesn't provide any value-add to the company you work for. I'm NOT TALKING ABOUT ELIMINATING CREATIVITY. Can I make that any clearer...? Maybe by extending the analogy... IMV, the creativity just needs to be redirected. Not so much put into the forming of each letter that goes into the story, or even in each word and paragraph (a la CASE tools). The creativity is in understanding the subject matter, organizing the story, and phrasing it so it makes sense and gets some points across. In programming, the code represents the tiniest tip of the iceberg of creativity that goes into solving the business problem. The bulk of the creativity goes into understanding what the user needs (when frequently that is the exact opposite of what they tell you...;-). The creativity goes in making balanced judgments... One of the most difficult classes of decisions that go into coding involve when is going quicker just gonna result in cut corners, and when it doesn't. When it's better to try new techniques, and when it's better to clone what you know has worked. Determining in what ways this job is similar to what you've done in the past, and what ways it isn't. Seen folks re-invent the wheel, plenty of times, just to try out some new techniques. Also seen folks take a square peg and jam it into a round whole, just because the last job called for a square peg. Some people say that what I'm talking about takes the creativity and the challenge out of programming. Funny... After 23 years of doing this, I still find plenty of challenge. How FAST can I get this job done **five-nines correctly**. That's still a challenge for me. I'm sure some people think that when I refer to the fact of the Law of 80/20 Rule, that doesn't apply to coding. Well, it certainly does.. At all times... I need the code to be five-nines, but how I get it there requires judicious use of the 80/20 rule. That is, if I'm going to accomplish the task in any kind of time-frame, anyway. So when I talk about 2 people working on a program, it's in order to get the story out, without resorting to a rough draft or two. Get it out in "one take", as they say in the flicks. Get the program written or changed with one or two compiles, and have it execute the way I intended, in one run. Doesn't always happen that way, that's for sure, but it isn't rare either. I'm talking hundreds of lines of new code or changes (just in case you're thinking sure, I do that all the time, myself, without anyone helping). In my experience, this is easier when you have someone watching for typos, or logic errors, or reversed logic. Not only that, but if you have someone who knows more about writing, the best way to teach that to another is by way of example. I'm not even going to emphasize the points about turnover, maintenance, and all that. These facts exist, in most shops. So when people ask about spending double the time to produce a program: First of all, it may not halve the time, but it may. It should reduce the time involved, if it's done correctly. This is not at all easy, and can in fact take double the time of one person working on a program if it's not done correctly. Like anything.. depends on HOW it's done. Second of all, how much value do you put on bringing those less-experience on par with the more-experienced? How much value do you put on cross-training? If you don't have any turnover or vacations, you might not have these issues. If you have a great excess of staff, you might not have these issues. If you have a great excess of budget, you can make sure your programmers don't walk down the street. But even in these rare cases, there are benefits of cross-training and training apprentices. (Also works between two masters of the 400, because nobody I know of knows everything about a 400.) At one time, I placed an extremely high value on how technical a programmer was. But in my experience, I've found that frequently a less technical person can see the issues around how well the program actually solves a problem the business has, than a more technical person. The best solutions that I've found are simple, yet elegant, code that solves a business problem, in the most cost-effective manner. I ***know*** we've ALL seen examples where absolutely great code, not only *didn't* solve a user's problems, but ***made it harder for a user to do their jobs***. Or they spend more money on a program than the original problem they're facing costs... Most people wouldn't consider these successful projects. (I cite the InfoCenter as one such example... I'm sure the code behind the project was extremely good.) If you think, well, *I* don't do that, then I wonder if you're as objective about your work as your users would be. *I* know *I* DO do that, when I'm not careful. And if you've been in the biz for less time than I have, then the laws of probability dictate that you are more likely to make this mistake, on any given project, than I am. Not a rule, but that's the probability. (Didn't get to visit the age/experience thread on RPG-L, but that probably sums up my views on the subject.) If writing GREAT software was THAT easy (or at least software the users are not constantly complaining about ;-)... Well, then everyone could do it. You wouldn't see a factor of 10 to 20 times, between the top and the bottom. I think this becomes a fair bit easier when things compile the first or second time, and work as planned the first or second run. Things start clicking into place. You address more problems with simpler solutions. If done properly, this can become easier to do, because two eyes are better than one. Some things are as simple as that, at least in concept. IM(maybe NS)HO. jt | -----Original Message----- | From: firstname.lastname@example.org | [mailto:email@example.com]On Behalf Of Leif Svalgaard | Sent: Monday, December 10, 2001 12:49 AM | To: firstname.lastname@example.org | Subject: Re: Two persons per product" | | | From: Brad Jensen <email@example.com> | | Brad and Steve (and the many others that will jump on this | over the next few hours), I have heard all these arguments | before (pride of ownership, creativeness, etc) and they are | *precisely* what is wrong with our "profession". I'll compare | (some will say that I can't) programming a large system as | akin to producing the engineering blueprints of a major | building. In order that the blueprints be understandable | and hence useful now and 20 years from now, there is | very little room for "creativity" and "personal style". If | the original creator of a portion of the blueprint leaves | the project another engineer can and should be able | to complete the piece without having to start from | scratch. The pride in your work comes not from being | original but from executing your job in a professional | manner. This argument can go on and on and on.
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.