I think that actually building things that work is often an underrated activity in computer science. Recently I had the experience, and it has happened to me many times before, of telling someone about work I'd done and getting the response, "Well, that's just engineering..." It's application of known principles; it doesn't help us learn new things; it's not capital-S Science; it's not valuable; it's just engineering.
That kind of thinking may be especially easy to fall into in the more theoretical fields in which I usually work. It's the done thing to prove the existence of an algorithm, without even necessarily writing out the algorithm itself in explicit form, and then act like the problem is solved and it's time to move on to the next problem. One good reason to work that way is that as academics we're trying to build things that will last. If you write software code it can all be plowed under when the next version of Windows comes along and breaks backward compatibility. A theoretical result, if it's solid, can continue helping people forever. One bad reason to work that way is that engineers were the kids in high school giving wedgies to the theorists, and so us theorists want to be superior over them engineers now. I think far too often the "It's just engineering" view comes from that kind of motivation rather than the more serious academic considerations of what will help the most people over time.
Theoretical results on practical problems are of no real value until someone does actually go ahead and reduce them to practice, and if it's not us, who will it be? Do we really trust engineers' greasy paws on our work? Do we, and more importantly should we, really trust our own existence proofs when we can't see the results? Even in pure math there is a (controversial) point of view called constructivism which holds that if you can't actually make something, you're not allowed to say it exists. The pure-math constructivists' idea of what can be counted as actually making something is a trifle precious, but their hearts are certainly in the right place. I think there's a lot of validity to the "put up or shut up" line of thinking espoused by the mathematical constructivists; and in comp sci that comes down to building implementations.
Building implementations is really hard. It takes a lot of time from highly skilled people, especially if we're talking about implementations of cutting-edge theory. Someone who partakes in that activity has to have the engineer's skills - which aren't trivial even if theorists tend to discount them - and also the Scientist's skills on top of that. Giving yourself a wedgie may sound easy, but can you give yourself a surprise wedgie? Implementation is like that, and if you're not up to it, who are you to discount the work of the implementor who needs to be a theorist and engineer simultaneously? That makes another reason for theorists to pooh-pooh implementation work: they may say it's not worthwhile just because they can't do it. The unreachable grapes must be sour. But this isn't work we should leave for the engineers because we're too good for it. It's work we should claim for ourselves because we're the only ones good enough to do it.
Building implementations is really important. It's the ultimate reason for most of the theoretical work we do; for all that we may talk about the pure beauty of abstract thought, as long as I can have my theory papers rejected from theory venues for not having a motivating application, it'll be the case that the important purpose of this work is to serve the eventual creation of implementations. I also find some of these purported algorithmic existence proofs unconvincing, not only for the mathematical constructivists' philosophical reasons but also because they're just too complicated. If someone shows me a 40-page paper which supposedly says the problem can be solved in linear time, well, maybe I can understand the proof, but maybe I can't, and if I can't, I'm not sure that's entirely my own fault. When I have the software on my hard disk then I'll have a better sense of the whole thing being for real. Maybe we should say that you don't really know a scientific principle - like the existence of an algorithm - is even true in the first place until you've built something that uses it.
I don't just put implementations at a higher priority than most people do: I think I also have stronger implementation skills than most. I generally do build the things I say I can build. The downside of that is that maybe I end up looking like I "wasted" a lot of time on activities that are "just" engineering. I saw the same sort of thing, a hyper-valuation of theory over experiment, in another recent discussion where I showed some experimental results that were surprising (if not completely implausible) to another scientist, and he wasn't convinced by them, citing numerical rounding and various other points as possible sources of error. I said, well, it would be quite surprising if the theory and the experiment were both wrong, necessarily for completely different reasons, in such a way that the experimental data still ended up right where the theory said it should be. And he said, oh, I didn't know you had theory behind it, I apologise, I didn't mean to doubt your theory.
I could have been bullshitting him or myself about the theory. It would be easier to get the theory wrong than the experiment. The theory shouldn't necessarily be any more convincing; but once I said I had a math proof for it, it was beyond doubt. Okay, yes, if a mathematical proof is correct (and of course mine was) it can be said to be a stronger sort of proof than any real-world experiment... but at the same time, and as I said to him, I doubted the theory myself because the result was so weird. That was why I did the experiments in the first place, and it's because I did both the math and the experiments that I'm sure I'm right. The two things go together, and should go together.
I think my implementation skills are one of my strong points as a scientist; some of my results are better than some other people's results because mine are reduced to practice instead of being hypothetical. I try to play that up as one of my strong points when I'm looking for work, as (for instance) I am right now. Sometimes it doesn't impress people; in some quarters I still get the "but that's just engineering" response. Whether it's a good or a bad thing or not, though, it's at least a description of how I work. I'm a maker of things, and "maker of things" is for me a thing to be, not only a thing to do. This was one attribute that drew me to my eventual choice of Master's supervisor - she shared my focus on really building stuff. It's a rare attribute in CS theory, and I haven't had much chance to exercise it during my time at UofW. I'm hoping my next gig will be better in this respect.
Really making things happen, for real, in the real world, has worked well for me in computer science. It hasn't worked so well for me in more personal areas of my life and I wish I could apply this gift there. It feels like people are always trying to sell me (both literally, for money, and metaphorically, as things I should spend spoons on) self-improvement programs with claims of the form "If you do X, you'll be able to do Y!" No good. Fuck that shit. I don't want to hypothetically be able to do Y. That's a non-constructive existence proof. I want to really experience Y. That's implementation. Show me the results that aren't conditional on someone other than you. Make promises to me that will be your fault, not mine, if they don't come true. Take responsibility for the program actually running instead of crashing on my hardware. Implementation is not "just engineering," it's the point; your whole franchise isn't worth my subscription if I can't have a real expectation for it to make my goals happen. Build the thing.
Comments
gordp from 70.71.65.215 at Wed, 16 Jul 2008 05:38:41 +0000:
While talking about the possibility of me going to CS grad school, my manager commented that all the new trends in programming that are gaining traction in the industry (eg XP/agile, Ruby) come from the industry; the new trends coming from academia (eg Aspect Oriented Programming) really aren't getting very far. He suggested that if I want to actually affect the art of programming - and I do - academia isn't necessarily the place to do that.
This we-don't-need-code attitude is, as I see it, a big part of the wedge that keeps Computer Science and Software Development apart, much to the detriment of both parties.
Steve from 165.154.153.61 at Wed, 16 Jul 2008 06:41:38 +0000:
Modern history and present day is full of scientists, but the capital-S Scientists made something. That's why we know their names and not the others.
Matt from 129.97.79.144 at Wed, 16 Jul 2008 18:48:00 +0000:
gordp: I think that's really a different issue, and one to which I'm less sympathetic. When I hear the "academics haven't done much in the way of new programming languages" line (and I've heard it several times), I reach for my gun. There's a lot more to CS than programming languages. Programming languages are just a small peripheral area of CS and not one I'm particularly fond of; I'm not sure we need new programming languages at all; the new programming languages emanating from industry suck (though, I admit, the academic-borne ones suck too); and since the industrial folks write such crummy software in existing programming languages, why should they be trusted to create new ones? Do we measure the quality of an author on how many new and interesting words they've coined? No - there are authors famous for that, but it's by no means the defining quality of great authors. My impression of new work on programming languages - both in industry AND academia - is that an awful lot of it is aimed at the goal of making it possible for us to tolerate incompetent programmers, and I don't see that as a worthy goal. I'm not keen on the commodification of programming. When I said engineering was important I didn't mean to in any way include *incompetent* engineering.
kiwano from 142.166.20.180 at Thu, 17 Jul 2008 18:54:51 +0000:
Come now, constructivism (strictly speaking) isn't about actually constructing a mathematical object to demonstrate its existence, it's getting the materials to construct such things without having to invoke the Axiom of Choice. And that's actually kinda important now that we've found some results that are decidable only if you use AC.
gordp from 70.71.65.215 at Fri, 18 Jul 2008 03:04:46 +0000:
Matt: I was trying to talk about computer science in general, even though my examples were from programming languages and software engineering (your two favourite branches of computer science, I know).
As someone in industry, I get the impression that the software industry and the whole of CS-academia don't talk to each other nearly as much as they could.
Kygron from 68.32.31.113 at Mon, 21 Jul 2008 07:53:01 +0000:
You lost me when you switched to personal life. You say, "Take responsibility for the program actually running instead of crashing on my hardware," but I consider self improvement programs to be more of a "hardware" upgrade than a software program. For example: "Flex your muscles and the girls will flock to you" would crash on my hardware even though I've seen it work for others. It really implies a hardware upgrade to be performed at the local gym.
Human interactions are just too complex, you must either work with standardized hardware (mental hardware as well as physical), or write your own software. The former is generally considered "evil" and may be the cause of your strong reaction there.
May you be lucky enough to only require a simple port of any good advice!
Matt from 129.97.79.144 at Mon, 21 Jul 2008 17:32:17 +0000:
I don't see why that distinction should make a difference. If an enhancement is marketed on the claim "This will work for you!" and it doesn't, then it was marketed on a false claim. It doesn't matter whether it's a video card designed for a different bus, a piece of code written for a different operating system, or an educational product intended for a different person. Yes, we're all different (like PCs tend to be different from each other) but when you promote something on the claim that it'll be useful to others, you're responsible for the implicit claim that they are similar enough to you in whatever ways are relevant, for it to actually work. If there's an important predictable for it not to work, like "Windows XP only," then A. the marketer has a responsibility to mention that before the sale, and B. anyone recommending that product to an audience who can't use it, deserves no credit for "helping" because they haven't helped.
See also http://www.pbfcomics.com/?cid=PBF228-The_Masculator.jpg
Kygron from 75.185.114.112 at Tue, 22 Jul 2008 08:24:53 +0000:
Interesting comic, on the one hand, if someone's trying to make a buck at your expense, then yes, they haven't helped anything. On the other hand, the product that the character there recieved is likely the only way to achieve the advertised result. (Note the hole where the head should be.)
He went looking for an unrealistic solution so anything he got would have been a disappontment. Can you really blame the manufacturer for offering a reality-based solution? Or the marketer for getting the ad to the target audience? Who is responsible for the proper realistic interpretation of an unrealistic goal? This is why it's so much fun to hear jokes about a genie granting improperly phrased wishes, there's so many possible interpretations.
Matt from 216.59.227.31 at Tue, 22 Jul 2008 13:08:35 +0000:
<I>likely the only way to achieve the advertised result</I>
Now, that's the other thing about self-improvement programs... it's not unusual for them to be marketed (and do bear in mind that I mean more than just "sold for money" here) on the claim that not only "this is an effective way to achieve your goals" but "this is the ONLY way to achieve your goals." I figure that raises the bar even further in terms of the marketer's obligations.
Captain Smokeblower from 168.103.67.105 at Sat, 26 Jul 2008 04:10:03 +0000:
I come from the era of the "Charles Atlas" bully sand kicker advertisements in comic books (Yeah, and those X-ray glasses that let you see through girls' clothes.). In a purely capitalistic society everything marketed is marketed for the company's profit, not the customer's benefit. Only in that unrealistic world can I agree with Kygron about not blaming the manufacturer. The manufacturers use advertising to create the need for the product they have to sell. Have you ever considered why it's called a TARGET audience? You're the target. As to who is responsible for realistic interpretation of an unrealistic goal there has to be some oversight because the general public is vegetatively moronic when it comes to reality. (These people watch REALITY television.) It is to our condemnation, but advertising works. I once had to attend a Life Seminar. It was a thinly veiled series of speakers selling ways to get rich -- for only <fill in the blank> dollars. I realized the fastest way to get rich in America is charge money to teach people how to get rich. If one of them succeeds you can use their testimonial to get more people to give you money. "We can't say this if it weren't true." Why not? Everyone else on TV does. There must be some economic system between capitalism and socialism where people produce products people need and can use; where unnecessary products are not produced; where advertising is an explanation of the capabilities and uses for products without creating false needs for the product. Of course before that all the people on the B Ark must die. Thank goodness for individual cell phones.
![[RSS syndication file]](/i/rss.png){kind=small}
Axel from 65.94.186.39 at Mon, 14 Jul 2008 23:55:29 +0000:
As an artsy-fartsy guy I have to say the "just engineering" attitude runs deep. Where I was an undergraduate we considered engineers were scarcely human. But I have done translations with engineers and developed an enormous respect for them.
There is also a strangely symmetrical opposite attitude: when you ask people for a mathematical solution they send you a lump of code, and if you say you can't read the code they say, "But I sent you the solution." (I had this problem with Bogdan Krusinsky, he of the house system.)