How much do we really need geeks?

July 28, 2010 at 4:07 pm 9 comments

That’s the lead question in this article from the Revolution (RunRev.com) newsletter.  The arguments being made (especially about computer scientists not caring about users) are similar to those that Brian Dorn heard from graphics designers, in explaining why they didn’t take computer science courses.  I found fascinating the first argument, that elegance and “best practice” have no place in the actual workplace.

There is a vast gulf between theoretical, “best practice” programming, as taught on many degree courses, and actual programming in the workplace. You may be taught that a certain thing should be done in such a way, or you should never use method xyz, but in practice you may be given a deadline of a week to produce something that “should” take three weeks, and you have to find a way to produce it. Quick and dirty hacks become more explicable in these circumstances. Then there is the difference between producing something satisfying to mind of a programmer, and something that an end user can actually use and understand. It may be the smart and logical way to do it, but if the end user can’t grasp it, its not especially valuable.

via Computer Science in the Workplace | revUp 97.

Entry filed under: Uncategorized. Tags: , .

Education (even kindergarten) matters What’s Wrong With the American University System – The Atlantic

9 Comments Add your own

  • 1. Greg Wilson  |  July 28, 2010 at 4:18 pm

    Harking back to an earlier topic, most scientific programmers start and end with this attitude: elegance be damned, they just need the answer so they can get back to doing the science they actually care about. One computational scientist (a mechanical engineer by training) once asked me, “Do you have a course on cutting corners? Because that’s mostly what I do.”

    Reply
  • 2. Garth  |  July 29, 2010 at 10:57 am

    I used to work at a software outfit that wrote police software: 911 operator interface, police car laptop interface, etc. My friend in the next cubicle was the “need this fixed immediately or the customer is going to be pissed” programmer. He was also the “quickly add a feature to the existing product” programmer. The company was not interested in style or clean coding, they just wanted it done yesterday and it need to sort of work. It was ugly. Most of the products they marketed were coded like that. Different programmers writing different pieces at different times all hacked together. Every now and then he would try to go clean up the code for a modification he had written months previously but it rarely happened. The general impression I got (not being a programmer myself) was to be a good programmer at the commercial level involved being quick, adaptable and very smart. Neat, organized and using methods taught in a programming class were not on the list. A methodical, well trained programmer straight out of college would not have survived. The business model was based on speed and no major bugs on delivery. I teach high school programming. I stress planning, commenting the code, using good variable names, modularization, and more planning. If I were truly preparing my students for the commercial programming world (using the admittedly limited experience I have) I would teach “hack it quickly, sell it, fix it later”.

    Reply
  • 3. Mark Guzdial  |  July 29, 2010 at 11:52 am

    I wonder what empirical evidence we have that shows the quick-hack method is worse than the elegant, well-designed engineering model. Sure, there are lots of failed software engineering projects. Can we really show that they failed because it was lots of quick hacks vs. well-engineered software? I’ve heard of some failures from some fairly established software development houses. I’m wondering about Greg’s answer to his scientists — how can we show them that the “course on cutting corners” isn’t “good enough”?

    Reply
  • 4. Matthew Hertz  |  July 29, 2010 at 3:22 pm

    I think that Brian Dorn’s comment has some truth to it, but is ultimately about the failure of the teacher and not about teaching. There is little value to just telling classes “do not do this” when things are really done. Whenever possible, I try to say “do not do this because…” and explain why we usually do not do it a certain way. (Assuming they pay attention) Students then have an idea of what the best practice is, but also an idea of what happens when they cut that corner. We can still demand/grade for best practices, but also give them enough information so they can evaluate when “cutting corners” is reasonable.

    Reply
    • 5. Mark Guzdial  |  July 29, 2010 at 4:59 pm

      Matthew, I didn’t quote Brian Dorn in this piece. I was quoting an article from the Revolution newsletter, that I said reminded me of Brian Dorn’s studies, particularly in his CHI 2010 paper on end-user programmers’ strategies. Which quote were you referencing?

      Reply
      • 6. Matthew Hertz  |  July 29, 2010 at 5:47 pm

        I am apparently unability to read. In trying to do 10 thing and talk to both my students, the quoted paragraph was attributed to Brian Dorn and not the newsletter. My argument about the limits of teaching “best practices” versus actual practices still stands,.

        Reply
  • 7. Eric Baumgartner  |  July 29, 2010 at 4:48 pm

    Hi Mark,

    There’s an interesting 2003 book (R. Glass, Facts and Fallacies of Software Engineering) that tries to distill of lot of prior research into a bunch of aphorisms for development. There isn’t a clear cut answer to your question, but three related points stand out (related citations in the book).

    1. Good design matters more than good code. So if you’re hacking within a solid overall design, you might be ok. If you cut corners on the initial design, though, you’re hosed down the road.

    2. Maintenance costs typically run 40-80% of overall lifecycle costs; enhancements typically run 60% of maintenance costs. This is usually cited to argue for better code up front to reduce maintenance and is probably the most obvious response to “quick and dirty” demand. Yet…

    3. More modern engineering practices led to more maintenance (at least in one study). Counterintuitive, but the ultimate claim was that better code reduced repair/debugging, but more than made up for it in enhancement requests (since the code design made enhancements so much easier). I’m not sure I buy the claim, since you also end up with a more capable product, but perhaps it ties in to the simplicity ethos that outfits like 37signals espouse.

    Reply
  • 8. Mark Miller  |  August 3, 2010 at 4:53 pm

    I agree that good design is the most important aspect (aside from getting the requirements right). It’s what we’re taught in SE, and I’d say from my experience it’s true. Unfortunately good design is usually only valued by the engineers, and even then sometimes the engineers don’t care. From what I’ve been hearing over the last ten years, good design is increasingly not even valued much by software developers.

    There are two culprits in this that I have seen. One is that the executives and/or customers of software products don’t understand the importance of this. With rare exceptions, the important thing to them is the deliverable, not the design process, nor the code that went into making it. In fact, if the engineers “spend too much” time on the design, as opposed to coding, the management/customers get nervous, “Why isn’t the product getting built?” In hindsight I wish they would’ve applied Sun Tzu’s insight to software development: “The war is won before it is fought.”

    More often than not the computer is “just a box” to them (to quote an old IBM ad). The engineer’s job is seen as “make the box do what we want”. They don’t care how it gets done. It could be written in spaghetti code for all they care, so long as it runs according to spec. when the first version is delivered.

    Ironically all that usually gets considered is the up-front development cost. It’s all driven by the financing, not the engineering. The up-front cost of developing a product from scratch is considered the “capital expense”, The maintenance is considered a “cost of business” expense, and is accounted for differently. From my experience corporate customers will accommodate the expense of maintaining a poorly designed piece of software so long as the “capital expense” is kept to something they consider reasonable (ie. relatively small). In the line of business I was in, IT services, this was largely driven by the number of competitive bids on a project. Each supplier had to try to outbid the other to win the contract. This necessarily makes the budget for the project “as small as possible”. Engineers have to work within those confines, or else the supplier eats the loss.

    Getting back to the question about good design, it’s been my experience that good up front design matters in terms of the amount of time spent on maintenance. A piece of software that’s designed poorly can be made to work on the first iteration with minimal bugs. A caveat about a small team size is probably necessary for this to work. It can probably be completed more quickly this way, because the developer can think of the process of writing the code as more or less linear. Unfortunately this tends to justify the bad design. To the customer, they say to themselves, “I saved money,” all the while they’re ignoring the size of the maintenance costs on the tail end. The problem comes when the software needs to be updated. There are some caveats to this as well. Sometimes “to really do it up right” requires more skill than a team of developers really has, and so a nice, but not-so-great design is all they can muster, if they’re even given the opportunity to do it. I’ve had the experience that in order to do this I ended up having to throw out some functionality for a product, because I couldn’t get the old features to work in my nicer design. This didn’t work out so well, as I discovered that some customers liked the older features.

    I have heard in the past that there are courses in CS programs that emphasize “getting it done quickly”. I remember hearing about one at C.U. Boulder years ago, which tried to teach practical on-the-job skills in this regard. I also remember a couple ACM programming contests I was involved in where solving the most problems in the least amount of time was emphasized. I didn’t like them very much.

    Overall it’s the realities I’ve described above that ultimately caused me to become despondent about the profession I had entered into, and caused me to search for some reality in computing that was better than what I had seen practiced. It’s been a long process, because I was ensconced in this mindset for many years. I hope it leads somewhere.

    Reply
    • 9. Mark Miller  |  September 5, 2010 at 4:33 pm

      After going through SICP for a while I realized that something I said above is probably not the best idea, though it might be, given what developers have to use out in the IT work world. I said:

      “In hindsight I wish they would’ve applied Sun Tzu’s insight to software development: ‘The war is won before it is fought.'”

      First of all I misquoted Sun Tzu. What he said was, “Every battle is won before it is ever fought.” A distinction there between “battle” and “war”. I apologize for the warrior mentality, but it seemed appropriate to the subject in a tongue-in-cheek sort of way.

      An idea I’ve seen Abelson and Sussman introduce in the old SICP lecture video series (available online) is that a better design strategy is “wishful thinking”. In other words, talk about the properties you want in the system before they’re implemented, and delay decisions about how to implement them for as long as possible. Abelson addressed the issue of “What about planning it all out ahead of time?” He said anyone who believes in that strategy hasn’t designed a very large system. So I see I haven’t. A popular idea in the industry is that the design document becomes outdated the moment it’s written. This is probably why. I’ve found them helpful nevertheless, because they at least provide some sense of direction.

      Other ideas introduced in SICP were that in the design of any system the important things to consider are:

      What are the primitives?

      What are the means of combination?

      What are the means of abstraction?

      It sounds like these questions have more to do with the implementation.

      In any case, I wanted to add this note, because I did not want to leave the impression that I was an authority who knew what I was talking about. In the realm of IT practice I do, but when it comes to good design I don’t, yet.

      In the realm of IT as it exists today I’d say that designing as much in advance as possible is practically a requirement, because of the development tools we are given to use. So many decisions have to be made early in the process, or else you get a program that won’t compile. Richard Gabriel talked about this in “The Art of Lisp & Writing”. It sounds like this requirement could actually be destructive to the goal of building well-designed systems. The problem may not be related to strict typing. It has more to do with early binding, which Gabriel said forces developers to work with a “publishing medium” rather than an authoring medium. Certainly at some point in the IT workplace you want to get to a point of “publishing”, but the reality of writing, or engineering, is that once you’ve created something, you realize new things about your idea, and so some rethinking/redesign is always necessary. And so a “drafting” medium would be more appropriate in the early stages.

      Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Trackback this post  |  Subscribe to the comments via RSS Feed


Enter your email address to follow this blog and receive notifications of new posts by email.

Join 9,005 other followers

Feeds

Recent Posts

Blog Stats

  • 1,878,617 hits
July 2010
M T W T F S S
 1234
567891011
12131415161718
19202122232425
262728293031  

CS Teaching Tips


%d bloggers like this: