Allen makes a few rather inflammatory remarks in his article but the gist is that we need to rethink how the education of software developers happens. With that point, I completely concur. Historically, software has been under a number of different departments but primarily engineering and/or math. For example, at UC Berkeley, there is "computer science" under the College of Letters and Science (for a Bachelor of Arts degree) as well as Electrical and Computer Engineering under the College of Engineering (for a Bachelor of Science degree). The core software curriculum is shared between the two colleges with the non-core focusing on e.g., humanities or electrical engineering, respectively.
Allen, Peter Siebel [who's publishing a book as we speak called Practical Common Lisp], and I were talking about this whole software education problem at last week's excuse for free food (ahem, I mean the meet and greet that Apress threw for Joel [I swear that I had nothing to do with the fire alarms triggering the flooding of the building where it was supposed to be held] :-). The point of the discussion was not that software is or isn't "science", "engineering", "math", etc. but rather that current software education isn't focused enough on software as a discipline of writing (and reading). That is, we need more thought, education, and practice at making software a useful form of truly literate literature.
People have been trying out various alternatives for awhile. As you've probably seen on TV, there's a lot of education programs geared towards software from a vocational, trade school approach. This spans an interesting range from the bazillions of certification cram courses, and learn XYZ in 37 minutes how-to classes, through various accredited (and not :-) degree programs, and up to things like MIS degrees from accredited schools of management. More recently, Richard Gabriel has been working on the notion of a Master of Fine Arts in Software (or "Master of Software Arts"). Heck, even the venerable Knuth has waxed rhetoric on his notion of Literate Programming (more info available here and here).
Now, back to the question that started all of this discussion. Software is something wondrous. It is not merely engineering, math, science, or even art. Software is all of the above and more. People struggle and create so much suffering because they keep trying to force it into their familiar pigeonholes. Luckily, the solution is really simple... Software is a functional bridge between the abstract and reality.
Much of the effort in Informatics right now is in the area of software (and other information technologies) development, with practitioners of Informatics focusing on how that software will fit into its context. Context includes other technologies, physical environment, users, and anything else surrounding the project which is pertinent to how the product will be used.
Informatics also focuses even more on the social aspects of technology, but the above is where a lot of the effort is because its where a lot of the direct results will be realized.
One example that came up recently in discussion is designing a vending machine. In CS classes the vending machine is often used as an example project because its complex enough to be interesting, but simple enough to be doable (as a software abstraction, of course). The thing is, having been trained to look at a vending machine in this way, many CS students and graduates won't look at what's really important about a vending machine -- things like how easy it is to choose what you want (ever seen those really complex coffee vending machines that seem to confuse everyone on their first use?), and how accessible the dispensed product is (people with bad backs hate having to get product out of that low slot).
Another good example is my school's new registration system. It is so hard to use that they dispense an instructions-only booklet nearly as long as the booklet that held both the instructions for the previous registration system and all the course listings.
The new system is really easy to use -- if you're a database. The entire thing feels like a complex data entry process, for picking classes! Ignoring for now the instructions being bad as well, its important to underscore what should be important in a registration system: allowing students to register for classes in a way that mirrors how they think about it.
For instance, the current system is pretty much useless for doing anything but signing up for a predetermined list of courses. However, students like to play around with possible course lists and schedules. Registration software should allow this behavior.
There are plenty of other examples as well, but that one is a good one, because there's no inherent need for it in an abstract registration system. Instead, it can only be determined with some understanding of the context, in this case the human/social/organizational context of a college campus.
As I recall, one premise of the idea for a software MFA was a belief that engineering is not a completely successful metaphor for software development. I've often wondered if we even have the understanding of what engineering really entails to use it as a metaphor, but I digress. Alternative metaphors abound, but the best of them recognize that there is a high degree of arts-like individual performance involved.
Recognizing that individuals and interactions matter more than planning and paperwork is recognizing the performance aspects of the trade. We certainly can gain useful insights into software development through comparision with the preparation and practices of a musical performer in advance of a public performance. As with improving musical ability, building good software depends on continuous, rapid, and meaningful feedback.
Indeed, the field of informatics is another attempt to make a coherent place for technology. I'm also partial to the field of cognitive science. :-)
As your examples make clear, without bridging the gap between the nebulous abstractions and persnickety reality, the costs (direct, to the users, as well as as all of the fallout and opportunity costs (see http://www.artima.com/weblogs/viewpost.jsp?thread=69024 for more on this)) go up and the value goes down.
> As I recall, one premise of the idea for a software MFA > was a belief that engineering is not a completely > successful metaphor for software development. I've often > wondered if we even have the understanding of what > engineering really entails to use it as a metaphor, but I > digress.
Yeah, the structural notions of engineering are, at best, only analogies to software. Indeed, if you follow the best (physical, non-software) architects and builders, they bring in much more dynamic notions into the mix.
> Alternative metaphors abound, but the best of > them recognize that there is a high degree of arts-like > individual performance involved.
I concur that there are definitely some benefits to bringing more of the notions from the various arts fields into the discussion but I don't find them any more metaphorically exact, per se, then the engineering notions. Ecology is one of the best metaphors that I've found.
> Recognizing that individuals and interactions matter more > than planning and paperwork is recognizing the performance > aspects of the trade. We certainly can gain useful > insights into software development through comparision > with the preparation and practices of a musical performer > in advance of a public performance. As with improving > musical ability, building good software depends on > continuous, rapid, and meaningful feedback.
> The point of the discussion was not that > software is or isn't "science", "engineering", "math", > etc. but rather that current software education isn't > focused enough on software as a discipline of writing (and > reading). That is, we need more thought, education, and > practice at making software a useful form of truly > literate literature.
I would say that current software *development* isn't focused enough on the task of writing for other people as well as the machine. Prior to the last few turns of Moore's Law, professional software engineers didn't have the luxury of being able to express their designs at the domain-specific level; it was pointers and jmp statements all the way down. I think few would disagree that now that we can express rich designs in our code, we should.
Unfortunately, the common languages for software development don't foster this notion at all. You're always coding to the machine because, hey, that's ultimately what pays the bills. No modern, widely-used languages (that I'm aware of) actually let you express designs, relationships, and domain-specific concepts as part of the "coding" process. All the languages I know of defer that role up to English/the native language of the programmer. (Even CWEB and Knuth's notion of literate programming use English as the concept modelling language.)
This is problematic because naturally evolved human languages are notoriously fuzzy at expressing and modelling structure in a rigorous way. Mathematicians and scientists have overcome this problem by using the language of math, complete with its own symbols, operators, and a whole host of different meanings. Software, however, can only leverage that framework to a certain point, because math and science don't have leaky abstractions. All their abstractions are fully defined (even if it takes several volumes of dense prose), and they can easily model infinities mapping onto other infinities. In software, *every* abstraction is leaky - even our concepts of INT and FLOAT are limited.
So, in short, the field of software is at a transitional state right now, where we are far enough beyond machine code that we can sense something more fundamental on the horizon, but not yet far along in our conceptual understanding to actually be able to formulate what that is. There is an ACM interview with Alan Kay at http://acmqueue.com/modules.php?name=Content&pa=showpage&pid=273 where he basically makes the point that software is a trade and not a science only because no one has developed a coherent body of theory that describes how to scale the stuff. That is, in any intellectual endeavor, there is only one kind of rigor and that is always mathematical.
The mathematical basis for computing is limited to low-complexity things: proofs of correctness of certain types of problems, proofs of running time/difficulty of other sorts of problems. But as far as I know, there isn't any theory describing the interactions between really complex computing systems. When you try to do anything serious or practical on a billion transistor chip, you end up leaving behind the comfy island of mathematical/theoretical CS and end up basically being a tradesman who hacks software together.
> Now, back to the question that started all of this discussion. Software is > something wondrous. It is not merely engineering, math, science, or even > art. Software is all of the above and more.
I have to disagree with this notion. Software engineering *does* have something new to bring to the scientific table - the modelling of complex systems - but in most respects it is another engineering discipline. Any resemblance it bears to art is due to either (1) the creative/intuitive aspect present in all branches of math and science, or (2) the lack of objectivity present in any traditional tradecraft. Alan Kay said it best in his interview:
If you look at software today, through the lens of the history of engineering, it?s certainly engineering of a sort?but it?s the kind of engineering that people without the concept of the arch did. Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves.
IMHO, software's missing arch is a formalism for expressing relationships between complex, incomplete abstractions.
> I would say that current software *development* isn't > focused enough on the task of writing for other people as > well as the machine.
Ah, sorry for not giving more context. Much of the background for this conversation is the fact that it's ridiculously hard to get existing, entrenched developers and development organizations to change so the best place to focus effort is on the training of the next generations.
> Prior to the last few turns of > Moore's Law, professional software engineers didn't have > the luxury of being able to express their designs at the > domain-specific level; it was pointers and jmp statements > all the way down. I think few would disagree that now > that we can express rich designs in our code, we > should.
Actually, we've always been able to do so. It's just been hidden amongst all of those pesky details. It just took a lot of intellectual horespower, experience, and discipline to do so. With the additional computational capacity, we do have the opportunity to code more concisely and say precisely what we mean. Of course, today it takes a lot of intellectual horespower, experience, and discipline to keep from getting sucked into each of the over-hyped "silver bullets" that comes along.
> Unfortunately, the common languages for software > development don't foster this notion at all. You're > always coding to the machine because, hey, that's > ultimately what pays the bills. No modern, widely-used > languages (that I'm aware of) actually let you express > designs, relationships, and domain-specific concepts as > part of the "coding" process. All the languages I know of > defer that role up to English/the native language of the > programmer. (Even CWEB and Knuth's notion of literate > programming use English as the concept modelling > language.)
[...] > IMHO, software's missing arch is a formalism for > expressing relationships between complex, incomplete > abstractions.
Well, we have some but they all suck in various ways. So, right now, it's a lot about making tradeoffs between which suckage works for you and which work against you. Unfortunately, most projects seem to pick poorly. :-( But, there are some new things coming down the pipe. :-)
"Traits are a simple composition mechanism for structuring object-oriented programs. A Trait is essentially a parameterzied set of methods; it serves as a behavioral building block for classes and is the primitive unit of code reuse. With Traits, classes are still organized in a single inheritance hierarchy, but they can make use of Traits to specify the incremental difference in behavior with respect to their superclasses."
"Unlike mixins and multiple inheritance, Traits do not employ inheritance as the composition operator. Instead, Trait composition is based on a set of composition operators that are complementary to single inheritance and result in better composition properties."
There is a working prototype implemented in Squeak. Its a bit like method categories from Objective C, but you can apply them to any class you like. Primary constraint is that a Trait may not access ivars directly, instead going through accessors. This also implies that a Trait specifies a required interface of the class to which it will be applied.
> I would say that current software *development* isn't > focused enough on the task of writing for other people as > well as the machine. Prior to the last few turns of > Moore's Law, professional software engineers didn't have > the luxury of being able to express their designs at the > domain-specific level; it was pointers and jmp statements > all the way down. I think few would disagree that now > that we can express rich designs in our code, we > should.
Unfortunately, it looks like Moore's Law was just a brief bubble. Processor manufacturers have hit the wall now. Unless something major happens, we'll have to go parallel to go faster and not all problems are parallelizable:
I would recommend the reading of Paul Graham´s book titled "Hackers and Painters:Big ideas from the Computer Age".
Among his clever comparisons between art crafting and software crafting is the one in he states that software development should be similar to the way and artist works, that is through trial and error, and that programming languages should promote that (and hence the case for dynamic typing...)
Yeah, Moore's Law was really just an inflationary period where all of the easy stuff about building processors was learned.
In terms of parallelization, yes, it's true that there aren't a lot of problems that are massively parallelizable but even small scale (2-, 4-, 8-way) parallelization goes a very long way with a huge range of problems.
Historically, as an industry, we software folks have done an amazingly bad job of dealing with parallelization. Some of it was certainly due to relying on e.g., Moore's Law effects to save us. Some of it is that we have relied on general purpose programming languages that are piss poor (that's a technical term :-) at facilitating parallel programming.
> Yeah, Moore's Law was really just an inflationary period > where all of the easy stuff about building processors was > learned. > > In terms of parallelization, yes, it's true that there > aren't a lot of problems that are massively parallelizable > but even small scale (2-, 4-, 8-way) parallelization goes > a very long way with a huge range of problems. > > Historically, as an industry, we software folks have done > an amazingly bad job of dealing with parallelization. > Some of it was certainly due to relying on e.g., Moore's > s Law effects to save us. Some of it is that we have > relied on general purpose programming languages that are > piss poor (that's a technical term :-) at facilitating > parallel programming.
So true. It will be interesting to see how this plays out with regard to programming language design. I hope that constructs from dataflow programming languages get another look. There was a language called 'Lucid' in the 80s which looked pretty neat.
> So, is software development just a bunch of computational > l math theory, a science of computers, a field of > engineering, or something completely different?
> Software is something wondrous. It is not > merely engineering, math, science, or even art. Software > is all of the above and more. People struggle and create > so much suffering because they keep trying to force it > into their familiar pigeonholes. Luckily, the solution is > really simple... Software is a functional bridge between > the abstract and reality.
To me, software development is a lot like architect in that you strive to produce beatiful and elegant designs - this is the art portion. OTOH, like an architect, you have to do some engineering to make certain that your creation will stand. For buildings its structural analyis. In software its algorithm analysis, memory size estimations, etc. That's the hard engineering part.
Its rather unfortunate that most machines are now vastly over powered for the jobs they do. The requirement for the engineering becomes less each year - somewhat like house building relies less on structural engineering than on building codes.
Yet there are still domains where rigor remains critical (bridge building, massively scalable systems, embedded software, transportation control).
Flat View: This topic has 30 replies
on 3 pages
[
123
|
»
]
Previous Topic
