BitWorking

Yeah, I'm with you. Frequently the activity of development is more worthwhile than the end result and also I tend to try to do a very quick first iteration on a design/implementation to extract lessons for the second and later iterations. I wrote a post on this topic recently.

Posted by Bill Higgins on 2007-02-06

A few thoughts. I find that I immediately doubt the credibility or seriousness of anything published with an AOL logo on it. What a brand problem.

Second, it seems that your response is a veiled refutation of John's premise that:

there are some people who just aren't good at finding prior solutions, or at understanding them once found, and they may contribute to unnecessary re-creation of software, increasing both cost and risk to larger projects. But they're not the norm

I really like the idea of programming as knowledge acquisition. But the bit about "unnecessary re-creation of software" seems to contradict his whole piece and smacks of a little elitism if you ask me.

Posted by Justin Watt on 2007-02-07

I suppose whether a particular re-creation is necessary depends on whether you're an 'engineer' or a 'scientist'. I was talking from the 'engineering' point of view, where the primary goal is to solve a problem. Here knowledge acquisition is just a prerequisite and unnecessary re-creation doesn't advance your goal. If you are being a 'scientist' and your primary goal is to acquire knowledge, then re-creation is fine and actually is a foundation of the scientific method. Sometimes you have to go back and forth between the two roles of course. Perhaps I misinterpreted Scott Rosenberg and he was really saying that the big problem is that programmers behave like scientists, when their projects need them to behave like engineers. The root problem then is not competence but a conflict of interest. I just don't think this is a key problem. That is, it's a real issue, but I don't see it as the key reason why software projects take so long or fail so often. I actually see the reverse problem a lot more (engineers trying to get a quick solution and not recognizing when it's time to step back and put on a scientist hat for a while).

Posted by John Panzer on 2007-02-07

Software development is a knowledge acquisition activity, not a manufacturing activity. This truth has been said before. There is one Alain Perlis epigram that says something like "When we try to make computers learn, it turns out that we learn and computers don't". In the Mythical Man Month you can read similar conclusion when discussion turns into second system effect. I think there is many examples of wrong kind of knowledge acquisition. You learn something by programming that you could have learned more quickly from the books or from studying how old programs do it. When you use both these sources and then write your programs you can learn something that others have not learned before. I think software engineering field lacks memory. It is frustrating to see that field is not moving forward but people just discover same solutions over and over.

Posted by Nick Nolan on 2007-02-08

In truth it is both: a balance between real world needs and theoretical perfection.

Posted by Mike Cantelon on 2007-02-08

I think building one's one software when there are suitable options out there would happen less often if open source also meant open architecture and open documentation. If I want to know the different elements required in building forums or a querying system or whatnot, I either have to dig deep into someone else's source code (which probably lacks comments and statistically isn't all that great), or do it on my own. The stress and annoyance of looking at other people's code without a birds-eye view from which to work is fairly significant. There needs to be more information like this: http://www.pui.ch/phred/archives/2005/04/tags-database-schemas.html Thoughts?

Posted by Luke on 2007-02-09

I have been doing my own stuff (you name it, me's done it). And I have never understood why people look at it as bad to do what has already been done. You can't understand the Standard Template Library of C++, unless you've cloned it. You can't know your *NIX real good, unless you've cloned it. You can't know your typing real good, unless you've typed! (Not just read what has been typed.)

I have argued this and frothed at the mouth, and thought I was the only one who saw this. Wrong, of course.

And, don't let anybody tell you it is for those who are learning. No! Learning never ends, and every time you write new code, you learn. Even if what you are learning is a new bug (or the lack of a feature) in your own programming language.

(Removed my address, because I think it may be reaped by bots - can it? Here, anyway, of you want it: revence27 at g m a i l dot com)

Posted by Revence 27 on 2007-02-10