Tony ([info]quikchange) wrote,
@ 2005-11-08 23:47:00
Previous Entry  Add to memories!  Tell a Friend!  Next Entry
Current mood: crushed
Current music:No Doubt - End It On This
Entry tags:anecdote, business, technology

Some personal revelations inspired by tonight's BayCHI talk
Eight years ago I discovered Visual Basic 3. At the time I had only ever used simple imperative languages like GW BASIC and PC Logo so the ability to create user interfaces via direct manipulation was both impressive and addictive. About a year later, after having tried to build a customer and sales management system and failing miserably, I became disenchanted with VB and swore off it forever.

Tonight at BayCHI I listened to Alan Cooper talk about the death march and how to avoid it. One of his points was that, in addition to the nontechnical aid provided by product management and executive direction, good software development requires 3 different technical roles that are generally muddled together, to disastrous effect, in most software companies. For the purpose of explanation he assigned them labels: programmers write code to be shipped by adhering to well-defined process and are concerned by the minutiae of production-quality software but need to be good at solving complex problems that arise in the process of crafting code; design engineers create the detailed architecture that the programmers will use to build the software but need to be good at writing throwaway code fast so they can tackle the tough conceptual issues via rapid prototyping; interaction designers envision and describe the user experience that the software is eventually going to provide so they need to be able to translate between the otherwise mutually incomprehensible jargon employed by geeks and suits.

If you're wondering into which camp you fall, I think an effective way to determine this is based upon your programming language of choice. Interaction designers will tend to prefer visual programming (like Flash or VB) or RAD for creating quick mock-ups of the user experience; design engineers will tend to prefer weakly-typed esoteric languages (Like SmallTalk, Lisp and Ruby) for iteratively prototyping solutions to challenging problems; programmers will tend to prefer strongly typed mainstream languages (like C++). Alternately, consider which of these goals is closest to your heart: end-user satisfaction and productivity enhancement (Interaction designer), a clean design based upon the best technology (design engineer), or releasing software that is standards-compliant, reliable, efficient and secure (programmer).

But what does this mean for the executives running software companies? Well, they need to avoid mixing up the 3 distinct roles so that people do what they excel in and each task has sufficient brainpower devoted to it. Furthermore, the software ideas should begin with the interaction designers and end end up as code produced by the programmers with critical guidance from the design engineers midway through.

Anyway, when I heard Alan elucidate this division among the technical staff I suddenly understood why I've felt such an identity crisis ever since I decided to study computer science and become a computer programmer eight years ago. My heart has never been in the code; I'm really cut out to be an interaction designer but am also fairly well suited to being a design engineer. The reason I became fascinated by computer programming back in high school is because I was enthralled by the prospects of how computer software could improve our lives and implicitly recognized that writing code was the only way to make these dreams a reality. Later on I noticed the distinction between programming and design engineering. Realizing that I was more interested in and adept at the latter, I gravitated toward what was then termed software architecture and almost ended up studying it in grad school. But about a year ago I began to creep back toward my original spark of interest in interaction design, which is what compelled me to jettison my plans for grad school in favour of a position on VMware's UI team where I now spend time in all 3 aforementioned roles of software development.

What I'd like to do is eventually increase the amount of time I spend on interaction design instead of programming. Unfortunately, Alan's encouragement to lavish more resources upon interaction design has not yet been taken to heart by most software companies. The obvious solution would be to start my own company. Philip Greenspun actually presented an idea for a startup tonight but it involves hardware so the Cooper model of running a successful software company can't be applied to it easily.

It's all very exciting. But I'm the sort of person who could have multiple heart-attacks while biking through rush-hour traffic with rabid pit-bulls snapping at my heels and then say it was an exciting trip... So what do I know?

Update: after a long IM discussion with [info]adamspitz I am now convinced that the best software developers are those who understand and enjoy all 3 roles.


(Post a new comment)


[info]kinthelt
2005-11-09 02:46 pm UTC (link)
What about people who use weakly-typed mainstream languages (like C), or strongly-typed non-mainstream languages (like ML)?

(Reply to this)(Thread)

[info]quikchange
2005-11-09 02:58 pm UTC (link)
Some people's natural inclinations straddle more than one role. It's like being ambidextrous. Given what I know about you, I suspect you are primarily a design engineer (since I know you love solving theoretical problems) but with reasonable aptitude and interest for programming (since you do write good production code and care about security).

(Reply to this)(Parent)

[info]ramou
2005-11-09 03:22 pm UTC (link)
Let's replace design engineer with software engineer, Alan Cooper is a name I vaguely recognize, and I seem to think he should have been using the proper terminology. It is, in fact, the software engineers who want the strongly typed languages *because* they promote such a crisp, clean design. It's the programmers who want the weakly typed so they can write their fast and dirty caffiene induced code...

Furthermore, Software Engineers distinguish between the architecture and the design, but do both. The architecture captures high level design decisions and should be readily approachable to stakeholders outside the comp. geek. pool. It should also include an evolving requirements artifact. The design itself is more of a means for the Software Engineers to communicate with each other and the programmers, and to determine at an early stage what works, what can go wrong where, and how to support adaptability (and maybe a few other odds and sods). Given a clear design, programmers can go write the encapsulated modules following the decent specifications provided in the design.

The interaction designers need their own special skillset, which we call HCI (Human Computer Interaction), which covers the development of these interfaces, as well as an understanding of what makes a good user interface. Sadly, HCI has been assigned as the girlie part of comp. sci. in many schools... However, it turns out that your best bet on what you call "interaction designers" is to have software engineers with talent for HCI.

Spending too much in the way of resources on interaction design is a waste. All the effort is spent on deciding how best to present stuff to the user, but this research is being done and standardised. It's ignorant to encourage people to continually re-invent the wheel. What they should do is to encourage their interaction designers to read up on HCI and see what is current, then they can do a good job, feel satisfied with their work, and formally back up their UI decisions.

Look into HCI research, I'll try to post some links as I come across it... although my favorite HCI person may be a bit mad at me at the moment...

(Reply to this)(Thread)
Replying to your comments in stack order...
[info]quikchange
2005-11-09 03:52 pm UTC (link)
I've already been looking into HCI research - what do you think the CHI in BayCHI stands for...?

It is true that more research is being done in the field of CHI (or HCI if you prefer) but it's a very nascant field so there's still a lot we don't understand. And interaction designers are generally already on top of the latest research in the area since this is what they do for a living!

Yes, it's sad that the user experience was neglected in favour of algorithm design (and later software architecture) for so long at both industrial and educational institutions but the relevant organizations have finally begun to give it the importance it deserves. After all, an efficient, maintainable and secure program is virtually useless if nobody can figure out how to use the damn thing.

Your 2nd paragraph captures some of what Cooper said about the need for a blueprint created by the design engineers to fulfil the user-experience needs set out by the interaction designers and which the programmers can follow as they construct the software that ships. However, specifications are only a small (and not particularly useful) component of this blueprint; the important stuff is the architecture - both high-level and low-level (which I think you labelled design).

Your first paragraph is actually a common misconception that arose from the ironic origins of the 2 methodologies. The "Rational" process for building good software was invented by the design engineers but is actually best applied to the process of programming while the agile approaches (like XP) were invented by the programmers but are actually bets suited to design engineering. Cooper covered this in his talk but I didn't reproduce everything he said in my original entry.

(Reply to this)(Parent)(Thread)
Re: Replying to your comments in stack order...
[info]ramou
2005-11-09 04:17 pm UTC (link)

Your first paragraph is actually a common misconception that arose from the ironic origins of the 2 methodologies. The "Rational" process for building good software was invented by the design engineers but is actually best applied to the process of programming while the agile approaches (like XP) were invented by the programmers but are actually bets suited to design engineering. Cooper covered this in his talk but I didn't reproduce everything he said in my original entry.


Well, I've spoken with some of the people who developed the RUP, and I've discussed XP in detail with Kent Beck over drinks and not discussed Agile with Alistair Cockborn, although I did help him find his way around a conference because he had an eye infection and was doped the fuck up... (I too tend to get dinners with the keynotes at conferences). I've used both, although Kent would suggest that you're not doing XP unless you're following *ALL* the steps suggested.

That said, I don't think anything I said in my first paragraph was wrong. Rational's current implementation of RUP tools may be heavily oriented towards the programmer, but the RUP itself, and things like the 4+1 architecture models are about design, and are meant to be as implementation independant as possible.

I'll not talk about the Agile process specifically, because I'm a bit rusty on that, bt XP itself is design based on testing and programming. However, it's meant to readily be converted into abstract designs using tools (like Rational Rose, for example) so that between an effective means of transforming code into visualization, and the fact that requirements are captured in test cases, you have most, if not all of the artifacts espoused by the RUP being automatically generated. However, XP remains, at its center, based on implementation, and is all about programming and the programming language (although it can be effectively used with most, if not any programing language).

Now, I assume you were actually talking about my second paragraph, and above I've just disputed some of your assertions about the processes used (hey, ROP is slightly leaning towards architecture, but not at all entirely, and XP is very much leaning towards design). However, I firmly believe in a mixxed approach, pushing the RUP for early architecturaly design, but going to an XP type approach immediately after, and early on, iterating through them as appropriate. Architecture docs are easier to maintain, XP code artifacts essentially maintain themselves. The realm of the software engineer is creating both architecture and design (and partaking in elicitation with the stakeholders). Programers should not invlove themselves in the architecture and design beyond indicating what they can and cannot do , and what restrictions they forsee (although any good designer should listen to their programmers if they appear to have a good idea).

(Reply to this)(Parent)(Thread)

[info]quikchange
2005-11-09 04:54 pm UTC (link)
According to Cooper, an iterative approach to production code means that programmers either spend a lot of time writing high-quality code that is subsequently discarded (a colossal waste of time) or they write quick'n'dirty code that ends up shipping (a maintainence nightmare). That's why he advocates using XP (or related techniques) for the prototyping work vital to getting a good architecture (or high-level design, if you will) but not for producing the code that will eventually be used by customers.

He is adamant that "release early, release often" results in a lousy user experience and a lot of expensive code rewriting.

(Reply to this)(Parent)(Thread)

[info]ramou
2005-11-09 06:16 pm UTC (link)
My whole research group has had a good laugh at that paragraph. Either you misinterpreted what he said pretty badly, or you're talking crazy.

XP isn't XP if you're throw-away prototyping.

Read http://www.objectmentor.com/resources/articles/RUPvsXP.pdf for a nice blurb on RUP and how XP grew from a minimal implementation of RUP. I don't endorse everything in this paper, but it'll maybe give you a better idea of what I, and the rest of the Software Engineering community, are talking about.

http://www.martinfowler.com/articles/newMethodology.html is by one of my heroes, Martin Fowler (who I've yet to meet), and he discusses the methodologies of various people, Beck and Cockburn in particular. There are some links to XP resources there, and I reccomend a quick look before continuing to speak of XP as a means to throw-away prototype.

One of the advantages of the Software Engineering discipline is that we all read the same books and use the same language. Unfortunately, a lot of the terms have been popularized and frequently get misused, even by people speaking at conferences as name-dropping to add credibility. I think that if Cooper had a good solid look at some of the stuff written about XP, or at least Fowler's extremely enlightened analysis of the various methodologies, he'd not be so quick to criticize.

(Reply to this)(Parent)(Thread)

[info]quikchange
2005-11-09 07:17 pm UTC (link)
I think I captured his thoughts fairly well but you can read Cooper's debate with Beck about XP and see for yourself.

Thanks for the link about RUP and XP - I'll read it tonight.

(Reply to this)(Parent)(Thread)

[info]ramou
2005-11-09 10:26 pm UTC (link)
fucking install nuked my window and most of my comments:

AHEM: Cooper is keen on perpetuating the idea that clients are too stupid to ever come up with what they want, and the solution is to make those decisions for them, and instead of dumping that responsability on the developers, he espouses a new bunch of people, interaction designers (or whatever) to make decisions for stupid clients who can't do so themselves, and then work that out with the developers.

Beck, an optimist, believes that by working with clients and forcing them to work with developers, one can either determine early whether a project isn't feasible, or develop a relationship that will be very fruitful once the users understand what the developers can do for them (and thus can ask for things better) and the developers can better understand what the clients want (and thus can listen better) and you can benefit from all the nice synergistic thingies associated.

Cooper says Beck is wrong because people are stupid, Beck says people aren't stupid. Cooper says change is a sign of aging, and kills software. Beck says change is the environment, and software that takes that into account doesn't age quite so badly, and can even thrive.

Note that on page 8, Cooper says:
During the detailed design phase, the interaction designer works closely with the programmers. There's a crossover point in the beginning of the design phase where the programmers work for the designer. Then, at a certain point the leadership changes so that now the designers work for the implementers. You could call these "phases"—I don't—but it's working together.

Did he not realize what he said? He's so indoctrinated in his own dogma that he doesn't even realize it. You called it a phase, then you say you don't call these things phases!

After reading that, Alan Cooper is a twit who doesn't get it.

The only problem I have with XP is that I'd like to formalize the story writing a bit more to get a bit more of a stable architecture document out of it. Not a permanently stable document, but one that can change week by week with the design. The SAD should be simple, but I think it helps visualize an important aspect that might be otherwise missed with just the story writing... however, Cooper suggests a static SAD, and that REALLY defeats the purpose.

I love how Cooper suggests that our field isn't an engineering field. Fuck you Cooper, I am an Engineer. I can't always prove that my software works yet, the tools aren't there, but I can often prove it doesn't!!

ramou

(Reply to this)(Parent)

[info]tangbu
2005-11-10 05:22 am UTC (link)
I disagree with your/Cooper's categorisation of software engineers. My interest is definitely in the UI area, but I also have strong programming instincts so I avoid VB like the plague (it can't decide whether or not it's OO). Algorithms are just a mechanism for getting things done. So I spend all my time designing the UI and then write it in C. What does that make me?

I know many programmers who make a good living writing code and have never used a command line in their lives. Take their IDE away and they're helpless. What does that make them?

(Reply to this)(Thread)

[info]quikchange
2005-11-10 05:48 am UTC (link)
Until VB.NET it was object-based but not OO. It lacked inheritance, among other things. Like you, I too tend to spend lots of time designing my GUI and then coding it in C - at least when I'm not constrained by external requirements. But after reading [info]ramou's counterarguments to Cooper, I'm not sure about any of this now...

You don't need to be familiar with a command line to be a programmer - just ask anybody who used to write apps for the classic MacOS.

(Reply to this)(Parent)(Thread)
Command Lines
[info]tangbu
2005-11-10 07:07 am UTC (link)
Well maybe so, but if you're dependent on an IDE, you're not a real programmer. Then again there are people who swear by vi, one of the worst UI abominations ever created by the Unix crowd, and that's saying something...

(Reply to this)(Parent)(Thread)
Re: Command Lines
[info]quikchange
2005-11-10 07:17 am UTC (link)
A programmer is somebody who writes code for applications. The tools used can make this easier or harder to do but don't change the fact that this person is a programmer.

You appear to have an arbitrary definition of what a "real" programmer is.

Using the tools that allow you to be most effective is generally a good idea. Of course, tools that make it very convenient to do otherwise complex tasks tend to make their users dependent upon them. Are you a "real" driver even if you use an automatic transmission?

(Reply to this)(Parent)(Thread)
Re: Command Lines
[info]tangbu
2005-11-11 03:00 am UTC (link)
A real driver is a professional who knows their car inside and out. They know precisely how fast they can take a corner without losing control, and are able to adapt instantly to changing conditions. If you can't distinguish between a differential and a head gasket, you're not a real driver.

I'm not a real driver, nor do I wish to be.

I don't know whether you misread my post or you're just being pedantic. I never meant that IDEs are inherently bad, just that if you're lost without one, then you need to learn a few more tricks. If you're lost without your IDE, then you don't really understand the language. If you are afraid to learn more than one language, then you're probably in the wrong career, as this profession has always been about Change. And if you've only ever written code through an IDE, you probably have little idea about code efficiency.

If you aren't aware of how a high level language is translated down into machine language, you're never going to be able to make accurate determinations on performance and memory usage. You'll likely abuse copy and paste to create huge unmanageable programs, where a simple loop or judicious use of functions and parameters would considerably simplify the code. There are way too many applications out there that are needlessly cumbersome, difficult to maintain bloatware, and in my opinion a large contributor to such junk is programmers who are unable or unwilling to simplify their code. I've heard the argument that CPUs are fast enough that we don't need to worry about efficiency, and I just don't buy it. After you've tried to decipher a 5000 line C++ function you'll probably agree.

(Reply to this)(Parent)(Thread)
Re: Command Lines
[info]quikchange
2005-11-11 05:05 am UTC (link)
Your guess about misreading your comment was correct. I agree with everything thing you just said; I simply didn't realize that by "real" you meant "good" ;-)

(Reply to this)(Parent)
Re: Command Lines
[info]grosskur
2005-11-11 03:27 am UTC (link)
Real programmers don't need editors. They do: 
     cat /dev/audio > a.out
and hiss machine code into the microphone.

(Reply to this)(Parent)
Re: Command Lines
[info]ramou
2005-11-11 12:41 am UTC (link)
Some guy and I had a lengthy subthread in java_dev on IDEs, I agree with the T-man here:
http://www.livejournal.com/community/java_dev/290265.html

(Reply to this)(Parent)(Thread)
Re: Command Lines
[info]tangbu
2005-11-11 03:16 am UTC (link)
Thanks for that pointer. We're solidly in disagreement :-).

(Reply to this)(Parent)(Thread)
Re: Command Lines
[info]ramou
2005-11-11 03:25 am UTC (link)
It's okay, I understand your confusion about the difference between good programming habits and making efficient code. That is how you've been taught, and that's been computer science for decades.

However, I would suggest that you consider the possibility that using an IDE might be the best way to help students learn to organize their code, make fewer errors and document. Consider the refactoring tools from Eclipse, a far more powerful, consistent and better means of improving code than by trying to shrink it through black magic use of control structures.

In fact, Martin Fowler (http://www.martinfowler.com/) advocates completely forgetting about efficiency when refactoring. Once your code is well written, if you need to make it efficient, you do so after the fact. You make it good, then you make it fast. To further help the argument for making clean code, vs. "efficient" code, compilers and pre-compilers are getting much better at doing that for people.

If you really believe efficiency is important above all else, go code in assembly, try not to screw it up because there's very poor tool support/IDE support, and we'll see who can make better systems. The ability to abstract and use more powerful tools extends our ability to develop, and to develop well. IDEs support this abstraction (as C supported abstraction over assembly, and as C++ supported it over C and so on). This isn't to say that IDEs are all powerful, but to ignore tools to conform to some archaic macho male programmer pride is foolush.

(Reply to this)(Parent)(Thread)
Re: Command Lines
[info]quikchange
2005-11-11 05:20 am UTC (link)
[info]tangbu's response to my driving analogy indicates that he believes a good computer programmer is one who truly understands the entire scope of the technology in use. Yes, Eclipse is a more convenient development tool than the vim/gcc/gdb combo but having a thorough understanding of the system at every level from the CPU on up will certainly make anybody a better programmer.

So, even if you no longer actually use gcc and gdb directly, the experience of learning how will have made you a better programmer by forcing you to understand the underlying system better.

(Reply to this)(Parent)(Thread)
Re: Command Lines
[info]ramou
2005-11-11 05:32 am UTC (link)
Trying to understand the "entire scope of the technology" in use is not what I consider the makings of a good programmer. Such thinks can be admirable, but are often futile and arrogant.

Now, perhaps my view is biased from the point of a designer (who has to code because he doesn't have any programmers to do his bidding), but, to steal more from either Larman or Fowler, what makes a good design is what I think also makes good code:

  • Satisfies requirements.
  • Reveals intent.
  • Is a simple as possible.
  • Is adaptable


Or, it's more important that you make it so the next guy can understand what you've done, and why you've done it, than to fully understand the system yourself. The lone gunman is dead. The effort to work with others will pay off more than the effort to be able to do everything by oneself.

Am I slowly converting you?

ramou

(Reply to this)(Parent)(Thread)
Re: Command Lines
[info]tangbu
2005-11-11 09:05 am UTC (link)
I don't know if you're addressing this to myself or [info]quickchange, but there's no need to convert me to those statements. I've been trying to say all along that maintainability is one of the holy grails I seek, in my own code and others. Satisfies requirements? Of course. Reveals intent? That's what comments and meaningful variable names are for. Simple as possible? Yep. Adaptable? Even better.

So how do you do all these things without understanding the system yourself?

(Reply to this)(Parent)(Thread)
Re: Command Lines
[info]ramou
2005-11-11 01:00 pm UTC (link)
Some level of system understanding must be there, but you don't need to know the whole system, and I'm saying IDEs don't prevent this level of understanding, they encourage it.

(Reply to this)(Parent)
Re: Command Lines
[info]ramou
2005-11-11 05:49 am UTC (link)
Having gone back and (re?)read his post, I don't disagree entirely. Well, I disagree about the professional. I'm a professional because I know why most (by which I mean almost all) of what I do works, and why most of it fails, and people are willing to pay me because of this. I'm good because I can formally prove most (this is a much less comprehenxive most) in either direction. I'm amazing because I have an innate understanding of computers and a killer intuition for all things programming. I don't know everything in detail, and I can't remember most things, I just try to keep track of where I can find out what I need to know, but that niether impairs my profesionalship, nor my quality.

However, I agree whole-heartedly that being lost when you don't have "your" IDE is bad, but I forsee a time when programming will just be too onerous with "an" IDE, and the ability to navigate any IDE that crosses your path will be what the next generation of programmers will probably consider to be proof of being a good programmer. What I mean is that being inconvenienced by being without and IDE is not the same as not knowing what to do without one (I don't refactor without an IDE, it's too hard and too easy to fuck up... IDEs make it a blink).

I don't think that everyone has to be aware of the details to do a good job. That's the whole idea of abstraction and seperation of concerns. And yes, I agree that somebody will need to be able to do the down and dirty, because sometimes that's needed to be done so that I can do my high level abstract programming. However, suggesting that everyone needs to know that to be worth their salt is like saying every doctor has to know everything about the entire field of medicine AND pharmecology. You get more prodoctivity if some people do their part and you do yours than if you try to do it all.

And again, eclipse makes your code better, helping you identify and remove bloat in your code, and the code you are subjected to.

We make a much more educated and pleasant debate than Beck and Cooper... Maybe we should write a book.

(Reply to this)(Parent)(Thread)
Re: Command Lines
[info]quikchange
2005-11-11 06:14 am UTC (link)
We should totally do that. It appears I may be in Montreal for a few days near the end of April. You can buy me that pitcher of beer then.

I'd rather have a doctor who was truly interested in the field of medicine. Such a doctor would tend to have a good understanding of the entire field.

(Reply to this)(Parent)(Thread)
Re: Command Lines
[info]tangbu
2005-11-11 09:17 am UTC (link)
50% of doctors graduated in the bottom half of their class. I want my doctor to be interested in medicine too.

(Reply to this)(Parent)
Re: Command Lines
[info]tangbu
2005-11-11 09:15 am UTC (link)
Have you had the pleasure (?) of trying to hire someone for a job, either a contractor or a permanent hire? If so, do you look for the person who is content to have their little piece of the whole, never curious about how they fit into the pending project, never making any suggestions about how the code/process/organisation could be improved? Or maybe you want to hire someone who's passionate about programming, spends their spare time hunting the net for new knowledge, started programming as a hobby when they were 10, and has two or three personal projects that they work on at home in their spare time?

Unfortunately, I too see a day when programming will be a matter of manipulating icons on a graphical window, when the joy of puzzling over and eventually finding an obscure bug hidden in that little 10 line function you dashed off 6 months ago, is increasingly rare. Fortunately, people have been predicting such a day for the past 20 years, and though it's closer, it's still a fairly long way away.

(Reply to this)(Parent)(Thread)
Re: Command Lines
[info]ramou
2005-11-11 01:26 pm UTC (link)
I have had the misfortune of having to hire people for my own small business... all contract work, almost all disastrous.

In terms of programmers, I never suggested having a programmer who never provided input, in fact, I've suggested exactly the opposite above although any good designer should listen to their programmers if they appear to have a good idea. However, I don't want a programmer fixated on implementation details. I would prefer one who has a life outside computers (however hypocritical that may sound). Computer Gurus are rare and expensive. Computer Guru-wannabes are less rare, still expensive. Both tend to be somewhat narrow minded and set in their ways.

It's great to be an expert at efficiency and control flow, but what do you do when you're dealing with event based systems, asynchronous multithreaded systems? Distributed sytems? A doctrine of write for efficiency will screw you pretty badly. The problem is that too many programmers still cling to control flow and writing complicated function call structures to reduce code and increase efficiency, and those things turn out to be the antithesis of good code. There IS a place for that sort of stuff, but telling a beginning programmer that they have to master every detail of a programming language before they can use a tool to help them program better is elitism at best.

If your JUnit plugin in your IDE had red-barred you 6 months ago, you would have found the bug right away. I also submit that those sorts of bugs that last 6 months are usually caused by a mistype or some bad logic (assignment in an if, anyone?), the sort of things IDEs might catch.

Have you ever looked at aspects? If you have, you'll be amazed at how much they can clean up and organize code... but if you tell me that can be programmed effectively outside of an IDE, you're crazy. If you tell me that means beginner level programmers should not be shown AOP till they've mastered all of what you consider "the basics", you're arrogant. When you learn a language, it changes how you think. If we teach people assembly, they will learn to think a certain way, and that has a purpose. If we teach them to program at an abstract level, they learn to think differently. Both ways of thinking have value, and I'm suggesting that right now, programmers are better served to think of programming at a more abstract level than to worry about the details. You still need people doing both.

Lastly, your arguments place a value on knowing the details of what you know about, and ignore the value of knowing the details of what I'm talking about. Why is knowing all the intricate details of a programming language and compiler specific things to help efficiency and detailed low level system understanding more important than a sound understanding of OO methodologies and the tools that support them? Suggesting that students must learn both completely is asking a lot of most. I'd suggest that you place more value on those programming details because that is what you have learned, and that is what you have spent a good deal of time on, not because you've looked at both sides of the coinc carefully in an effort to determine what best to teach to students to produce better programmers.


(Reply to this)(Parent)
Re: Command Lines
[info]tangbu
2005-11-11 09:00 am UTC (link)
I'm not confused at all. The two things I see every day that make my blood boil are inefficient code and sloppily organised/undocumented code. I believe that tools like IDEs promote these bad habits rather than help correct them, and without instruction in more basic techniques are nothing more than a crutch.

When I was in high school, there was a big debate about allowing us to use calculators in class. We were allowed in grade 13 but before that we had to use our noggins. Today it's barely possible to find a HS graduate who can even subtract, let alone multiply. I'm sure there are teachers around that told their peers how calculators promote the investigation of higher level mathematics without the drudgery of the basics.

I've heard that "make it good, then make it fast" argument before. The trouble is, with deadlines being what they are, you never get to make it twice, and my point is that "making it good" the first time is a rare practice these days. I was taught to make it right the first time, and I don't see anything wrong with that philosophy.

I have coded in assembly language, for almost two years as part of my job. I believe it was a very large part of my education, because it forced me to write small, modular, re-usable routines that I could rely on to work correctly every time. I don't do so any more because that would be silly, but to sneer at assembly language implies ignorance of the benefits that being forced to program small, or fast, can bring.

I hate religious wars. Why don't we switch this to something less controversial, like editors maybe? :-).

(Reply to this)(Parent)

[info]ramou
2005-11-11 12:44 am UTC (link)
Glad to have caused thought and pause. Glad you made me go read stuff so I could confirm that I wasn't, myself, full of shit (or at least find evidence suggesting same).

(Reply to this)(Parent)

[info]grosskur
2005-11-10 07:02 pm UTC (link)
OO is a style of programming, not a property of some particular language.

(Reply to this)(Thread)

[info]quikchange
2005-11-10 07:23 pm UTC (link)
That's not what I learnt in my Programming Languages course...

OO is a programming paradigm (like functional, imperative, et al). Languages either support or prevent these paradigms from being used.

However, in a remarkable display of ambiguity, OO is also considered to be a programming methodology/style! Methodologies are different and not tied to specific languages so tightly.

It turns out that the reason for this ambiguity is because OO is really a design paradigm.

All this semantic juggling is making my brain hurt :-(

(Reply to this)(Parent)

[info]ramou
2005-11-11 12:43 am UTC (link)
what he said.

(Reply to this)(Parent)

[info]ramou
2005-11-12 04:14 am UTC (link)
heh, sorry for my hijack ranting. I'll try to be less zealous next time.

(Reply to this)(Thread)

[info]quikchange
2005-11-12 05:57 am UTC (link)
Oh, it's fine; I enjoy a good discussion :-)

(Reply to this)(Parent)

Create an Account
Forgot your login?
Login w/ OpenID
English • Español • Deutsch • Русский…